3 ms·

The advisory says exploitation is not limited to just systems running the original Sendmail MTA, but Postfix' "sendmail" wrapper apparently ignores the "-X" par

by 0x0 10y ago

The advisory says exploitation is not limited to just systems running the original Sendmail MTA, but Postfix' "sendmail" wrapper apparently ignores the "-X" parameter... so how can a Postfix-based system be exploited?

thaumaturgy 10y ago
Yeah, looks like you're right, and although there might be some ways to abuse other Postfix command line options for some kind of mail abuse, I don't see that it offers any options that'll write a file to a specific location. If true, that's another big point in Postfix's favor. On one of my web-facing servers running Postfix: root@:/home/rob# sendmail -X/home/rob/test.log sendmail: fatal: unsupported: -X/
tyingq 10y ago
I believe it's because the exploit isn't actually exploiting sendmail, it's expoiting /bin/sh sh -c <cmd>. Php's implementation of popen() doesn't invoke commands directly with stdlib's execl() or execle()...it calls stdlib's popen(), which passes it through /bin/sh -c <cmd>. That's assuming phpmailer doesn't treat a postfix sendmail wrapper differently than sendmail. Edit: As far as I can tell, php doesn't allow any way to spawn a process without passing it to /bin/sh. That's odd, as other script languages like Perl and Python provide that. It avoids a whole class of exploits. Edit2: It seems to be exploiting the "-f" option, not "-X". The postfix wrapper supports that.
- thaumaturgy 10y ago
  It's exploiting -f to abuse -X to allow it to save a file with PHP tags to an externally-accessible location. Without -X or some similar capability, it's not exploitable. Well, it is, but not for the same amount of fun -- all you get to do is abuse whatever other arguments Postfix makes available to you. I don't see a whole lot that a non-root user calling Postfix's version of sendmail can do with this ... maybe get a mail server RBL'd.
  - tyingq 10y ago
    Ah, yes, you're right. Maybe the option to use an alternate alias database could be troublesome, but would require some other hole that allowed local file creation.

by 0x0 10y ago

thaumaturgy 10y ago

Yeah, looks like you're right, and although there might be some ways to abuse other Postfix command line options for some kind of mail abuse, I don't see that it offers any options that'll write a file to a specific location. If true, that's another big point in Postfix's favor. On one of my web-facing servers running Postfix: root@:/home/rob# sendmail -X/home/rob/test.log sendmail: fatal: unsupported: -X/

tyingq 10y ago

I believe it's because the exploit isn't actually exploiting sendmail, it's expoiting /bin/sh sh -c <cmd>. Php's implementation of popen() doesn't invoke commands directly with stdlib's execl() or execle()...it calls stdlib's popen(), which passes it through /bin/sh -c <cmd>. That's assuming phpmailer doesn't treat a postfix sendmail wrapper differently than sendmail. Edit: As far as I can tell, php doesn't allow any way to spawn a process without passing it to /bin/sh. That's odd, as other script languages like Perl and Python provide that. It avoids a whole class of exploits. Edit2: It seems to be exploiting the "-f" option, not "-X". The postfix wrapper supports that.

thaumaturgy 10y ago
It's exploiting -f to abuse -X to allow it to save a file with PHP tags to an externally-accessible location. Without -X or some similar capability, it's not exploitable. Well, it is, but not for the same amount of fun -- all you get to do is abuse whatever other arguments Postfix makes available to you. I don't see a whole lot that a non-root user calling Postfix's version of sendmail can do with this ... maybe get a mail server RBL'd.
- tyingq 10y ago
  Ah, yes, you're right. Maybe the option to use an alternate alias database could be troublesome, but would require some other hole that allowed local file creation.