linux-kernel - Re: New Security Features, Please Comment

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]

Message-ID: <73639.1228272932@turing-police.cc.vt.edu>
Date:	Tue, 02 Dec 2008 21:55:32 -0500
From:	Valdis.Kletnieks@...edu
To:	Geoffrey McRae <geoff@...idhost.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: New Security Features, Please Comment

On Wed, 03 Dec 2008 12:44:17 +1100, Geoffrey McRae said:

> I would welcome more information as to how this can break applications
> as I am very new to kernel hacking and would like to solve this
> performance vs security problem once and for all.

A *lot* of software has implicit assumptions - for instance, that your process
UID remains constant unless you intentionally did a setuid() call.

Read Henry Spencer's (now ancient but still educational) write-up on *some* of
the things that can happen to set-UID programs:

http://www.daemon-systems.org/man/setuid.7.html

Now consider that *any* program that gets its UID suddenly changed on it
just became vulnerable to all that stuff that Henry writes about.

News flash - most programmers who wrote code thinking it would run as the
same userid the whole time don't do checks for all the sort of stuff that
Henry warns about when programs suddenly get invoked with more privilege
than they were designed to handle.

Then there's the opposite case - somebody manages to trick you into nuking the
permissions on the right process-ID but wrong executable. Hilarity ensues when
the process is running with *less* privilege than it expected. Go and read up
on how Sendmail failed back around 2000, and understand *why* it failed. Just
google for 'sendmail CAP_SETUID' and start reading. Then think what happens if
somebody manages to get PHP to exec() some other binary (a set-UID one) and
it's busy running when you whack its UID.

That's just off the top of my head.

Then go look at kernel/sys.c and read the comments just before the functions
sys_setpgid(), sys_setregid(), and sys_setuid(), and figure out how the
saved uid enters into things....

There be serious and nasty dragons in there...

Content of type "application/pgp-signature" skipped