[CHECKER] pcmcia user-pointer dereference

[CHECKER] pcmcia user-pointer dereference

[Hollis Blanchard]

On Mon, 12 May 2003 Junfeng wrote:
>
> here is a detailed explanation in case the warnning itself isn't clear:
>
> 1. ds_ioctl is assigned to file_operantions.ioctl
> so its argument 'arg' is tainted. verify_area are
> also called on 'arg', which confirms.
>
> 2. copy_from_user (&buf, arg, _) copies in the content of arg
>
> 3. buf.win_info.handle is thus a user provided pointer.
>
> 4. pcmcia_get_mem_page dereferences its first parameter, in this case
> buf.win_info.handle

I contacted David Hinds about this; the behavior is by design. User 
space passes in a pointer to a kernel data structure, and the kernel 
verifies it by checking a magic number in that structure.

It seems possible to perform some activity from user space to get the 
magic number into (any) kernel memory, then iterate over kernel space 
by passing pointers to the pcmcia ds_ioctl() until you manage to 
corrupt something. But I'm not really a security guy...

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [CHECKER] pcmcia user-pointer dereference

[David Hinds]

On Thu, May 29, 2003 at 04:11:19PM -0500, Hollis Blanchard wrote:
> 
> I contacted David Hinds about this; the behavior is by design. User 
> space passes in a pointer to a kernel data structure, and the kernel 
> verifies it by checking a magic number in that structure.
> 
> It seems possible to perform some activity from user space to get the 
> magic number into (any) kernel memory, then iterate over kernel space 
> by passing pointers to the pcmcia ds_ioctl() until you manage to 
> corrupt something. But I'm not really a security guy...

This ioctl just returns the contents of another field of that same
data structure that contains the magic number.  So, a malicious user
could, if they were able to cause another kernel data structure to
contain that magic number and they knew the address of that data
structure, use this ioctl to read out the contents of an adjacent
field that might not have otherwise been user-accessable.  You could
not corrupt anything with this ioctl.

The kernel pointer could be done away with, by instead using an
integer to represent the position in a linked list of the target data
structure, which would be the best fix, if someone wants to code it.

- Dave

Re: [CHECKER] pcmcia user-pointer dereference

[Hollis Blanchard]

On Thursday, May 29, 2003, at 16:22 US/Central, David Hinds wrote:

> On Thu, May 29, 2003 at 04:11:19PM -0500, Hollis Blanchard wrote:
>>
>> I contacted David Hinds about this; the behavior is by design. User
>> space passes in a pointer to a kernel data structure, and the kernel
>> verifies it by checking a magic number in that structure.
>>
>> It seems possible to perform some activity from user space to get the
>> magic number into (any) kernel memory, then iterate over kernel space
>> by passing pointers to the pcmcia ds_ioctl() until you manage to
>> corrupt something. But I'm not really a security guy...
>
> This ioctl just returns the contents of another field of that same
> data structure that contains the magic number.  So, a malicious user
> could, if they were able to cause another kernel data structure to
> contain that magic number and they knew the address of that data
> structure, use this ioctl to read out the contents of an adjacent
> field that might not have otherwise been user-accessable.  You could
> not corrupt anything with this ioctl.

That's true for pcmcia_get_mem_page. However pcmcia_map_mem_page writes 
into the structure it verifies. I think pcmcia_get_first/next_window 
could also be used to corrupt memory (*handle = win in 
pcmcia_get_window).

> The kernel pointer could be done away with, by instead using an
> integer to represent the position in a linked list of the target data
> structure, which would be the best fix, if someone wants to code it.

That does sound like a better idea. :)

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [CHECKER] pcmcia user-pointer dereference

[David Hinds]

On Thu, May 29, 2003 at 04:30:54PM -0500, Hollis Blanchard wrote:
> 
> That's true for pcmcia_get_mem_page. However pcmcia_map_mem_page writes 
> into the structure it verifies. I think pcmcia_get_first/next_window 
> could also be used to corrupt memory (*handle = win in 
> pcmcia_get_window).

The map_mem_page ioctl can only be used by root.  The get_*_window
ioctl's can't corrupt anything because they, like get_mem_page, only
read the target data structures.

-- Dave

Re: [CHECKER] pcmcia user-pointer dereference

[Alan Cox]

On Iau, 2003-05-29 at 22:36, David Hinds wrote:
> The map_mem_page ioctl can only be used by root.  The get_*_window
> ioctl's can't corrupt anything because they, like get_mem_page, only
> read the target data structures.

Which if the passed address is something like a PCI DMA trigger register
isn't going to be too pretty

Re: [CHECKER] pcmcia user-pointer dereference

[Alan Cox]

On Iau, 2003-05-29 at 22:11, Hollis Blanchard wrote:
> I contacted David Hinds about this; the behavior is by design. User 
> space passes in a pointer to a kernel data structure, and the kernel 
> verifies it by checking a magic number in that structure.
> 
> It seems possible to perform some activity from user space to get the 
> magic number into (any) kernel memory, then iterate over kernel space 
> by passing pointers to the pcmcia ds_ioctl() until you manage to 
> corrupt something. But I'm not really a security guy...

That isnt safe - the pointer dereference could hit anything

Re: [CHECKER] pcmcia user-pointer dereference

[David Wagner]

Hollis Blanchard  wrote:
>I contacted David Hinds about this; the behavior is by design. User 
>space passes in a pointer to a kernel data structure, and the kernel 
>verifies it by checking a magic number in that structure.

As you and others point out, this isn't safe, in general.  What if an
attacker can get the magic number at the required offset from interesting
memory location in kernel space?  This seems like a plausible assumption.
Then the attacker can read secret kernel memory, which is bad.

This sounds scary.  I don't know whether there are any exploitable
attacks here, but based on what you said, it seems strange to take this
kind of risk.

Sounds to me like it should be treated as a security hole.  Good catch,
Junfeng et al!

Re: [CHECKER] pcmcia user-pointer dereference

[Mike Playle]

On Fri, May 30, 2003 at 01:40:27PM +0100, David Hinds wrote:
> On Thu, May 29, 2003 at 04:30:54PM -0500, Hollis Blanchard wrote:
> > 
> > That's true for pcmcia_get_mem_page. However pcmcia_map_mem_page writes 
> > into the structure it verifies. I think pcmcia_get_first/next_window 
> > could also be used to corrupt memory (*handle = win in 
> > pcmcia_get_window).
> 
> The map_mem_page ioctl can only be used by root.  The get_*_window
> ioctl's can't corrupt anything because they, like get_mem_page, only
> read the target data structures.
> 
> -- Dave

What about memory-mapped IO registers? Can this ioctl be used to cause
an unwanted read from a memory mapped device?

-- 
Mike