Wolfgang Jeltsch wrote:
> Am Donnerstag, den 25.09.2014, 22:16 +0200 schrieb Ángel González:
> > Any program which allows untrusted variable contents into the
> > environment and can be made to spawn a bash descendant is "affected".
>
> The question is how an attacker can convince Courier to set environment
> variables to malicious contents.
>
> So far, I have found the variables listed in the dot-courier manpage
> under “ENVIRONMENT VARIABLES” as variables that could be set from the
> outside. However as I understand, such a variable must be set to
> something that begins with “() {” to exploit the bash bug. I wonder
> whether this is possible at all, or whether Courier does sanity checking
> on things like the envelope return address.
>
> 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.
I think that the point is the *-default files can launch a shell.
Variable values are set much earlier into the environment.
> I would be happy about any clarification why *-default files are
> affected by this bug, and why other parts of Courier are not.
>
> 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?
No. I'm quite sure there can be cases where they are not logged. But
maybe you are not vulnerable, after all.
> > 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.
It is a variation of CVE-2014-6271. It provides an exported function
through the environment with a syntax error. Bash gets confused and
creates a file named as the first argument, executing from the second
argument onwards (that it shouldn't).
It is weaker because you have less control on bash actions. The
conditions to explit them are the same IMHO, but you have less
flexibility with CVE-2014-7169.
------------------------------------------------------------------------------
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
