Bugtraq mailing list archives
Re: [HERT] Advisory #002 Buffer overflow in lsof
From: robert () cyrus watson org (Robert Watson)
Date: Fri, 19 Feb 1999 13:35:09 -0500
On Fri, 19 Feb 1999, Mariusz Marcinkiewicz wrote:
On Thu, 18 Feb 1999, Don Lewis wrote:... or are there systems that give group kmem write privileges? If so, I'd say that's a security hole.Yes, you are right... but... I saw that hole after installing new linx and checked it's security. First I was suprised but not for a long time. In a few mins I noticed all linux versions are chown .kmem; chmod g+s lsof... on linux /dev/kmem is +w for gid kmem, on bsd too (probably, I
Sorry, no go. FreeBSD 2.2-STABLE and 4.0-CURRENT, the two versions I have sitting around, have the following permissions on /dev/kmem: crw-r----- 1 root kmem 2, 1 Mar 7 1998 /dev/kmem Please verify claims such as these before posting them. FreeBSD also does not ship with lsof installed, although if the package/port is installed, it will be installed sgid kmem.
didn't checked that), so... all of std. distributions are vuln. without ONE! the slackware, IMHO, it's the most secure distribution [ :))) i know: slackware doesn't has lsof;))) but by tahat way that distr. is secure ;P ]
Write access to /dev/kmem would certainly be fairly nasty--you might as well give the user kernel privileges outright (to be distinguished, btw, from root access, due to securelevels). As has been pointed out, even read access to /dev/kmem can be sufficient to gain root access, it just requires a little more skill and patience, however. I do not know of a way, however, to gain kernel privileges using only read access to /dev/kmem, when securelevels are in use (correctly). I haven't given that particular problem much thought, and discouraging kmem access both in and out of securelevel is probably a good idea for other reasons (such as IPsec keying material privacy, passwords, etc). Robert N Watson robert () fledge watson org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/
Current thread:
- Re: [HERT] Advisory #002 Buffer overflow in lsof Don Lewis (Feb 18)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Vic Abell (Feb 18)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Mariusz Marcinkiewicz (Feb 18)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Robert Watson (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Lee Brotzman (Feb 22)
- NcFTPd remote buffer overflow Julien Nadeau (Feb 23)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Alan Cox (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Alex Shnitman (Feb 20)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Wichert Akkerman (Feb 21)
- Possible DOS attack in the .nu domain service Shane Wegner (Feb 20)
- Severe Security Hole in ARCserve NT agents (fwd) Weld Pond (Feb 21)
- Administrivia Aleph One (Feb 22)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Robert Watson (Feb 19)
- <Possible follow-ups>
- Re: [HERT] Advisory #002 Buffer overflow in lsof Friedrichs, Oliver (Feb 18)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Eric Stevens (Feb 19)