Re: Linux v2.6.0-test1

Re: Linux v2.6.0-test1

[John Bradford]

> Then you'll just have to wait a few months

Oh well, it just seems strange to be asking people to test
2.6.0-root-my-box, without making the consequences a bit clearer.

John.

Re: Linux v2.6.0-test1

[Dave Jones]

On Mon, Jul 14, 2003 at 12:50:40PM +0100, John Bradford wrote:
 > > Then you'll just have to wait a few months
 > 
 > Oh well, it just seems strange to be asking people to test
 > 2.6.0-root-my-box, without making the consequences a bit clearer.

>From http://www.codemonkey.org.uk/post-halloween-2.5.txt

------ 8< 8< 8< 8< ------
Security concerns.
~~~~~~~~~~~~~~~~~~
Several security issues solved in 2.4 may not yet be forward ported
to 2.5. For this reason 2.5.x kernels should not be tested on
untrusted systems.  Testing known 2.4 exploits and reporting results
is useful.
------ 8< 8< 8< 8< ------


If you don't have the time/energy to trawl linux-kernel, testing the
many zillions of `sploits out there to see what works and what doesn't
may be more fun. (Although most if not all should be failing, so it
may also get boring very quickly). It'd be nice if someone like osdl
could add such testing to nightly regression tests. Some of them may
even be candidates for LTP perhaps ?

		Dave

Re: Linux v2.6.0-test1

[William Lee Irwin III]

On Mon, Jul 14, 2003 at 12:50:40PM +0100, John Bradford wrote:
>> Oh well, it just seems strange to be asking people to test
>> 2.6.0-root-my-box, without making the consequences a bit clearer.

On Mon, Jul 14, 2003 at 12:53:13PM +0100, Dave Jones wrote:
> If you don't have the time/energy to trawl linux-kernel, testing the
> many zillions of `sploits out there to see what works and what doesn't
> may be more fun. (Although most if not all should be failing, so it
> may also get boring very quickly). It'd be nice if someone like osdl
> could add such testing to nightly regression tests. Some of them may
> even be candidates for LTP perhaps ?

Some work has been done here, though I'm not sure how much; I'll try to
get the IBM people involved with it to chime in.


-- wli

Re: Linux v2.6.0-test1

[Alan Cox]

On Llu, 2003-07-14 at 13:00, William Lee Irwin III wrote:
> Some work has been done here, though I'm not sure how much; I'll try to
> get the IBM people involved with it to chime in.

The IBM india folks (being outside the DMCA zone) went through a long list of 
fixes and propogated them but there are lots of others some pretty critical such
as the fs/exec stuff and proc leaks

Re: Linux v2.6.0-test1

[William Lee Irwin III]

On Llu, 2003-07-14 at 13:00, William Lee Irwin III wrote:
>> Some work has been done here, though I'm not sure how much; I'll try to
>> get the IBM people involved with it to chime in.

On Mon, Jul 14, 2003 at 01:39:44PM +0100, Alan Cox wrote:
> The IBM india folks (being outside the DMCA zone) went through a long list of 
> fixes and propogated them but there are lots of others some pretty critical such
> as the fs/exec stuff and proc leaks

Well, that should cover it. Odd that I've not heard of those two.


-- wli

Re: Linux v2.6.0-test1

[Alan Cox]

On Llu, 2003-07-14 at 13:47, William Lee Irwin III wrote:
> Well, that should cover it. Odd that I've not heard of those two.

They've had publically discussed fixes, patch files, CAN vulnerability
identifiers and mail to bugtraq. The information is out there but the
2.5 people have been too busy on more fundamental stuff I guess

Re: Linux v2.6.0-test1 [[Fwd: [Full-Disclosure] Linux 2.4.x execve() file read race vulnerability]]

[David R. Piegdon]

this one was posted on full-disclosure a while ago
i think this is what alan cox means with
 fs/exec stuff
:)


----------  Forwarded Message  ----------
From: Paul Starzetz <paul@starzetz.de>
To: bugtraq@securityfocus.com,
 vendor-sec <vendor-sec@lst.de>,
 full-disclosure@lists.netsys.com
Date: Thu, 26 Jun 2003 19:24:23 +0200

Hi people,

again it is time to discover a funny bug inside the Linux execve()
system call.


Details:
- ---------

While looking at the execve() code I've found the following piece of
code (from fs/binfmt_elf.c):

static int load_elf_binary(struct linux_binprm * bprm, struct pt_regs *
regs)
{
    struct file *interpreter = NULL; /* to shut gcc up */

[...]

    retval = kernel_read(bprm->file, elf_ex.e_phoff, (char *)
elf_phdata, size);
    if (retval < 0)
        goto out_free_ph;

    retval = get_unused_fd();
    if (retval < 0)
        goto out_free_ph;
    get_file(bprm->file);
    fd_install(elf_exec_fileno = retval, bprm->file);


So, during the execution of new binary, the opened file descriptor to
the executable is put into the file table of the current (the caller of
execve()) process. This can be exploited creating a file sharing
parent/child pair by means of the clone() syscall and reading the file
descriptor from one of them.

Further, the check for shared files structure (in compute_creds() from
exec.c) is made to late, so even the parent can successfully exit after
playing games on that file descriptor and the child (if setuid) is
executed under full privileges. I wrote a simple setuid binary dump
utility so far, but further implications (due to the complexity of the
execve() syscall) may be possible...


Lets illustrate the vulnerability:

paul@buggy:~> ls -l /bin/ping
- -rws--x--x    1 root     root        29680 Oct 25  2001 /bin/ping

so the setuid ping binary can be only executed by anyone, but not read.

Now we start the suid dumper (while playing with the disk on another
console like cat /usr/bin/* >/dev/null) :

paul@buggy:~> while true ; do ./suiddmp /bin/ping -c 1 127.0.0.1 ; if
test $? -eq 1 ; then exit 1 ; fi; done 2>/dev/null | grep -A5 suc

and after few seconds:

Parent success stating:
uid 0 gid 0 mode 104711 inode 9788 size 29680
PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=94 usec

- --- 127.0.0.1 ping statistics ---

paul@buggy:~> ls -l
total 7132
- -rwxr-xr-x    1 paul     users       29680 Jun 26 19:17 suid.dump
[...]

paul@buggy:~> ./suid.dump
Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]
            [-p pattern] [-s packetsize] [-t ttl] [-I interface or address]
            [-M mtu discovery hint] [-S sndbuf]
            [ -T timestamp option ] [ -Q tos ] [hop1 ...] destination


Obviously the setuid binary has been duplicated :-) (but with no setuid
flag of course).


Source also available at:

http://www.starzetz.com/paul/suiddmp.c

/ih

-------------------------------------------------------

Re: Linux v2.6.0-test1

[Alan Cox]

On Llu, 2003-07-14 at 12:50, John Bradford wrote:
> > Then you'll just have to wait a few months
> 
> Oh well, it just seems strange to be asking people to test
> 2.6.0-root-my-box, without making the consequences a bit clearer.

Its 2.6.0 locally root my box, not remotely root my box, although remote
crash bugs exist in at least one situation

Re: Linux v2.6.0-test1

[Kurt Wall]

Quoth John Bradford:
> > Then you'll just have to wait a few months
> 
> Oh well, it just seems strange to be asking people to test
> 2.6.0-root-my-box, without making the consequences a bit clearer.

And it seems equally odd actually to put an unstable kernel on a 
production system.

Kurt
-- 
He had occasional flashes of silence that made his conversation
perfectly delightful.
		-- Sydney Smith