On Tue, 29 Aug 2000, Jeffrey Goldberg wrote:
> > | As stated continuously on this newsgroup, with respect to many security
> > | issues, seteuid() does absolutely nothing to protect against code
> > problems
> > | that allow an attacker to entirely comprimise the running program. An
> > | attack allowing me to execute arbitrary system calls in this environment
> > | allows me to simply reset my credentials back to root.
>
> Again, see above. I simply don't believe that that is true, but I am not
> an expert on such things.
In fact, I can show it is not true. There is a whole host of pseudo-experts who
claim to be able to spot security problems at a mile off. The simple truth is,
even if there is a section of code that doesn't do bounds checking, you have to
work out how to exploit it. You can spend your entire life grepping for dodgy
fucntion calls, but unless you can write an exploit to take advantage of that
code, you may as well just shut the hell up.
I've taken a look over the code, and yeah there are things that could be
tightened up a little bit, but I'm damned if I can see a way of leveraging an
exploit out of it. In fact, I might put the code auditors around here on it for
a few weeks to see for certain if there is something amiss.
> > | Exim seems to exhibit all the security design mistakes Sendmail has
> > made,
>
> That is a contentless statement.
Indeed. That's like saying that old Suzuki jeeps are dangerous therefore all
jeeps that are 4-wheel drive and quite tall are all dangerous as well.
> > | had paid attention to Sendmail's progress at all, the code would be many
> > | times more secure.
>
> For years now exim has used its own sprintf() functions. Though I am a
> bit surprised that PH made the mistake of using the standard library one
> in the very early days of exim.
To say that PH should have followed sendmail's lead is quite laughable. For
security purposes sendmail has lagged behind the rest of the pack for many
years. It's why sendmail 9.0 is a complete re-write from scratch that has been
on-going for several years now, IIRC.
> > | Specific examples include giving little (or no) consideration to the
> > | size of data read from the environment, arguments, or the outside world,
> > | string manipulation and logging routines which hide unchecked standard C
> > | library string copy and formatting operations (I'm particularly fond of
> > | string_sprintf), and, in some situations, even trusting argv[0] as
> > passed
> > | to the program to contain the path to the exim binary.
>
> All of that has been long fixed I believe.
Again, correct. There are a few areas where the code could be tightened, but
like I said above, I can't see how to exploit it.
> > | I've taken only a cursory look at Exim (in fact, I haven't even strayed
> > | out of "exim.c" yet). I do not claim to fully comprehend all the
> > security
> > | implications of the code. However, what I have seen thus far is
> > frightful;
So, he hasn't read the code, but is commenting on it and describing it as
frightful and dangerous. He wouldn't happen to be a Daily Telegraph reader would
he?
> > | in Exim's process memory space. For that matter, so is the binary Exim
> > | executes when restarting itself (defined by a global pointer called
> > | "exim_path"). What's to prevent someone from altering either of these
> > | and subverting the program? Certainly not the code!
>
> This is interesting. Anyone who knows more about these things wish to
> elaborate? I'm not sure what the alternative is recommended.
Bahahahaha.... sorry, but I'd like to see you do that. No, really, I want you
to try and do that as user nobody when exim is running under it's own uid. We
were talking about this very kind of exploit the other day down the pub, and
although it has possibilities, there are problems around how seteuid() is used.
> > | like old versions of Sendmail" than against "programs that work
> > | differently from qmail". At this point, I'd be far more comfortable
> > | running Sendmail 8.8.5 on a sensitive machine that I would be running
> > any
> > | revision of Exim.
Please do so. You run sendmail 8.8.5 on a public machine, and provide me with
legal release. I'll have it rootkitted within the hour. Put exim on, and well,
I'm going to shrug my shoulders, say "well done" and look for holes elsewhere
on the system.
At the end of the day, my company is involved in the security industry as much
as it is the ISP industry. Therefore, we take a great deal of care in choosing
the software that our clients mail and web traffic go through. We have spent
countless days pouring over code. One of my guys used to spend 12 hours a day
writing exploits within the underground community, and he hasn't yet complained
to me about the problems you descibe with exim.
I think to draw this argument to a close, we should just say "Write the exploit
or shut up". I know we've tried writing them, and we have a hell of a lot more
experience in this field than most of the bearded prats who think they know
about security in here.
I'm not going to say that exim is better or worse than any other MTA. All I am
going to say is that whilst software that has had a lot of holes found in it
gets a thorough auditing by the security community (such as sendmail), I have
yet to see a single solitary exploit that works with current versions of Exim.
Until that happens, you can assume it is secure. It is all very well being able
to read through code and going through 'what-if' cases, but if you haven't
actually been able to get that exploit to work, you're dreaming.
--
Paul Robinson - Internet Services @ Akita -
http://www.akita.co.uk
------------------------------------------------------------------
Sales:- T: 01869 337088 F: 01869 337488 E: sales@???
Techs:- T: 0161 228 6388 F: 0161 228 6389 E: root@???
------------------------------------------------------------------
