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
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
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
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
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
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
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
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!