This is being forwarded from BugTraq where there is an ongoing
discussion over a security hole in IIS based on it's unicode decoder.
This particular individual is stating that several unicode decoders,
including the one in the Linux unicode_console driver, have failed to
adhere to certain security warnings in some RFCs. This IMPLIES that
there is a potential security problem in all of them.
Anyone familiar with this who can comment on the problem in the
Linux unicode_console driver?
Mike
--
Michael H. Warfield | (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
--
Michael H. Warfield, | Voice: (678)443-6000 (678)443-6123
Senior Researcher - X-Force | Fax: (678)443-6477
Internet Security Systems, Inc. | E-Mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
6600 Peachtree Dunwoody RD NE | http://www.iss.net/
300 Embassy Row, Suite 500 | http://www.wittsend.com/mhw/
Atlanta, GA 30328 | PGP Key: 0xDF1DD471
----- Forwarded message from Cris Bailiff <[EMAIL PROTECTED]> -----
Approved-By: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i686)
X-Accept-Language: en
Date: Thu, 19 Oct 2000 21:07:57 +1100
Reply-To: Cris Bailiff <[EMAIL PROTECTED]>
From: Cris Bailiff <[EMAIL PROTECTED]>
Subject: Re: IIS %c1%1c remote command execution
To: [EMAIL PROTECTED]
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
> This is one of the vulnerabilities Bruce Schneier warned of in one of
> the past CRYPTO-GRAM isssues. The problem isn't the wrong time of
> path checking alone, but as well a poorly implemented UTF-8 decoder.
> RFC 2279 explicitly says that overlong sequences such as 0xC0 0xAF are
> invalid.
As someone often involved in reviewing and improving other peoples web code, I
have been citing the unicode security example from RFC2279 as one good reason why
web programmers must enforce 'anything not explicitly is allowed is denied'
almost since it was written. In commercial situations I have argued myself blue
in the face that the equivalent of (perl speak) s!../!!g is not good enough to
clean up filename form input parameters or other pathnames (in perl, ASP, PHP
etc.). I always end up being proved right, but it takes a lot of effort. Should
prove a bit easier from now on :-(
>
> It's a pity that a lot of UTF-8 decoders in free software fail such
> tests as well, either by design or careless implementation.
The warning in RFC 2279 hasn't been heeded by a single unicode decoder that I
have ever tested, commercial or free, including the Solaris 2.6 system libraries,
the Linux unicode_console driver, Netscape commuicator and now, obviously, IIS.
Its unclear to me whether the IIS/NT unicode decoding is performed by a system
wide library or if its custom to IIS - either way, it can potentially affect
almost any unicode aware NT application.
I have resisted upgrading various cgi and mod_perl based systems to perl5.6
because it has inbuilt (default?) unicode support, and I've no idea which
applications or perl libraries might be affected. The problem is even harder than
it looks - which sub-system, out of the http server, the perl (or ASP or PHP...)
runtime, the standard C libraries and the kernel/OS can I expect to be performing
the conversion? Which one will get it right? I think Bruce wildly understated the
problem, and I've no idea how to put the brakes on the crash dive into a
character encoding standard which seems to have no defined canonical encoding and
no obvious way of performing deterministic comparisons.
I suppose as a security professional I should be happy, looking forward to a
booming business...
Cris Bailiff
[EMAIL PROTECTED]
----- End forwarded message -----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
