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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html