> 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
an option).
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
'su').
You'd probably be well served to read the Andrew Morgan's
pages at:
http://www.kernel.org/pub/linux/libs/security/linux-privs/
.. and at:
http://www.kernel.org/pub/linux/libs/security/Orange-Linux\
/refs/Orange.html
> 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:
> /bin/su
> possibly some programs (xterm,...) from X11 package, but I haven't found
> and problems without this bit.
>
> Hope this patch will help :)
>
>
> g00bER
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).
(http://www.cs.berkeley.edu/~daw/janus/)
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:
http://www.communities.com/company/papers/security/index.html
--
Jim Dennis, The Linux Gazette "Answer Guy"
Linux Gazette is Published under the GPL http://www.linuxgazette.com
answerguyat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:55:35 PDT