Hello,
The present document aims to demonstrate a design weakness found in the
handling of simply
linked lists used to register binary formats handled by
Linux kernel, and affects all the kernel families
(2.0/2.2/2.4/2.6), allowing the insertion of infection modules in
kernel space that can be used by malicious users to create infection
tools, for example rootkits.
POC, details and proposed solution at:
English version: http://www.shellcode.com.ar/docz/binfmt-en.pdf
Spanish version: http://www.shellcode.com.ar/docz/binfmt-es.pdf
regards,
--
SHELLCODE Security Research TEAM
[email protected]
http://www.shellcode.com.ar
On Tue, 3 Oct 2006, SHELLCODE Security Research wrote:
> Hello,
> The present document aims to demonstrate a design weakness found in the
> handling of simply
> linked lists used to register binary formats handled by
> Linux kernel, and affects all the kernel families
> (2.0/2.2/2.4/2.6), allowing the insertion of infection modules in
> kernel space that can be used by malicious users to create infection
> tools, for example rootkits.
So the problem you find is that newly registered binfmts are inserted into
the front of the binfmt list instead of the rear, and this means that a
binfmt handler can slip in at runtime at run quietly before any other
handler?
I'm not sure I see this as a real problem. If you can load a module into
kernel space and access arbitrary symbols (not to mention run in ring 0) I
think you can do a lot more than just hide out on the binfmt list.
Am I missing something?
> POC, details and proposed solution at:
> English version: http://www.shellcode.com.ar/docz/binfmt-en.pdf
> Spanish version: http://www.shellcode.com.ar/docz/binfmt-es.pdf
>
> regards,
> --
> SHELLCODE Security Research TEAM
> [email protected]
> http://www.shellcode.com.ar
>
Thanks,
Chase
Ar Maw, 2006-10-03 am 16:48 -0500, ysgrifennodd Chase Venters:
> So the problem you find is that newly registered binfmts are inserted into
> the front of the binfmt list instead of the rear, and this means that a
> binfmt handler can slip in at runtime at run quietly before any other
> handler?
This is a feature as anyone trying to debug versions of the elf loader
could would find out quite fast.
>
> I'm not sure I see this as a real problem. If you can load a module into
> kernel space and access arbitrary symbols (not to mention run in ring 0) I
> think you can do a lot more than just hide out on the binfmt list.
>
> Am I missing something?
Don't think so. At the point you can load code into the kernel you can
replace any code anyway.
NOTABUG
Alan
On Tuesday 03 October 2006 14:12, SHELLCODE Security Research wrote:
> Hello,
> The present document aims to demonstrate a design weakness found in the
> handling of simply
> linked lists used to register binary formats handled by
> Linux kernel, and affects all the kernel families
> (2.0/2.2/2.4/2.6), allowing the insertion of infection modules in
> kernel space that can be used by malicious users to create infection
> tools, for example rootkits.
Yay, you've been Slashdotted!
Question: Why did you personally submit this to Slashdot when it is absolutely
clear that the observation is akin to figuring out a process can call fork()
and exec() and become "/bin/rm" with an argv of "/bin/rm", "-rf", and "*"?
Is this what you call good marketing?
> POC, details and proposed solution at:
> English version: http://www.shellcode.com.ar/docz/binfmt-en.pdf
> Spanish version: http://www.shellcode.com.ar/docz/binfmt-es.pdf
>
Thanks,
Chase