Re: Modprobe local root exploit

[Keith Owens <kaos@ocs.com.au>]

On Mon, 13 Nov 2000 23:02:10 -0600, 
Peter Samuelson <peter@cadcamlab.org> 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
>name.

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

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/