BUG REPORT: User/Kernel Pointer bug in sys_poll

BUG REPORT: User/Kernel Pointer bug in sys_poll

[Sorav Bansal]

Package: linux-kernel-src
Version: 2.4.27

Description: User/Kernel pointer bug/security holl in sys_poll

I think, there is a potential bug/security hole in the sys_poll system
call.

In sys_poll, the user pointer ufds (first arg to sys_poll) goes through
copy_from_user. Then __put_user is called on &ufds->revents.

Since copy_from_user is a read access and __put_user is a write access,
the first call does not verify write-access to ufds. This can be exploited
by a malicious user on a 386 machine (where write-protection in
kernel mode is not enabled .i.e. CONFIG_X86_WP_WORKS_OK is undef).

It seems that this bug can be corrected by replacing the two __put_user
calls in sys_poll by put_user. I am using the latest kernel from
kernel.org .i.e. linux-2.4.27

thanks,
Sorav

Re: BUG REPORT: User/Kernel Pointer bug in sys_poll

[Sorav Bansal]

Older x86 architectures (386 and before) allow the kernel to write to any
user location regardless of the write-protect bits.

Hence, with this bug, a user program could write to the write-protected
region of its address space by calling the sys_poll system call and
setting the address and data values appropriately.

An example where this could be exploited is an application running
third-party software. The application may want to write-protect its code
region but with this bug, the third party software will be able to
overwrite write-protected regions by calling sys_poll.

Sorav

On Wed, 27 Oct 2004, Tace wrote:

> sorry but I don't understand, why would it be a
> problem?
>
> --- Sorav Bansal <sbansal@stanford.edu> wrote:
>
> >
> > Package: linux-kernel-src
> > Version: 2.4.27
> >
> > Description: User/Kernel pointer bug/security holl
> > in sys_poll
> >
> > I think, there is a potential bug/security hole in
> > the sys_poll system
> > call.
> >
> > In sys_poll, the user pointer ufds (first arg to
> > sys_poll) goes through
> > copy_from_user. Then __put_user is called on
> > &ufds->revents.
> >
> > Since copy_from_user is a read access and __put_user
> > is a write access,
> > the first call does not verify write-access to ufds.
> > This can be exploited
> > by a malicious user on a 386 machine (where
> > write-protection in
> > kernel mode is not enabled .i.e.
> > CONFIG_X86_WP_WORKS_OK is undef).
> >
> > It seems that this bug can be corrected by replacing
> > the two __put_user
> > calls in sys_poll by put_user. I am using the latest
> > kernel from
> > kernel.org .i.e. linux-2.4.27
> >
> > thanks,
> > Sorav
> >
> > -
> > 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/
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
> http://promotions.yahoo.com/new_mail
>

Re: BUG REPORT: User/Kernel Pointer bug in sys_poll

[Andi Kleen]

Sorav Bansal <sbansal@stanford.edu> writes:

> Older x86 architectures (386 and before) allow the kernel to write to any
> user location regardless of the write-protect bits.

Actually it's only some early steppings of 386 and Linux never ran on
a 286 or earlier. I think the best would be to just ignore it, the affected
user base is very likely zero or very near it. I suspect the 
probability of one of these machines still used as a multiuser
machine is very definitely nil.

Cue is that 386 got occassionally broken, and it often took 
months to be noticed.

These machines already have other exploitable bugs BTW that have been
ignored for a long time and only been fixed in 2.6.

So just ignore it. It's a non issue, really.

-Andi

Re: BUG REPORT: User/Kernel Pointer bug in sys_poll

[Denis Vlasenko]

On Thursday 28 October 2004 09:32, Andi Kleen wrote:
> Sorav Bansal <sbansal@stanford.edu> writes:
> 
> > Older x86 architectures (386 and before) allow the kernel to write to any
> > user location regardless of the write-protect bits.
> 
> Actually it's only some early steppings of 386 and Linux never ran on
> a 286 or earlier. I think the best would be to just ignore it, the affected
> user base is very likely zero or very near it. I suspect the 
> probability of one of these machines still used as a multiuser
> machine is very definitely nil.

People ran Linux on 8086 (DragonLinux,ELKS iirc).

I admire their level of madness, but, really,
it is not useful to spend time on such things.

My personal bottom line of supported hw is 486.
--
vda

Re: BUG REPORT: User/Kernel Pointer bug in sys_poll

[Andrew Morton]

Sorav Bansal <sbansal@stanford.edu> wrote:
>
> Older x86 architectures (386 and before) allow the kernel to write to any
>  user location regardless of the write-protect bits.
> 
>  Hence, with this bug, a user program could write to the write-protected
>  region of its address space by calling the sys_poll system call and
>  setting the address and data values appropriately.

Nope.  The only significant difference between copy_from_user() and
__put_user() here is that copy_from_user() checks that the address is not
in the 0xc0000000-0xffffffff range.  __put_user() skips that check.

So

	if (copy_from_user(kaddr, addr, n))
		fail();
	__put_user(42, addr);

is safe.  We know that the address is in the 0x00000000-0xbfffffff range by
the time we call __put_user().  And if the page at *addr it not writeable
the kernel will take a fault.

So I see no hole.  But I wouldn't have coded it that way...

Re: BUG REPORT: User/Kernel Pointer bug in sys_poll

[Sorav Bansal]

> Nope.  The only significant difference between copy_from_user() and
> __put_user() here is that copy_from_user() checks that the address is not
> in the 0xc0000000-0xffffffff range.  __put_user() skips that check.

This is true for modern x86 architectures.

For some older 386's, where Write-Protect does not work okay, there is a
difference between put_user() and copy_from_user(). put_user() performs an
extra check called verify_write() in addition to checking the address
range. Hence, the following code may be unsafe when running on those
machines.

> So
>
> 	if (copy_from_user(kaddr, addr, n))
> 		fail();
> 	__put_user(42, addr);
>
> is safe.  We know that the address is in the 0x00000000-0xbfffffff range by
> the time we call __put_user().  And if the page at *addr it not writeable
> the kernel will take a fault.

In older 386's, the kernel will NOT take a fault and write to the
write-protected region.

But then, maybe 386 is too old to worry about :-)

Re: BUG REPORT: User/Kernel Pointer bug in sys_poll

[Alan Cox]

On Iau, 2004-10-28 at 10:48, Andrew Morton wrote:
> is safe.  We know that the address is in the 0x00000000-0xbfffffff range by
> the time we call __put_user().  And if the page at *addr it not writeable
> the kernel will take a fault.
> 
> So I see no hole.  But I wouldn't have coded it that way...

On x86 maybe. I think he's right in the sense that we may have a non x86
platform that this is not safe on.