Potenitial security hole in the kernel

Potenitial security hole in the kernel

[Vadim Lebedev]

Hi folks,

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.
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. Then sys_sigreturn restores back the context
from user mode stack...
Suppose the signal handler modifies this context frame for example by
storing into the PC slot address of the panic routine
then when handler will exit  panic will be called with obvious results.


Please CC your comments to me directly as i'm not subscibed to this list

Vadim Lebedev

Re: Potenitial security hole in the kernel

[Philip Blundell]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

>Suppose the signal handler modifies this context frame for example by
>storing into the PC slot address of the panic routine
>then when handler will exit  panic will be called with obvious results.

You can't execute panic() - or any other kernel function - in user mode.
The application can write what it likes into its sigcontext, and the worst 
that will hapenn is that it will crash itself.

p.



[-- Attachment #2: Type: application/pgp-signature, Size: 730 bytes --]

Re: Potenitial security hole in the kernel

[Vadim Lebedev]

Philip,

The point is the panic will be executed in KERNEL and NOT  user mode.
Unless i'm missing something the sigcontext contains kernel mode and not
user mode context.

Vadim

----- Original Message -----
From: "Philip Blundell" <philb@gnu.org>
To: "Vadim Lebedev" <vlebedev@aplio.fr>
Cc: <linux-kernel@vger.kernel.org>
Sent: Tuesday, May 29, 2001 12:21 AM
Subject: Re: Potenitial security hole in the kernel

Re: Potenitial security hole in the kernel

[Kurt Roeckx]

On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote:
> Hi folks,
> 
> 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.
> The problem IMO is that the signal handling code stores a processor context
> on the user-mode stack frame which is active while

And how is that different from any other function call?


Kurt

Re: Potenitial security hole in the kernel

[Vadim Lebedev]

Kurt,

Maybe i'm missing something but it seems that during execution of the signal
handler, user mode stack contains kernel mode context...
Hence the security hole

Vadim

----- Original Message -----
From: "Kurt Roeckx" <Q@ping.be>
To: "Vadim Lebedev" <vlebedev@aplio.fr>
Cc: <linux-kernel@vger.kernel.org>
Sent: Tuesday, May 29, 2001 12:29 AM
Subject: Re: Potenitial security hole in the kernel


> On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote:
> > Hi folks,
> >
> > 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.
> > The problem IMO is that the signal handling code stores a processor
context
> > on the user-mode stack frame which is active while
>
> And how is that different from any other function call?
>
>
> Kurt
>
>

Re: Potenitial security hole in the kernel

[Kurt Roeckx]

On Tue, May 29, 2001 at 12:30:03AM +0200, Vadim Lebedev wrote:
> Kurt,
> 
> Maybe i'm missing something but it seems that during execution of the signal
> handler, user mode stack contains kernel mode context...
> Hence the security hole

It's rather complicated how things work.

Both the user and kernel stack are changed.

On the user stack we add a frame from the calling function.  This
just looks a function call.

On the kernel stack we change the last frame so we "return" to
the signal handler from the kernel.

The signal handler then "returns" to the place where the process
did the system call.  You do not return to the kernel.

I hope this helps you understand things better.


Kurt

Re: Potenitial security hole in the kernel

[Brett Frankenberger]

> 
> Hi folks,
> 
> 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.
> 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. Then sys_sigreturn restores back the context
> from user mode stack...
> Suppose the signal handler modifies this context frame for example by
> storing into the PC slot address of the panic routine
> then when handler will exit  panic will be called with obvious results.
> 
> 
> Please CC your comments to me directly as i'm not subscibed to this list
> 
> Vadim Lebedev
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Potenitial security hole in the kernel

[Russell King]

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

Re: Potenitial security hole in the kernel

[Kurt Roeckx]

On Tue, May 29, 2001 at 12:12:56AM +0100, Russell King wrote:
> 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.

If that's what's happening, I have to agree with him that there
is a problem.

Why would he need to go back to kernel space at all?  He can make
it point wherever he wants.

You should never "return" from userspace to kernelspace.  The
only way to go from user space to kernel space should be by using
a system call.


Kurt

Re: Potenitial security hole in the kernel

[Kurt Roeckx]

On Tue, May 29, 2001 at 01:30:30AM +0200, Kurt Roeckx wrote:
> You should never "return" from userspace to kernelspace.  The
> only way to go from user space to kernel space should be by using
> a system call.

If you were able to return to kernel space, it already means
you're running as kernel in the first place.  There is no reason
to even do the return in the first place.


Kurt

Re: Potenitial security hole in the kernel

[Jamie Lokier]

Kurt Roeckx wrote:
> You should never "return" from userspace to kernelspace.  The
> only way to go from user space to kernel space should be by using
> a system call.

That does actually happen on x86.  The kernel puts a small code fragment
called the "trampoline" on the user mode stack, which is run when the
signal handler returns if it does a normal return.

The trampoline does the system call "sigreturn", and in there the kernel
restores the state of the user mode stack, before returning to user space.

It is possible to avoid the sigreturn system call by setting the
sa_restorer field, and I don't know why Glibc 2.2 doesn't do this.

By the way, the context stored on the stack is entirely a user space
context, however it does include some information from the kernel that
may be useful to user space, such as a page fault address.

If the user space signal handler mucks with the context on its stack,
all that happens is that "sigreturn" will end up restoring a different
user space context and continuing execution with that.  If you set
context.eip to the address of the kernel's panic() function, than the
user space program will simply crash with a SIGSEGV immediately after
"sigreturn" returns to user space.

Mucking with the context in a signal handler is even useful occasionally.

enjoy,
-- Jamie

Re: Potenitial security hole in the kernel

[Chris Wedgwood]

On Tue, May 29, 2001 at 02:32:23AM +0200, Jamie Lokier wrote:

    By the way, the context stored on the stack is entirely a user
    space context, however it does include some information from the
    kernel that may be useful to user space, such as a page fault
    address.

I actually (ab)used this for userspace paging with mprotect and
friends.... nasty hack :)



  --cw

