mailing list archives
Re: First Patch :)
From: jimd () STARSHINE ORG (Jim Dennis)
Date: Sat, 30 May 1998 06:16:04 -0700
Hi traqers of bugs !
Here is my first patch for Linux. Its purpose is to stop some
exploits based on using SUID bit. For better protection it should be
combined with Solar Designer's one (but it could work independently
too). It doesn't make writing exploits impossible, but at least a bit
tougher. I have tested it on my computer, but it is possible that it
won't work in some cases.
I presume you mean the stack_noexec kernel patch.
(I was hoping that would make it into the 2.2 kernels as
There has been considerable discussion on the
comp.security.unix newsgroup about the limitations of
this and Crispan's StackGuard.
How does it work - for each process it stores a new uid (I
have choosen a name RUID = Real UID). Purpose of RUID is to keep
track of who is real owner of this process (it is inherited from
parent process and changed only when root's process runs process
under different EUID). When process tries to spawn (fork/exec)
process under EUID!=RUID and it is not originally root's process
(RUID==0), it is reported to console and EUID is forced to RUID.
Of course, sometimes it is required for process to spawn something
under different EUID (example is 'su'). I needed to somehow mark programs
that are allowed to spawn under different EUID. For this purpose I have
choosen new bit (thus it cannot be marked by chmod). So, programs marked
in this way CAN spawn programs under different UID.
Hmm. There's already work under way to support MLS style
"privileges" (wrongly called "capabilities" in some POSIX.1e
literature). Some of the prelimary support is already in the
2.1.x kernels in lieue of BSD'ish securelevel. Further support
will apparently require extensions to the ext2fs filesystem
(to store the privilege bitmaps for specific binaries like
You'd probably be well served to read the Andrew Morgan's
.. and at:
Explanation how it works on exploits. Ex, standard old
exploit by Solar D. (the one using NLSPATH on "/bin/su"):
1) user (hacker) COOLER runs program a.out
2) process a.out gets ruid=(uid of COOLER)
3) process a.out prepares what it needs (set variable,...)
4) it runs process '/bin/su'
5) process 'su' gets RUID=(uid of COOLER) and EUID=0
6) something happens (exploit code gets control)
7) it does 'setuid(0)' to set its *UID=0
8) when trying to 'exec("/bin/sh"...)', my code checks if it can do
so (variable 'secure' is used to). If not, message is sent to console
and EUID=(uid of COOLER).
values of secure:
0 = unsecure program
1 = secure program
2 = program that isn't secure, but was runned by secure program. This
isn't used in present version of patch, but probably will be used
in some future.
There are some other things that this patch should do.
To mark secure programs, I needed to use some technique. At this moment
I use the S_ISVTX (+t bit), but I have another idea - use new bit.
Problem is that in standard inode attributes is no free space :)
So I decided to use inode->flags, but I still don't know how is it
possible to set flags :) Many other ideas will be implemented in next
version of this patch.
I would suggest that you leave your patch using the t bit
*which is meaningless on files in kernel Linux implementations
and does have related to security semantics when used on
directories in any event.
I'd also suggestion that you present this as an interim
experimental patch --- and look at the privs and capabilities
projects that I've mentioned above.
Of course, this patch is not absolutely proof. Here are two ways
of bypassing the exploit
1) hacker doesn't need to exec anything (he can do everything in the
exploit code. ex, write something to passwd/shadow,..., because at
that moment it runs under EUID=0).
programs that require marking using my patch to work properly:
possibly some programs (xterm,...) from X11 package, but I haven't found
and problems without this bit.
Hope this patch will help :)
I personally kind of miss the point of this whole kernel patch.
it doesn't address the core problem (that the SUID binary might
have exploitable bugs) but it adds complexity to the kernel
(risking new exploitable bugs in that!
If you have a list of programs that should never be allowed to
fork/exec other processes, that might suggest a wholly different
approach (some people have discussed introducing a kernel
option that allows one to set a process flag so that a bitmask
is consulted before *every* system call. Thus a parent program
could set a child process in such a way that a whole list of
suspicious system calls would be deferred to the parent. That
is similar to the research done under the "Janus" project ---
except that it puts a relatively simple kernel patch in place
to avoid the overheard of ptrace (???). (This was a USENIX
paper within the last couple of years).
I'd much rather see work done on creating a true capabilities
subsystem for Linux --- based on the model that's described by
Jonathan Shapiro at: http://www.cis.upenn.edu/~eros/ and in
a paper at the Electric Communities web site:
Jim Dennis, The Linux Gazette "Answer Guy"
Linux Gazette is Published under the GPL http://www.linuxgazette.com
answerguy () ssc com