Local root exploit with kmod and modutils > 2.1.121

Local root exploit with kmod and modutils > 2.1.121

[Keith Owens]

On Mon, 13 Nov 2000 20:23:07 +0000 (GMT), 
Chris Evans <chris@scary.beasts.org> wrote:
>Either the kernel or modprobe needs to treat the module name with
>_extreme_ distrust, and I see no evidence of that.

Agreed.  modprobe was not designed to run suid.  Calling modprobe from
request_module has the same effect as running suid.  dev_load() can
take the interface name and pass it to modprobe unchanged and modprobe
does not verify its input, it trusts root/kernel.

>Without this distrust, there is a huge amount of code a malicious user can
>play with. Looking at meta_expand() and split_line() in modprobe, there
>are buffer overflows all over the place (lucky an interface name can only
>be 15 characters!). Worse, user-defined input can be passed to sprawling
>interfaces such as glob() and wordexp().

The buffer overflows are not as bad as they look, most of them are on
malloc strings which have calculated sizes.  There are some strcat
calls that are suspect and I have fixed those in my tree, and replaced
the system() calls with safe equivalents.  But that does not fix the
other problems.

(1) Some user defined input is passed directly through the kernel to
    modprobe running as root.

(2) Current modprobe has no way of telling that it was invoked from the
    kernel instead of by root so it cannot apply different verification
    to its parameters for kmod input.

(3) modprobe applies filename expansion to the user supplied input as
    well as the paths from modules.conf.  The former is tainted, the
    latter is not but they are joined together in modprobe.  This is
    fine for root, terrible for kmod.

The only secure fix I can see is to add SAFEMODE=1 to modprobe's
environment and change exec_modprobe.

static char * envp[] = { "HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", "SAFEMODE=1", NULL };

In safemode, modprobe will treat its last argument as a module name,
even if it starts with '-'.  Also in safemode, no filename expansion
will be applied to the module name, filename expansion will still be
applied to paths in /etc/modules.conf.

To cater for older kernels (including 2.2), modprobe will treat an
environment of exactly this, and no more
"HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin"
as requiring safemode.  Why add SAFEMODE at all?  In case we want to
change the environment in future.

Chris Evans raised another point.

(4) Passing user defined input directly through the kernel to modprobe
    does more than expose modprobe to suspect input.  If a user can
    find a program that the kernel trusts and whose input is passed
    straight through then they can load any module.  Controlled loading
    with kernel generated names like net-pf-10, eth0 is fine,
    uncontrolled loading of any module name from user input is not.
    This is a pure kernel problem.

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

Re: Local root exploit with kmod and modutils > 2.1.121

[Alan Cox]

> request_module has the same effect as running suid.  dev_load() can
> take the interface name and pass it to modprobe unchanged and modprobe
> does not verify its input, it trusts root/kernel.

Then dev_load is being called the wrong way. In older kernels we explicitly
only did a dev_load with user passed names providing suser() was true.

Alan

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

Re: Local root exploit with kmod and modutils > 2.1.121

[kuznet]

Hello!

> > request_module has the same effect as running suid.  dev_load() can
> > take the interface name and pass it to modprobe unchanged and modprobe
> > does not verify its input, it trusts root/kernel.
> 
> Then dev_load is being called the wrong way. In older kernels we explicitly
> only did a dev_load with user passed names providing suser() was true.

It checks CAP_SYS_MODULE nowadays.

Which does not look good by the way, it is function of request_module(),
rather than of caller.

Alexey
-
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/

Re: Local root exploit with kmod and modutils > 2.1.121

[Alan Cox]

> It checks CAP_SYS_MODULE nowadays.
> 
> Which does not look good by the way, it is function of request_module(),
> rather than of caller.

Only the caller knows if the data is tainted. Thus only the caller can decide

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

Re: Local root exploit with kmod and modutils > 2.1.121

[kuznet]

Hello!

> Only the caller knows if the data is tainted. Thus only the caller can decide

Sorry? What data? What to decide?

Device name of &|&|&|&|&|& is absolutely legal, nicely loking name.
dev.c _wants_ to load such device and it is problem of kmod,
if it is not able to make this.

It is the first. And the second: each user is allowed to refer to this device.
And it is problem of module to allow to load corresponding module or not
to allow this.

It means that test for CAP_SYS_MODULE is illegal, moving pure policy
issue to improper place.

Alexey
-
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/

Re: Local root exploit with kmod and modutils > 2.1.121

[Alan Cox]

> It is the first. And the second: each user is allowed to refer to this device.
> And it is problem of module to allow to load corresponding module or not
> to allow this.

Not so.

> It means that test for CAP_SYS_MODULE is illegal, moving pure policy
> issue to improper place.

Definitely not so

What matters is whether the user is requesting a module or the kernel is 
choosing to load a module. In the former case where the user can influence the
module name then you need to check CAP_SYS_MODULE in the latter you do not
care.

Alan
-
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/

Re: Local root exploit with kmod and modutils > 2.1.121

[kuznet]

Hello!

