[lkml]   [2000]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Modprobe local root exploit
On Mon, 13 Nov 2000 23:02:10 -0600, 
Peter Samuelson <> wrote:
>[Torsten Duwe]
>> + for (p = module_name; *p; p++)
>> + {
>> + if (isalnum(*p) || *p == '_' || *p == '-')
>> + continue;
>> +
>> + return -EINVAL;
>> + }
>I think you just broke at least some versions of devfs. I don't
>remember if the feature is still around, but I know it *used* to be
>possible to request_module("/dev/foobar"), which requires '/' in the

That feature of devfs is definitely still around, it is critical to

All these patches against request_module are attacking the problem at
the wrong point. The kernel can request any module name it likes,
using any string it likes, as long as the kernel generates the name.
The real problem is when the kernel blindly accepts some user input and
passes it straight to modprobe, then the kernel is acting like a setuid
wrapper for a program that was never designed to run setuid.

At the very least, interface names which are taken directly from the
user should be prefixed with "user-interface-" before being passed to
modprobe. The sysadmin can set "alias user-interface-eth0 eth0" if
they want to use this feature. Passing the interface name unchanged is
asking for trouble, as Chris Evans pointed out, you can abuse this
"feature" to load any module.

I have nearly finished the security review of modutils, 2.3.20 will be
out later tonight. It treats the kmod environment as tainted, forces
the last parameter to be treated as a module name even if it starts
with '-', only accepts one module name and refuses 'variable=value'
strings. I find it rather ironic to be treating kernel supplied data
as tainted.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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