Re: Potenitial security hole in the kernel

[Jamie Lokier]

Chris Wedgwood wrote:
>     By the way, the context stored on the stack is entirely a user
>     space context, however it does include some information from the
>     kernel that may be useful to user space, such as a page fault
>     address.
> 
> I actually (ab)used this for userspace paging with mprotect and
> friends.... nasty hack :)

Aye, and it's nice to see that Linux is relatively fast at this.
(See attached table).

Various garbage collectors do this to track dirty pages (clisp, Elk and
Hans Boehm's GC which is now part of the GCC distribution come to mind).
It's a shame this doesn't work for system calls like read(), as they
return EFAULT instead of calling the signal handler.  (It could be made
to work with some effort).

-- Jamie


   Timing measurements
   ===================

   Here are some rough timings to handle a write protection faults and
   change protection from read-only to writable, page by page in
   sequential order.  2000 pages were faulted, in a region of
   memory-mapped /dev/zero.

   The times given are the total running time divided by the number of
   pages, so they including the time to call mprotect to unprotect each
   page.  They are given in microseconds per page, and only the best
   observed time is shown.  The first column is the time to dirty a zero
   page for the first time (the OS must process a second page fault and
   COW/allocate a new page in these cases).  The second column is the
   time to unprotect a page that is already modified, which is the
   typical scenario for an incremental garbage collector.

     133MHz Pentium Linux 2.3.29           85.52      37.13     (page == 4096).
     233MHz dual Pentium II Linux 2.2.17-4 51.17      23.27     (page == 4096).
     233MHz Pentium II Linux 2.4.4         51.15      16.60     (page == 4096).
     300MHz Pentium II Linux 2.4.4         39.84      13.02     (page == 4096).
     366MHz Intel Celeron Linux 2.4.4      38.83      13.02     (page == 4096).
     400MHz Pentium II Linux 2.4.2         35.83      12.46     (page == 4096).
     600MHz Pentium III Linux 2.4.4        33.60       8.12     (page == 4096).
     600MHz Pentium III Linux 2.2.14-5     27.28       7.75     (page == 4096).
     600MHz Pentium III Linux 2.2.17-4     28.62       9.36     (page == 4096).
     PA-RISC HP-UX (which speed?)         108.44      60.34     (page == 4096).
     Sparc Ultra-1 SunOS 5.6              256.69     209.03     (page == 8192).
     Sparc SunOS 5.7 machine #1           158.26     102.26     (page == 8192).
     Sparc SunOS 5.7 machine #2           190.09     139.25     (page == 8192).