Re: SquirrelMail <= 1.4.23 Remote Code Execution (CVE-2017-7692)

[Dawid Golunski <dawid () legalhackers com>]

Stuart,

Your suggested mitigation is good and was in fact already mentioned in
my advisory, see
'VIII. SOLUTION' section of:
https://legalhackers.com/advisories/SquirrelMail-Exploit-Remote-Code-Exec-CVE-2017-7692-Vuln.html


As for the utility I just wrote my own C tool that loops through
argv[] and saves it into a file.
If you need something more advanced / already available you can try
auditd rules.


Regards,
Dawid Golunski
https://legalhackers.com  |  https://ExploitBox.io
t: @dawid_golunski



On Tue, Apr 25, 2017 at 5:56 PM, Stuart Gathman <stuart () gathman org> wrote:
> On 04/24/2017 05:14 PM, Dawid Golunski wrote:
> > SquirrelMail <= 1.4.23 Remote Code Execution (CVE-2017-7692)
> >
> > Desc.:
> > SquirrelMail is affected by a critical Remote Code Execution vulnerability
> > which stems from insufficient escaping of user-supplied data when
> > SquirrelMail has been configured with Sendmail as the main transport.
> > An authenticated attacker may be able to exploit the vulnerability
> > to execute arbitrary commands on the target and compromise the remote
> > system.
> We deploy squirrelmail NOT using sendmail for sending mail ($useSendmail
> = false).  There is no reason not to use SMTP instead of running
> sendmail directly.  It doesn't seem to be vulnerable that way - and I
> suggest that as a mitigation.  Just to be sure, after reading this
> advisory I added  $sendmail_path  = '/usr/sbin/false'; (We always avoid
> direct command execution with PHP because PHP is prone to quoting bugs.)
>
> OT: is there already a utility that *safely* logs arguments and stdin
> (as was apparently used to explain the exploit)?  I could write a C
> prog, or a carefully quoted bash script - but would rather use an
> already proven utility.