Followup to: <[email protected]>
By author: "Michael H. Warfield" <[email protected]>
In newsgroup: linux.dev.kernel
>
> Oh, I hate to add to a remark like that (OK, I lied, I love
> trollbait...)
>
> On Tue, Nov 14, 2000 at 11:20:35AM -0800, Ben Ford wrote:
> > Olaf Kirch wrote:
>
> > > sure request_module _does_not_ accept funky module names. Why allow
> > > people to shoot themselves (and, by extension, all other Linux users
> > > out there) in the foot?
>
> > I thought that was the whole purpose of Unix/Linux?
>
> True! Very true! Unix/Linux requires that the user shoot
> themselves in the foot. Windows automates that process and does it
> for the user, thus making foot shooting user friendly. :-)
>
Seriously, though, I don't see any reason modprobe shouldn't accept
funky filenames. There is a standard way to do that, which is to have
an argument consisting of the string "--"; this indicates that any
further arguments should be considered filenames and not options.
For example:
rm -- -foo # Delete a file named "-foo"
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On 14 Nov 2000 11:42:42 -0800,
"H. Peter Anvin" <[email protected]> wrote:
>Seriously, though, I don't see any reason modprobe shouldn't accept
>funky filenames. There is a standard way to do that, which is to have
>an argument consisting of the string "--"; this indicates that any
>further arguments should be considered filenames and not options.
The original exploit had nothing to do with filenames masquerading as
options, it was: ping6 -I ';chmod o+w .'. Then somebody pointed out
that -I '-C/my/config/file' could be abused as well. '--' fixes the
second exploit but not the first.
The problem is the combination of kernel code passing user space
parameters through unchanged (promoting user input to root) plus the
modprobe meta expansion algorithm. By treating the last parameter from
the kernel as a tainted module name (not an option) and suppressing
meta expansion on tainted parameters, modprobe removes enough of the
problem to be safe.
My changes to modprobe do nothing about this: "ping6 -I binfmt_misc".
That construct lets a user load any module. However that is a pure
kernel problem which needs to be fixed by the developers who call
request_module.
> The original exploit had nothing to do with filenames masquerading as
> options, it was: ping6 -I ';chmod o+w .'. Then somebody pointed out
Why is there any reason that a shell should be invoked anywhere in the
request_module->modprobe->insmod chain?
If implemented correctly, this attack should have the same result as
insmod ';chmod o+w .' (and it should not matter if it gets renamed so
that the actual command executed is insmod 'netdevice-;chmod o+w .')
> The problem is the combination of kernel code passing user space
> parameters through unchanged (promoting user input to root)
Which means that all parts of the chain which deal with possible user
input in elevated privilege mode must do input validation. This means
the kernel _and_ modprobe in my book.
> plus the
> modprobe meta expansion algorithm.
and I see no reason why modprobe should do any such thing, apart from
configurations dealt with in modules.conf anyway.
Olaf
On Wed, Nov 15, 2000 at 11:43:54AM +0100, Olaf Titz wrote:
> > plus the
> > modprobe meta expansion algorithm.
>
> and I see no reason why modprobe should do any such thing, apart from
> configurations dealt with in modules.conf anyway.
If it helps, wordexp has a flag to prevent command substitutions from
occuring.
Tim.
*/
On Wed, 15 Nov 2000 11:43:54 +0100,
>Why is there any reason that a shell should be invoked anywhere in the
>request_module->modprobe->insmod chain?
>If implemented correctly, this attack should have the same result as
>insmod ';chmod o+w .' (and it should not matter if it gets renamed so
>that the actual command executed is insmod 'netdevice-;chmod o+w .')
You are confusing two different problems. The meta expansion problem
means ;chmod o+w .' does nasty things to your system. The other
problem is that any user can load any module by ping6 -I module_name.
>> plus the
>> modprobe meta expansion algorithm.
>
>and I see no reason why modprobe should do any such thing, apart from
>configurations dealt with in modules.conf anyway.
modutils 2.3.20 only does meta expansion for entries in the config
file, not for input from the command line. That fixes the first
problem but does nothing about the second. The only way to fix the
second problem is by always adding a prefix to the user input before
passing it to modprobe, that fix has to be in the kernel, not modutils.
In message <[email protected]> you write:
> On 14 Nov 2000 11:42:42 -0800,
> "H. Peter Anvin" <[email protected]> wrote:
> >Seriously, though, I don't see any reason modprobe shouldn't accept
> >funky filenames. There is a standard way to do that, which is to have
> >an argument consisting of the string "--"; this indicates that any
> >further arguments should be considered filenames and not options.
>
> The original exploit had nothing to do with filenames masquerading as
> options, it was: ping6 -I ';chmod o+w .'. Then somebody pointed out
> that -I '-C/my/config/file' could be abused as well. '--' fixes the
> second exploit but not the first.
Yes, modprobe code is stupid (execing insmod without "--"). Of
course, the passing of flags to modprobe is pretty broken too (the
kernel shouldn't assume anything about modprobe, otherwise why bother
with the /proc entry?)
But the kernel should be fixed for future:
--- working-2.4.0-test11-5/kernel/kmod.c.~1~ Wed Oct 4 15:17:12 2000
+++ working-2.4.0-test11-5/kernel/kmod.c Fri Nov 17 11:44:09 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);
--
Hacking time.