Home page logo
/

bugtraq logo Bugtraq 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
        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

                            answerguy () ssc com



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]