From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Chase Venters <chase.venters@clientec.com>
Cc: SHELLCODE Security Research <GoodFellas@shellcode.com.ar>,
linux-kernel@vger.kernel.org
Subject: Re: Registration Weakness in Linux Kernel's Binary formats
Date: Tue, 03 Oct 2006 23:54:14 +0100 [thread overview]
Message-ID: <1159916054.17553.92.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0610031645340.3514@turbotaz.ourhouse>
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
next prev parent reply other threads:[~2006-10-03 22:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-03 19:13 Registration Weakness in Linux Kernel's Binary formats SHELLCODE Security Research
2006-10-03 21:48 ` Chase Venters
2006-10-03 22:54 ` Alan Cox [this message]
2006-10-04 3:49 ` Chase Venters
-- strict thread matches above, loose matches on Subject: below --
2006-10-03 21:25 Fwd: " Bráulio Oliveira
2006-10-03 21:53 ` Kyle Moffett
2006-10-03 21:59 ` Stephen Hemminger
2006-10-03 22:28 ` Valdis.Kletnieks
2006-10-04 4:08 Julio Auto
2006-10-04 4:25 ` Chase Venters
2006-10-04 14:55 ` Alan Cox
2006-10-04 14:34 ` Xavier Bestel
2006-10-04 5:40 ` Kyle Moffett
2006-10-04 7:11 ` Peter Read
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1159916054.17553.92.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=GoodFellas@shellcode.com.ar \
--cc=chase.venters@clientec.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.