>
> On Thu, Jul 06, 2000 at 03:27:43PM -0700, Kanoj Sarcar wrote:
>
> > > Note that set_fs(KERNEL_DS) also allows the filename to be fetched from
> > > anywhere in memory including kernel space resulting in a potencial
> > > information leak or crash.
> >
> > Define how you can get a information leak or crash. I haven't looked
> > too closely, but I assume the fs/namei.c routines protect themselves.
> > In any case, most other ioctls on 64 bit platforms have this same problem
> > then.
>
> Nope, these routines don't - and can't protect themselfes. The user has
> to set_fs() correctly and that's broken in these functions.
>
> Information leak - it's not exactly a superconvenient peephole into the
> kernelspace. Assume you want to read a certain address space in memory.
> To do so you have to guess that memory's content. If you guess right
> you'll stat some random object on the fs. You can guess which one it
> was from the inode number.
Okay, so you can guess a specific filename exists at a specific location
in memory (assuming you have the permissions to do stat on that file). It
doesn't reassure you much, but it can't disturb you much either, but then
I am no security expert ...
>
> Crash - there are some hardware registers which don't like to be read.
> Point the filename argument to one of those and poof, game over. For now
> some pointer to non-decoded address space should do, you get a DBE
> exception, game over.
>
The right way to fix this is to fix the fault handlers to give SIGSEGV
to the process incurring the DBE, and move on. If the architecture is
such that receovery from a DBE is not possible, yes, then all the arch
specific code must validate user input. For sys32_newstat, that would
mean copying the user string into a temporary kernel buffer, then
setting the set_fs() before invoking sys_newstat() and pointing it to
the temporary kernel buffer.
Kanoj
> Ralf
>
|