Wolfgang Jeltsch writes:

Sam Varshavchik wrote that exploits should only be possible via
*-default files. I currently do not understand why this is the case. The
special thing about *-default files with regard to environment variables
seems to be that the DEFAULT variable is set to a part of the recipient
e-mail address. But also here I wonder whether this allows for an
exploit. I suppose one would have to send e-mail to an address like
<user-() {someting;}na...@example.com>, but I cannot see how this should
be possible.

Also the EXT* variables. When -default files are used, they will have the corresponding portion of the recipient's email address.

SENDER doesn't seem to be a problem. Courier rejects a return address that starts with "()" characters.

RECIPIENT/LOCAL can only be the recipient's exact email address, if -default wildcards are not used.

So, I only see DEFAULT and EXT* variables as a problem.

UFLINE, RPLINE, and DTLINE will always start with From_, Return-Path: and Delivered-To:, those can't be munged.

Furthermore, I wonder whether successful exploits can always be detected
via the logs. Is it, for example, enough to just check for the string
“() {” in the mail log file?

> CVE-2014-6271 and CVE-2014-7169 are the same in this respect, so the new
> vulnerability doesn't change the affected status (although the later is
> harder to exploit doing something useful, while with 6271 it was
> straightforward).

What exactly does CVE-2014-7169 allow for? And if it is harder to
exploit in general, is it even exploitable at all via Courier?
Unfortunately, I have not yet found anything detailed on CVE-2014-7169
on the web.

I have some additional knowledge. As far as anyone can tell, the successful exploit would allow bash to be coerced into creating a 0-length file, with the name of the file being the name of the command that bash was going to execute.

However, the only available information shows that you need to stuff an > character into an email address, which is not possible with SMTP.

I don't think that CVE-2014-7169 is a problem here. The partial patch that has been kicked around is going to contain most of the damage. For the ultraparanoid, it's trivial to reconfigure Courier to use csh, see my other message.

Attachment: pgpB_DHFVhbwc.pgp
Description: PGP signature

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to