From: Russell King <rmk@arm.linux.org.uk>
To: Vadim Lebedev <vlebedev@aplio.fr>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Potenitial security hole in the kernel
Date: Tue, 29 May 2001 00:12:56 +0100 [thread overview]
Message-ID: <20010529001256.F9203@flint.arm.linux.org.uk> (raw)
In-Reply-To: <003601c0e7bf$41953080$0101a8c0@LAP>
In-Reply-To: <003601c0e7bf$41953080$0101a8c0@LAP>; from vlebedev@aplio.fr on Mon, May 28, 2001 at 11:43:38PM +0200
On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote:
> Please correct me if i'm wrong but it seems to me that i've stumbled on
> really BIG security hole in the signal handling code.
I don't think there's problem, unless I'm missing something.
> The problem IMO is that the signal handling code stores a processor context
> on the user-mode stack frame which is active while
> the signal handler is running.
User context (defined by 'regs') is stored onto the user stack.
However, when context is restored, certain checks are done, including
making sure that the segment registers cs and ss are their user mode
versions (or'd with 3), and the processor flags are non-privileged.
This means that when the kernel does eventually return to user space,
if the user has pointed the EIP address at panic(), by the time we
jump there the processor will not be in a privileged mode, and panic()
won't do anything (you'll probably end up with a page fault caused by
the processor fetching instructions from kernel space).
However, that said, I don't know x86 in depth (I'm the ARM guy), so
don't take this as gospel, but should be sufficient to point you in
the right direction. (check the segment registers, check the eflags
register, hell, try it out for real and see what happens)!
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
next prev parent reply other threads:[~2001-05-28 23:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-28 21:43 Potenitial security hole in the kernel Vadim Lebedev
2001-05-28 22:21 ` Philip Blundell
2001-05-28 22:26 ` Vadim Lebedev
2001-05-28 22:29 ` Kurt Roeckx
2001-05-28 22:30 ` Vadim Lebedev
2001-05-28 23:15 ` Kurt Roeckx
2001-05-28 22:44 ` Brett Frankenberger
2001-05-28 23:12 ` Russell King [this message]
2001-05-28 23:30 ` Kurt Roeckx
2001-05-28 23:46 ` Kurt Roeckx
2001-05-29 0:32 ` Jamie Lokier
2001-05-29 7:35 ` Chris Wedgwood
2001-05-29 10:14 ` Jamie Lokier
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=20010529001256.F9203@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=vlebedev@aplio.fr \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox