[9680] in bugtraq
Re: [HERT] Advisory #002 Buffer overflow in lsof
daemon@ATHENA.MIT.EDU (Vic Abell)
Fri Feb 19 20:25:31 1999
Date: Thu, 18 Feb 1999 16:43:26 -0500
Reply-To: abe@purdue.edu
From: Vic Abell <abe@PURDUE.EDU>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199902181631.IAA19818@salsa.gv.tsc.tdk.com>
Don Lewis writes:
>
> On Feb 18, 1:30am, "Anthony C . Zboralski" wrote:
> } Subject: [HERT] Advisory #002 Buffer overflow in lsof
>
> } When lsof is setuid-root or setgid kmem, it is vulnerable to a buffer
> } overflow that will lead to direct root compromise or root compromise
> } thru live kernel patching.
>
> If lsof is installed setgid kmem, it shouldn't gain any privileges to
> overwrite something to gain root access. At worst, it should only be
> possible to read things in kernel memory that ordinary users shouldn't
> have access to (I suppose this might include a password in a tty buffer
> if the cracker got really lucky).
>
> ... or are there systems that give group kmem write privileges? If so,
> I'd say that's a security hole.
I'd say the /dev/kmem warning is over-stated. Most systems don't
give the group that can read /dev/kmem write permission.
However, some systems at times have used the same group ownership
for /dev/kmem and important system directories, AND made those
directories and some of their files group writeable. In that case
a stack attacked lsof might be able to do file or directory damage.
There are three lsof installations that could be setuid(root):
Pyramid DC/OSx lsof, /proc-based Linux lsof (generally Linux kernels
2.1.72 and above), and Pyramid Reliant UNIX lsof. (I've tried to
limit the number of dialects that need setuid(root) permission.)
Lsof drops its set[gu]id permissions as soon as possible.
Vic Abell <abe@purdue.edu>, lsof author
