[17250] in bugtraq
Re: IIS %c1%1c remote command execution
daemon@ATHENA.MIT.EDU (Florian Weimer)
Wed Oct 18 10:07:11 2000
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <tglmvmz3ek.fsf@mercury.rus.uni-stuttgart.de>
Date: Wed, 18 Oct 2000 15:26:27 +0200
Reply-To: Florian Weimer <Florian.Weimer@RUS.UNI-STUTTGART.DE>
From: Florian Weimer <Florian.Weimer@RUS.UNI-STUTTGART.DE>
X-To: rain forest puppy <rfp@WIRETRIP.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: rain forest puppy's message of "Tue, 17 Oct 2000 09:48:03 -0500"
rain forest puppy <rfp@WIRETRIP.NET> writes:
> So is it UNICODE based? Yes. %c0%af and %c1%9c are overlong UNICODE
> representations for '/' and '\'. There may even be longer (3+ byte)
> overlong representations too. IIS seems to decode UNICODE at the wrong
> instance (after path checking, rather than before). I didn't learn this
> until later on (after doing some research on UTF-8).
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.
Markus Kuhn's UTF-8 stress test file contains some tests covering such
problems. It's available at:
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt
(I just checked, and Netscape Communicator 4.75 appears to have a
broken UTF-8 decoder, too.)
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.
--
Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
