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
| ||
|
Message-ID: <F6242D340921D5118D1E00508BB9837A07657D38@tlnmail1.toplayer.com> From: kquest at toplayer.com (kquest@...layer.com) Subject: Microsoft IIS SSL PCT vulnerability -----Original Message----- From: Ami Chayun To: full-disclosure@...ts.netsys.com Sent: 4/25/04 1:45 PM Subject: Re: [Full-Disclosure] Microsoft IIS SSL PCT vulnerability Importance: High 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=t ext/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, you are probably correct about the PCT V2 CLIENT HELLO labeling. It's probably a typo... I doubt that it is a PCT v2 message (or even PCT v1) because what you have after 0x02bd does not match the PCT protocol. You are suppose to have the SESSION ID DATA, which is 32/30 bytes long. It's not there in the exploits.... In my initial posting I did not provide all of the info... For example, the VERSION's MSB could also be 0 while the LSB is any number except 1 (e.g., 0x0004, 0x0010, etc). What's even more intersting is that version field could be set to SSLv2 (0x0002)!!! I intend to post a new PoC for this vulnerability that will look very different from the exploit we've seen so far. It won't be caught by the Snort's PCT signature either. Stay tuned... Kyle
Powered by blists - more mailing lists