Re: QPOPPER problem.... ONE crude patch...

[tbrown () BAREMETAL COM (Tom Brown)]

On Sat, 27 Jun 1998, Seth McGann wrote:

> Its come to my attention that systems around the internet are being
> exploited using a new remote overflow in Qualcomm's Popper server.  Well,
> lets clear a few things up:

<snip>

> 2.  This vulnerability effects FreeBSD, OpenBSD, and Solaris x86 so far.
> Other systems are most certainly vulnerable.  Linux does not appear
> vulnerable.  To test, simply send the sever several thousand characters and
> see if it crashed.  Check the return address to see if it matches.

QPopper 2.4 (which is the current stable package, I just checked
qpopper2.41beta1 from ftp.qualcomm.com and it has the same problem... :-[)
on Linux ** IS ** vulnerable...  and I see no reason why we shouldn't
expect it to be ...

pop_msg.c does a

        vsprintf(mp,format,ap);

at line 66 as Seth pointed out... into a fixed length buffer (on the
stack) pointed to by mp... the problem described is any command long
enough to overflow MAXLINELEN (1024) bytes when formatted as:

-ERR Unknown command: "%"\r\n

changing this to something like:

        vsnprintf(mp,sizeof(message)-(mp - message)-3,format,ap);
        /* minor change -> vsnprintf, as per bugtraq Jun 27th posting...*/
        /* -3 leaves room for null and \r\n appended below */

solves the immediate (or maybe I should say obvious), problem...

Wanna test your own box...?

perl -e 'print "e"x2000,"\r\nQUIT\r\n";' | nc -i 2 target 110

assuming you have netcat (nc) on your system... if not, just
telnet to your server and paste something like 20 lines of solid
characters into your telnet window... You'll get the -ERR
response back... at which point unpatched servers should core
dump... and you get "Connection closed by foreign host."

I haven't audited the code to see what other responses you can get out of
the pop server without having gone through the authentication stage (at
which point the POP server drops from root to the logged in user...) but a
cursory glance indicates that the user, apop, pass, quit, and "notvalid"
commands would be the most significant,

we also have a probably buffer overflow in pop_log.c (line 50), but it's
to a global variable, not a stack variable... same fix... simpler
actually...

change to something like:

        /* vsprintf(msgbuf,format,ap); bugtraq fix #2 */
        vsnprintf(msgbuf,sizeof(msgbuf)-1, format,ap);

... those are the only two occurences of vsprintf() in the code that I
see...

----------------------------------------------------------------------
tbrown () BareMetal com   | Courage is doing what you're afraid to do.
http://BareMetal.com/  | There can be no courage unless you're scared.
                       | - Eddie Rickenbacker