Bugtraq mailing list archives
Re: QPOPPER problem.... ONE crude patch...
From: tbrown () BAREMETAL COM (Tom Brown)
Date: Sat, 27 Jun 1998 01:58:10 -0700
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
Current thread:
- !!! FLASH TRAFFIC !!! QPOPPER REMOTE ROOT EXPLOIT Seth McGann (Jun 26)
- Re: !!! FLASH TRAFFIC !!! QPOPPER REMOTE ROOT EXPLOIT Theo de Raadt (Jun 27)
- patch for qpopper remote exploit bug Roy Hooper (Jun 27)
- Re: patch for qpopper remote exploit bug Andres Kroonmaa (Jun 27)
- Re: patch for qpopper remote exploit bug Theo de Raadt (Jun 27)
- Re: patch for qpopper remote exploit bug Jon Lusky (Jun 27)
- Re: patch for qpopper remote exploit bug Benjamin J Stassart (Jun 27)
- Users can view script source from Win WebServers Aleph One (Jun 27)
- Re: patch for qpopper remote exploit bug Andres Kroonmaa (Jun 27)
- Re: QPOPPER problem.... ONE crude patch... Tom Brown (Jun 27)
- Re: QPOPPER problem.... ONE crude patch... Daniel Ryde (Jun 27)
- Re: QPOPPER problem.... ONE crude patch... Marco S Hyman (Jun 27)
- Re: QPOPPER problem.... Jason Ackley (Jun 27)
- Re: QPOPPER problem.... Bruno Lopes F. Cabral (Jun 27)
- patch: qpopper (plugs another hole too) Miquel van Smoorenburg (Jun 27)
- Re: QPOPPER problem.... Marco S Hyman (Jun 27)
- Re: QPOPPER problem.... Bruno Lopes F. Cabral (Jun 27)
- More patch ideas for qpopper Aaron D. Gifford (Jun 27)
- Re: QPOPPER problem.... Jeff Haas (Jun 27)
- Re: QPOPPER problem.... ONE crude patch... Daniel Ryde (Jun 27)
- Re: QPOPPER problem.... ONE crude patch... Yiorgos Adamopoulos (Jun 27)