All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olaf Kirch <okir@caldera.de>
To: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
Cc: BUGTRAQ@SECURITYFOCUS.COM, linux-kernel@vger.kernel.org
Subject: Re: More modutils: It's probably worse.
Date: Tue, 14 Nov 2000 09:59:22 +0100	[thread overview]
Message-ID: <20001114095921.E30730@monad.caldera.de> (raw)
In-Reply-To: <Pine.LNX.4.21.0011132040160.1699-100000@ferret.lmh.ox.ac.uk> <Pine.LNX.4.21.0011132352550.31869-100000@dione.ids.pl>
In-Reply-To: <Pine.LNX.4.21.0011132352550.31869-100000@dione.ids.pl>; from lcamtuf@DIONE.IDS.PL on Tue, Nov 14, 2000 at 12:06:32AM +0100

On Tue, Nov 14, 2000 at 12:06:32AM +0100, Michal Zalewski wrote:
> Maybe I am missing something, but at least for me, modprobe
> vulnerabilities are exploitable via privledged networking services,
> nothing more.

Maybe not. ncpfs for instance has an ioctl that seems to allow
unprivileged users to specify a character set (codepage in m$speak)
that's requested via load_nls(), which in turn does a

	sprintf(buf, "nls_%s", codepage);
	request_module(buf);

Yummy.

The vfat file system contains code to obtain the charset name from
the media. Currently, the charset name is always "cp<number>", but
who knows, maybe next month will see another Microsoft extension to
ISO9660 that lets you specify an NLS name as a string?

Everyone is fixing modutils right now. Fine, but what about next
year's modutils rewrite?

This is why I keep repeating over and over again that we should make
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?

Olaf

PS: The load_nls code tries to check for buffer overflows, but
    gets it wrong:

	struct nls_table *nls;
	char	buf[40];

	if (strlen(charset) > sizeof(buf) - sizeof("nls_"))
		fail;
	sprintf(buf, "nls_%s", charset);

    This will accept charset names of up to 35 characters,
    because sizeof("nls_") is 5. This gives you a single NUL byte
    overflow. Whether it's dangerous or not depends on whether your
    compiler reserves stack space for the *nls pointer or not...

-- 
Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de    +-------------------- Why Not?! -----------------------
         UNIX, n.: Spanish manufacturer of fire extinguishers.            
-
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/

       reply	other threads:[~2000-11-14  9:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.21.0011132040160.1699-100000@ferret.lmh.ox.ac.uk>
     [not found] ` <Pine.LNX.4.21.0011132352550.31869-100000@dione.ids.pl>
2000-11-14  8:59   ` Olaf Kirch [this message]
2000-11-14 10:04     ` More modutils: It's probably worse David Schleef
2000-11-14 10:29     ` Guest section DW
2000-11-14 10:38       ` Olaf Kirch
2000-11-14 19:20     ` Ben Ford
2000-11-14 20:24       ` Michael H. Warfield
2000-11-14 19:42         ` H. Peter Anvin
2000-11-14 23:27           ` Keith Owens
2000-11-15 10:43             ` Olaf Titz
2000-11-15 11:17               ` Tim Waugh
2000-11-16  4:31               ` Keith Owens
2000-11-17  0:48             ` Rusty Russell
2000-11-14 12:47 Petr Vandrovec

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001114095921.E30730@monad.caldera.de \
    --to=okir@caldera.de \
    --cc=BUGTRAQ@SECURITYFOCUS.COM \
    --cc=lcamtuf@DIONE.IDS.PL \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.