Bugtraq mailing list archives
Re: Serious Linux 2.0.34 security problem
From: daia () stoilow imar ro (Liviu Daia)
Date: Wed, 1 Jul 1998 12:45:35 +0300
On 30 June 1998, David Luyer <luyer () UCS UWA EDU AU> 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 <alan () LXORGUK UKUU ORG UK> 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
Current thread:
- Re: Serious Linux 2.0.34 security problem Theo de Raadt (Jun 30)
- Re: Serious Linux 2.0.34 security problem Alan Cox (Jul 01)
- 1998 USENIX Annual Technical Conference - Call for Papers Jackson Dodd (Jul 01)
- <Possible follow-ups>
- Re: Serious Linux 2.0.34 security problem Liviu Daia (Jul 01)