|
|
Subscribe / Log in / New account

DoS on x86_64

From:  Mathias Krause <minipli-AT-googlemail.com>
To:  Thomas Gleixner <tglx-AT-linutronix.de>, Ingo Molnar <mingo-AT-redhat.com>, linux-mm-AT-kvack.org
Subject:  DoS on x86_64
Date:  Thu, 28 Jan 2010 08:34:02 +0100
Cc:  security-AT-kernel.org

Hello security team,

I found by accident an reliable way to panic the kernel on an x86_64
system. Since this one can be triggered by an unprivileged user I  CCed
security@kernel.org. I also haven't found a corresponding bug on
bugzilla.kernel.org. So, what to do to trigger the bug:

1. Enable core dumps
2. Start an 32 bit program that tries to execve() an 64 bit program
3. The 64 bit program cannot be started by the kernel because it can't find
the interpreter, i.e. execve returns with an error
4. Generate a segmentation fault
5. panic

The problem seams to be located in fs/binfmt_elf.c:load_elf_binary(). It
calls SET_PERSONALITY() prior checking that the ELF interpreter is
available. This in turn makes the previously 32 bit process a 64 bit  one
which would be fine if execve() would succeed. But after the
SET_PERSONALITY() the open_exec() call fails (because it cannot find  the
interpreter) and execve() almost instantly returns with an error.  If you
now look at /proc/PID/maps you'll see, that it has the  vsyscall page
mapped which shouldn't be. But the process is not dead  yet, it's still
running. By now generating a segmentation fault and  in turn trying to
generate a core dump the kernel just dies. I  haven't yet looked into this
code but maybe you guys are much faster  than me and just can fix this
problem :)

Test case for this bug is attached. It was tested on a 2.6.26.7 and
2.6.30.10, but I may affect even older kernels. So it may be  interesting
for stable, too.


Greetings,
Mathias Krause
[2. application/octet-stream; amd64_killer.tgz]...




to post comments


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds