full-disclosure - Microsoft IIS SSL PCT vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <200404252045.02151.amic@beyondsecurity.com>
From: amic at beyondsecurity.com (Ami Chayun)
Subject: Microsoft IIS SSL PCT vulnerability

On Saturday 24 April 2004 22:32, kquest@...layer.com wrote:
> I just thought it would be nice to have a little bit more analysis for this
> vulnerability...
> with all these exploits coming out because everybody probably wants to know
> how to stop what's out now and what will follow. To do that we need to
> understand
> how the vulnerability is triggered. Unfortunately I don't have time to do a
> complete
> analysis, but here's a simplified (and incomplete) version:
>
> The exploits seem to be using CLIENT HELLO packets...,
> but they don't seem to be PCT client hello packets.
>
> PCT CLIENT HELLO packet format:
>
> LEN (2 or 3 bytes) <-- 0x80 0x62 (in this case it's two bytes... you know
> that it's two bytes bc MSB is set)
> MSG_TYPE (1 byte) <-- 0x01 for CLIENT HELLO
> CLIENT_VER (2 bytes) <-- 0x02 0xbd
> PAD (1 byte)
> SESSION_ID_DATA (32 bytes)
> CHALLENGE_DATA (32 bytes)
> OFFSET (2 bytes)
> ...
> the rest goes here....
>
> If you look at the exploits though, they don't seem to match the format.
> If you look at the client version it doesn't appear to be PCT1 ( 0x80
> 0x01). Instead it's 0x02 0xbd. What is this magic number? Well, it appears
> that it's not magic. For the vulnerability to be triggered, this number
> needs to have either 0x0100 or 0x0200 bits set... (but not at the same
> time). The other values don't matter, so all these values will be good
> enough too: 0x0201, 0x0202, 0x0204, 0x0101, 0x0200, 0x0100, 0x02ff, 0x01ff,
> etc.
>
> Next, let's look at the length field (0x8062). It says that the
> SSL/PCT/whatever
> message is suppose to be 98 bytes, while the actual packet is 326 bytes.
> It seems that the key thing here is that the actual length is greater than
> the
> declared length. As long as the declared length is 11 or over bytes, you
> are all set.
>
> To be continued...
>
> Kyle

Looking at 
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/*checkout*/gnutls/doc/protocol/draft-benaloh-pct-01.txt?rev=HEAD&cvsroot=GNU+TLS+Library&content-type=text/plain

You will notice the PCT version 2 will actually set the CLIENT_VER to 0x02 
(PCT_VERSION_V2 := 0x0002), so our packet is not PCT version 1.0 but rather 
version 2.0.

The CLIENT_HELLO of PCT v2 looks like (The original draft baddly labled the 
version as the third parameter, which is not logical, as it won't be 
compatible with SSL/PCTv1):
char CH_CLIENT_VERSION[2]
char CH_SESSION_ID_DATA[30]
char CH_CHALLENGE_DATA[30]
char CH_OFFSET[2]

So the sub version, is not that crucial and as you seen in your finding, can 
be set to anything you desire.

\x80\x62 = Length
\x01 = CLIENT_HELLO
\x02\xbd = Version 2.189 (what?)
...

So can we conclude that this is actually PCT v2?

And what we are overflowing is a mis-allocated buffer? (malloc 98 bytes 
followed by a malloc that is much bigger :) ).

---
Ami Chayun
Beyond Security Ltd.
http://www.securiteam.com