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
| ||
|
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
Powered by blists - more mailing lists