There are some vulnerabilities in the Internet Anywhere Mail Server version 2.3.1, build 10020. They are probably present in earlier versions too:
1) If you send the POP3 server the commands "user", "retr", "list" or "uidl" with arguments that are about 200 characters long, the server crashes.
2) If you send the POP3 server the commands "list a", "top a a", or "uidl a" (that is, letters where there should be numbers), the server crashes.
3) If you send the SMTP server the command "vrfy" with an argument that is about 250 characters long, the server crashes.
4) Another problem is that the server stores the account passwords in plaintext in the file msgboxes.dbf.
Points 1-3 are fixed in the brand new version 3.1 which is now available from True North Software
, but point 4 will not be fixed until a future version - all this according to True North Software.
So, is it possible to get some code of our own to execute by exploiting the buffer overflows? I've written some exploit code, iamexploit.c
, which starts the Command Prompt in one of my servers when I run it from another computer (it probably won't do it on yours without modification, see below). The program exploits the vrfy overflow. How easy would it be to modify it to work against other systems? First of all it is dependent on the version of msvcrt.dll, because of the entry address to the system() function. This part of the program could of course be changed. There is however another complication in this case - the server converts the whole vrfy string to uppercase after receiving it - and that includes converting the payload machine code to uppercase too. I've circumvented this by using assembly instructions which don't generate machine code that contains "lowercase character values". A bit tricky, especially since you can't have any null characters in the code either, but it works. I wouldn't want to write any complicated payload this way though. :) Now, there are a couple of more problems here. First of all, the bytes we send to overwrite the return address are also converted to uppercase. This time I was lucky, the ones I use in my case are ok. The second problem is that the stack location depends on more things than the SP version and so on.