An addendum, actually copied from the Sun-managers list where
the qpopper exploit is a definite problem :
[snip]
Now that the official qpopper buffer overflow problem has been publicized,
others might like to know of alternate popper sources:
ftp://ftp.cac.washington.edu/mail/imap-4.1.BETA.tar.Z
Univ of Washington's imap
ftp://ftp.cac.washington.edu/imap
CMU's cyrus
ftp://ftp.andrew.cmu.edu/pub/cyrus-mail
and cucipop
ftp://ftp.informatic.rwth-aachen.de/pub/packages/cucipop
ftp://ftp.fdt.net/pub/unix/packages/cucipop/
[/snip]
Perhaps of use to anyone who is worried. Still haven't identified
any errors on DU though.
chas
-----------------------------------------------------------------
>Thanks to Arrigo and Ann Cantelow for quick replies on this one.
>I've appended bother answers but for myself the bottomline is :
>
>1) there is indeed an issue... if only b/c you can expect to see
> yourself probed. (i've yet to get a core dump on my own machines)
>2) protect your port with TCP wrappers (though for some of us that
> have staff checking mail using local dial-up accounts with ISPs -
> ie. where we do not know the IP ranges - this can be troublesome,
> with the risk of blocking our own users)
>3) use an alternative POP server. I actually have pop3d that comes
> with Cyrus IMAPd running on some other machines BUT that uses a
> different mailbox format (fine if you're already using IMAP but
> a lot of work to convert otherwise). Hopefully other POP servers
> will not suffer from the same problem.
>
>quick and perhaps incomplete reply b/c speed is of the essence here,
>i think,
>
>chas
>
>
>>From: Arrigo Triulzi <arrigo_at_albourne.com>
>>|
>>|Just saw this on the FreeBSD list and not sure
>>|if I missed something here on DU. Is it a problem
>>|for us too ? (didn't have any effect on my box)
>>
>>I can confirm that my site has been flooded with POP requests since
>>Thursday. All stopped by TCP-Wrappers which I strongly recommend.
>>
>>There is an apparently better POP server called IMAPD by the
>>University of Washington.
>>
>>I think you might want to confirm that there is an issue to the list.
>>
>>Arrigo
>
>---------------------------------------------------------------------
>
>
>From: Ann Cantelow <cantelow_at_athena.csdco.com>
>
>Here is post with much better information than mine, from BugTraq:
>
>----------------------------------------------
>>From tbrown_at_BAREMETAL.COMSat Jun 27 09:31:30 1998
>Date: Sat, 27 Jun 1998 01:58:10 -0700
>From: Tom Brown <tbrown_at_BAREMETAL.COM>
>To: BUGTRAQ_at_NETSPACE.ORG
>Subject: Re: QPOPPER problem.... ONE crude patch...
>
>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...
>
>
>
Received on Mon Jun 29 1998 - 18:43:10 NZST