I'm surprised there's been no discussion here of something this big --- ALL
OF US WERE WIDE OPEN AND THE BAD GUYS KNOW ABOUT IT.
You need to know so you can make the decision to shut down web messaging
and calendaring (which certainly would have the same problem), or patch it
with a firewall by blocking packets containing non-ascii characters. I
haven't posted the exploit or patch. I wouldn't trust the patch from
someone who does not responsibly disclose bugs - not to mention that the
patch is applied in an unsafe manner. I'm off with a disassembler to check
it out though.
-------------------- Original message ---------------------------------
"In 1995, Ipswitch released IMail Server, the first
commercial NT Mail Server. Seven years later there are
over 49 million users of IMail worldwide.
IMail Server 7.1
Greater security, improved usability, and new revenue
opportunities for service providers."
7 years in development, 20 minutes of BuffSex
v0.3(tm), 3 remote 'root' holes
2c79cbe14ac7d0b8472d3f129fa1df55 Security Advisory #5
#PRODUCT
IPSwitch IMail, All Versions
#VULNERABILITY
there is an overflow present in the GET parameter
under the HTTP/1.0 specification in the Web Messaging
daemon in all IMail versions to date.. HTTP/0.9 &
HTTP/1.1 are not vulnerable, as they have been fixed
in a previous bug report.. oops, forgot one :>
#EXPLOITATION
<96 bytes><EBP><EIP>
choosing right causes no problems, soooo....
as none of the registers point to our payload on ret
some trickery is necessary to hit our payload in a
dynamic way.. nothing too difficult however
esp is 8 bytes from our payload, but it has to run
right over our chosen ret (call/jmp esp).. so flat out
jmping esp has some shitty near-impossible odds
working against it.. so we need to do some sex first
execution flow:
eip overran, ret (esp-4) -> (imailsec.dll) land at pop
ebx, ret10 (esp-18) -> (imailsec.dll) call esp
after only 3 redirections we've now got esp pointing
at our corrupted payload.. YUMMY!
preserve esp -> sub esp -> jmp esp
we preserve esp to prevent our stack from running
right over our code, then we jump relative to our good
payload.. ooohh you know whats coming next
recover esp -> execute shell
now that the stack is out of the way, we can just let
the shit fly..
see attached exploit.. target imail version is 7.11
(HF1 applied or not)
#PATCH
since this is just a simple buffer overflow
(lstrcpya() if I remember correctly?), a simple patch
is in order!.. GET argument is now limited to 90
characters, we can assume no more is necessary, as
someone else would have found this earlier..
#EOF
mailserver #4, more to come..
always,
2c79cbe14ac7d0b8472d3f129fa1df55
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Please visit the Knowledge Base for answers to frequently asked
questions: http://www.ipswitch.com/support/IMail/
