lkml.org 
[lkml]   [1998]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectSound driver security hole?
Consider mmap'ing an ordinary file:

fd = open("some file" ...);
mmap(..., MAP_SHARED, fd, ...);
close(fd);

after the close, the file mapping is still there
and you can still access the file via the mapping.
This does certainly make sense.

Now let's look at sound. Consider a system where
sound.o is demand loaded by kerneld. A malicious app
does something like the following:

fd = open("/dev/dsp"...);
some ioctls to set various parameters
mmap(..., MAP_SHARED, fd, ...);
close(fd);

At this point, the app has mapped the DMA buffer
into its address space. The physical storage behind
the mapping was allocated by the sound driver with
get_free_pages, and it keeps this allocation around.
But since the fd is closed again, the use count
of the sound module is 0 and nothing prevents
the module from being removed. Now the malicious app
only has to wait until sound is removed by kerneld.
When sound.o gets removed, it deallocates the dma buffer,
giving the pages back to the kernel. _BUT_ the malicious
process still has a mapping to them! And nothing I can
think of prevents the kernel from reusing these pages.

Note that this is nothing Alan or myself introduced during
our recent sound driver work, this is present also in the
sound driver in 2.0.32.

Unless I haven't made a mistake in my reasoning, this is a
rather serious problem that needs to be fixed.

One possibility would be to disable that feature altogether.
I'm more and more convinced that the mmap feature is a pandora's
box for no real benefit (that couldn't be done much simpler otherwise).
But unfortunately some binary only "killer" applications
deemed important like doom and quake use it. Therefore this
might not be practical.

"The right thing to do" IMHO would be to remove the mapping
at close() time. It doesn't make sense to keep the mapping
around longer, as to use it reasonnably, you have to
be able to use the SNDCTL_DSP_GETxPTR ioctls. But with the current
mm, this does not seem to be easy to implement. One cannot simply
remember the virtual address at mmap time and then call
do_munmap at close time, as the application might
already have mapped something different to that
address space. Installing specific vm_ops and keeping
track of the usage using open/close doesn't seem to work either,
as during mmap close (of the last reference) might be followed
immediately by a (re)open.

I'm stuck. Can a mm expert enlighten me on how best to implement
the unmapping at close time?

Tom

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:3.049 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site