bugtraq - Re: cdrecord local root exploit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 1 Oct 2004 13:26:30 -0400 (EDT)
From: "Greg A. Woods" <woods@...nix.com>
To: "Jason T. Miller" <jasomill@...ffstall.com>
Cc: "D.r Andrew C. Aitchison" <A.C.Aitchison@...ms.cam.ac.uk>,
	"BUGTRAQ: Full Disclosure Security Mailing List" <bugtraq@...urityFocus.com>
Subject: Re: cdrecord local root exploit

[ On Tuesday, September 28, 2004 at 01:22:17 (-0500), Jason T. Miller wrote: ]
> Subject: Re: cdrecord local root exploit
>
> The notion that a program must be root if an ordinary user doesn't have
> the necessary permissions by default is a dangerous one.

Very well said.

I really liked your way of presenting the idea of a setuid proxy too.
Not very many texts on secure programming techniques are so lucid.

Even those of us who've been trying to practice secure programming
techniques (esp. on unix-like systems, i.e. those using setuid), have
had tremendous difficulty implementing the principle of least privilege.

I can usually get as far as designing my code in the manner of your
outline for something like cdrecord where a program needs certain
privileges to open a device file and where only certain users should be
allowed to run that program.

However with the limitations of file and process ACL technology present
in most unix-like systems following this principle gets a lot more
difficult if, for example, you want to have a second limited group of
users be able to write to a configuration file for the program, but not
make it possible for the program itself to write to any of its
configuration files (e.g. if it were to suffer a buffer overflow and
give its privileges to an attacker).  As far as I've ever been able to
figure out it's almost impossible to do this on unix-like systems if you
also need to protect the content of the configuration file from prying
eyes (i.e. not be "other"-readable).  It might be possible to do
relatively safely with a pair of communicating front-end/back-end setuid
proxy programs, providied they can have hard-coded group-ID numbers (and
provided the host system implements multi-group membership for
processes).  Such complexity though is an enemy of security.

-- 
						Greg A. Woods
						Planix, Inc.

<woods@...nix.com>     +1 416 489-5852 x122     http://www.planix.com/