3 ms·
Somewhat ironic for all the noise made about qmail that many configurations of it are vulnerable. I wonder if Bernstein will be paying out that $1000 reward, a
by calpaterson 12y ago
Somewhat ironic for all the noise made about qmail that many configurations of it are vulnerable. I wonder if Bernstein will be paying out that $1000 reward, and if so, to who
See section 1.3:
http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf
- dfranke 12y agoThe qmail bounty explicitly disclaims "bugs outside of qmail", which this one clearly is. So, no.
- kag 12y agoWhy it's not exploitable without the shellshock-vulnerable bash, you could argue that qmail is not validating the input in accordance with the RFCs. In fact, that's one of the things I said here: http://marc.info/?l=qmail&m=141183309314366&w=2 http://marc.info/?l=qmail&m=141183309314366&w=2
- panic 12y agoInput validation is an orthogonal issue here, since bash doesn't know anything about RFC821/RFC2821, doesn't expect data in that format, and doesn't make any guarantees about what it will or won't do on such data. The only reasonable policy for a shell to follow is to be entirely input-agnostic and never execute code based on the contents of an environment variable (regardless of which RFCs the contents conform to).
- kag 12y agoOf course bash doesn't know and shouldn't know about the SMTP RFCs. Yes, bash shouldn't execute code in variables. I was talking about input validation in qmail itself, not bash. Even though bash shouldn't have executed the code, better input validation and RFC conformance in qmail could have prevented exploitation of bash. You know, defense-in-depth.