> > It means that test for CAP_SYS_MODULE is illegal, moving pure policy
> > issue to improper place.
> 
> Definitely not so
> 
> What matters is whether the user is requesting a module or the kernel is 
> choosing to load a module. In the former case where the user can influence the
> module name then you need to check CAP_SYS_MODULE in the latter you do not
> care.

Alan, I honestly peered to this paragraph of text for 10 minutes. 8)8)

It is funny, but I managed to compile it only as:
"dev_load(i.e. you) need not take of care of this".

I.e. exactly the thing which I said. 8)

Alexey
-
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/

[PATCH] Re: Local root exploit with kmod and modutils > 2.1.121

[Xavier Bestel]

Hi,

as modprobe (insmod) seems to have POSIX args handling, we should perhaps add "--"
to the modprobe cmdline, in order to stop further args processing, and to avoid
mixing a textual argument with an option.
BTW, it should perhaps be generalized.

Xav


--- linux-2.4-test10/kernel/kmod.c	Tue Sep 26 01:18:55 2000
+++ linux/kernel/kmod.c	Thu Nov 16 19:57:45 2000
@@ -133,7 +133,7 @@
 static int exec_modprobe(void * module_name)
 {
 	static char * envp[] = { "HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL };
-	char *argv[] = { modprobe_path, "-s", "-k", (char*)module_name, NULL };
+	char *argv[] = { modprobe_path, "-s", "-k", "--", (char*)module_name, NULL };
 	int ret;
 
 	ret = exec_usermodehelper(modprobe_path, argv, envp);


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

Re: Local root exploit with kmod and modutils > 2.1.121

[Keith Owens]

On Thu, 16 Nov 2000 16:04:23 +0000 (GMT), 
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> request_module has the same effect as running suid.  dev_load() can
>> take the interface name and pass it to modprobe unchanged and modprobe
>> does not verify its input, it trusts root/kernel.
>
>Then dev_load is being called the wrong way. In older kernels we explicitly
>only did a dev_load with user passed names providing suser() was true.

ping6 -I module_name.  ping6 is setuid, it passes the interface name to
the kernel while it holds root privileges, suser() == true.  It is
not reasonable to expect setuid programs to know that Linux does
something special with some parameters when no other O/S has that
"feature".

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

Re: Local root exploit with kmod and modutils > 2.1.121

[Alan Cox]

> >Then dev_load is being called the wrong way. In older kernels we explicitly
> >only did a dev_load with user passed names providing suser() was true.
> 
> ping6 -I module_name.  ping6 is setuid, it passes the interface name to
> the kernel while it holds root privileges, suser() == true.  It is
> not reasonable to expect setuid programs to know that Linux does
> something special with some parameters when no other O/S has that
> "feature".

ping6 shouldnt be running with CAP_SYS_MODULE in the first place

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

[PATCH] Re: Local root exploit with kmod and modutils > 2.1.121

[Xavier Bestel]

Hi,

as modprobe (insmod) args parsing seems POSIX compliant, we should put a
"--" before
what should be interpreted only as a textual argument, not as an option.
This is a lot safer: whatever is passed, modprobe will take it as a module
name.

--- linux-2.4.0-test10/kernel/kmod.c    Tue Sep 26 01:18:55 2000
+++ linux/kernel/kmod.c Thu Nov 16 19:57:45 2000
@@ -133,7 +133,7 @@
 static int exec_modprobe(void * module_name)
 {
        static char * envp[] = { "HOME=/", "TERM=linux",
"PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL };
-       char *argv[] = { modprobe_path, "-s", "-k", (char*)module_name,
NULL };
+       char *argv[] = { modprobe_path, "-s", "-k", "--",
(char*)module_name, NULL };
        int ret;

        ret = exec_usermodehelper(modprobe_path, argv, envp);
-
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/

Re: [PATCH] Re: Local root exploit with kmod and modutils > 2.1.121

[Keith Owens]

On Thu, 16 Nov 2000 22:21:52 +0100, 
Xavier Bestel <xavier.bestel@free.fr> wrote:
>as modprobe (insmod) args parsing seems POSIX compliant, we should put a
>"--" before
>what should be interpreted only as a textual argument, not as an option.
>This is a lot safer: whatever is passed, modprobe will take it as a module
>name.

That only solves one of the two exploit methods.  modutils 2.3.20
solves both without any kernel changes, mainly so it fixes the problem
on all kernels, including 2.2.

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

Re: [PATCH] Re: Local root exploit with kmod and modutils > 2.1.121

[H. Peter Anvin]

Followup to:  <5529.974412016@ocs3.ocs-net>
By author:    Keith Owens <kaos@ocs.com.au>
In newsgroup: linux.dev.kernel
>
> On Thu, 16 Nov 2000 22:21:52 +0100, 
> Xavier Bestel <xavier.bestel@free.fr> wrote:
> >as modprobe (insmod) args parsing seems POSIX compliant, we should put a
> >"--" before
> >what should be interpreted only as a textual argument, not as an option.
> >This is a lot safer: whatever is passed, modprobe will take it as a module
> >name.
> 
> That only solves one of the two exploit methods.  modutils 2.3.20
> solves both without any kernel changes, mainly so it fixes the problem
> on all kernels, including 2.2.
> 

However, the kernel change is probably still a good idea.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/