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 Sun Jun 28 1998 - 04:00:29 NZST