Ted Cooper wrote:
> On 10/12/10 00:20, Brad Jorsch wrote:
>> I've tried to take a look, but I haven't been able to reproduce it in a
>> quick attempt.
>
> My attempt to hunt it down without the dump ended up being quite
> fruitless, except for finding where the headers are read in and the
> memory allocated for them. After grabbing the dump off Sergey I
> discovered I was thinking far too small with the amount of data that was
> being sent.
>
> I'm in the process of attempting to write something to reproduce the
> result but I have a feeling it's going to be based on a very exact
> amount of data being sent which is very dependant on the system exim is
> running on.
>
> Is anyone else working on this in the background?
>
>
In an oblique way, yes.
Very oblique...
I'm looking ONLY at the external environment, specifically on FreeBSD and
OpenBSD.
'whyso' is partly because I am reasonably certain the exploit would fail on
either of the *BSD's, not only as I run them, but as commonly configured.
By 'fail' I am ignoring the initial 'implantation' attack vector ('coz it
cannot
succeed here at all [1])
.. and presuming successful implantation of the payload files as the start
point.
There seem to be adequate barriers to the exploit - all external to Exim, but
starting with not being vulnerable to the delivery mechanism in the first
place...
More when I have more....
Meanwhile:
Absent *total* elimination of once-up Exim ever again needing or having access
to root privs, I don't believe even the cleverest of coding is going to be good
enough to cover 'all possible' exploits on 'all supported' OS'en in 'all
possible' builds or configs. Not even close.
That said - I am not sure THIS exploit actually puts the average system at risk.
Surely we would have seen more real-world compromises over the many years?
Was the OP actually hit with this?
Or did he *write* it? (no apologies, w/r servers, I am one paranoid MF!)
And is the community now being enlisted to confirm it can work - and show how
to
refine it?
It's a 'glass house' we operate in here...
Perhaps 'the work' should be on private channels for a time - if not so
already..
JM2CW,
Bill Hacker
[1] for several reasons - throttled bandwidth, per-IP connection limit, limited
total connections, rDNS hard-fail, and finally defer if the deliberately
limited
pool of PostgreSQL connections is used up.
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details
at http://www.exim.org/ ##
