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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
From: kquest at (
Subject: Microsoft IIS SSL PCT vulnerability


-----Original Message-----
From: Ami Chayun
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, wrote:
> I just thought it would be nice to have a little bit more analysis for
> vulnerability...
> with all these exploits coming out because everybody probably wants to
> 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
> 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
> 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
> that it's not magic. For the vulnerability to be triggered, this
> 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,
> 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
> It seems that the key thing here is that the actual length is greater
> the
> declared length. As long as the declared length is 11 or over bytes,
> are all set.
> To be continued...
> Kyle

Looking at*checkout*/gnutls/doc/protocol/

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

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

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

\x80\x62 = Length
\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...


Powered by blists - more mailing lists