Re: [Full-Disclosure] Microsoft IIS SSL PCT vulnerability

From: Ami Chayun (amic_at_beyondsecurity.com)
Date: 04/25/04

  • Next message: kquest_at_toplayer.com: "RE: [Full-Disclosure] Microsoft IIS SSL PCT vulnerability"
    To: full-disclosure@lists.netsys.com
    Date: Sun, 25 Apr 2004 20:45:02 +0300
    
    

    On Saturday 24 April 2004 22:32, kquest@toplayer.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
    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html
    

  • Next message: kquest_at_toplayer.com: "RE: [Full-Disclosure] Microsoft IIS SSL PCT vulnerability"