On Wed, 4 Sep 2002, Lars Troen wrote:
>
> Shawn wrote:
> > Hmm, I have a vague recollection of Davide release a quick=20
> > fix like less
> > then 12 hours after a regular release -- I figured it was him=20
> > that found
> > a fixed the issues -- still 2 in how many years? How many other mail
> > vendors can say the same :-D
> >=20
>
> qmail & postfix.. atleast for remote exploits.. not sendmail, exchange, =
> notes, groupwise and others I guess.
>
> That xmail has not had many vulnerabilities the last few years doesn't =
> mean that xmail is flawless. Just look to apache httpd. Or sshd. Or the =
> OpenSSL lib. These were living for quite a few years without remote =
> exploits.
>
> I wish I could change the greeting banner in order to let potential =
> hackers know as little about my systems as possible. It's possible to =
> fool nmap's os detection and I guess most hackers move on to the next =
> system if they can't figure out much about your systems.
>
> Why do you think we get regular scans for bind versions? Also in bind =
> you can return bogus versions here without loosing functionality.=20
>
> Also it wouldn't break anything (else than not being RFC compliant) by =
> changing the banner. All extended mail options are still available =
> through ehlo.
>
> Quite a few programs let you alter greeting messages. Usually not with =
> commercial software, but enterprise firewalls can also do that. Pix for =
> instance automaticly filters out any such responses from the mailserver =
> (inserts 'X's in place for the message) while some others have built in =
> smtp secure proxies (Checkpoint/Raptor).
>
> So I'd say it's quite an accepted thing to do this and you're actually =
> gaining something from it too. I also can imagine it wouldn't be the =
> hardest thing on earth to implement such a feature.
I tried to stay out of this, but i couldn't resist. Hiding banners is the
most stupid and useless thing that one can do. It's so useless that is not
even funny. Do you really think that the attacker will become
kind-of-scared because it won't be able to detect the MTA and will pass to
something else ?
<hacker algorithm>
if port-25-open {
if banner == xmail {
shoot-xmail-exploits
} else if banner == exim {
shoot-exim-exploits
} else if ...
...
} else {
shoot-all-the-damn-exploits
}
}
</hacker algorithm>
And this is the smart version, the dumb one is to just shoot all known
exploits for the given port. More, you can differentiate MTAs only by
error responses if you want. An open port is a precious resource for an
hacker and he simply won't pass because the banner is anonymous.
About exploits, XMail is obviously not invulnerable. But suppose that a
code like this is present inside XMail :
void foo(void) {
char buffer[10];
...
read_from_socket(sock, buffer);
...
}
What the hacker can do ? To inject code he has to guess that stack
pointer, and this is easy for other softwares because you have simply to
try to make the program crash and look at the coredump ( or dr watson dump
). XMail has, at each thread creation, a random stack pointer movement
that with current values can assume 256 different positions. This means
that the attacker has less that 0.5% of probability to get it right. And
what will hapen if he won't get it right ? The program will crash ( 99.5%
of the times ) by generation a coredump and this will be sufficent for me
to know the exact point of failure. More, being XMail multi-threaded the
whole program will crash and the attacker won't have another immediate
opportunity to retry. This is not true with (x)inetd daemons where the
attacker can continuosly try the exploit. Hope this will clarify for
another couple of months.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
