I received emails from a bunch of XMail users saying that tools like
nessus reports XMail buffer overflow and security holes.
It's definitely not true and it's these tools that are bugged.
They try to send very loooong command lines with length that exceed the
rfc constraint and, when XMail sees such behaviour does not even try to be
pretty with these clients and it drops the connection.
These tools then thinks that the server died but it's not.
XMail has another protection that check the command line string for the
correct encoding ( us ascii ) and, if it detect binary chars, it drops the
connection.
In these way if buffer overflows will ever exist, the hacker will never be
able to execute its code due the lack of available chars.
Another XMail unique protection against buffer overflows is the random
stack pointer shifting at thread startup.
When every XMail thread starts the stack pointer is randomly "moved" by
making the SP guessing for hackers almost impossible.
The hacker will be forced, probabilistically, to try a huge number of
times and the user will perceive this like server crashes.




- Davide


Reply via email to