Sending large overflow values (packet > 65535bytes) about scapy-ssl_tls

[tintinweb]

Hi @AviDor,

While the tlsrecord.size field (short) can be up to 65k, rfc2246 6.2.1 Fragmentation recommends a maximum records size of 16k. Our implementation of TLSRecord currently enforces this limit and if you exceed TLSRecord.MAX_LEN a TLSFragmentationError will be thrown. However, you're free to override TLSRecord.MAX_LEN to fit your needs but be aware, this is a class attribute and your change will be shared with all other instances of TLSRecord. Note that you cannot exceed 65k as this is the maximum value the records size field can hold (remember, its a short int).

Also note that TLSClientHello.gmt_unix_time is not a good candidate for adding random data as it is a fixed length 4 byte integer field and adding 10m 'a' will likely just result in creating an invalid hello message. Your best bet would be planting your payload as valid extensions to the hello message.

Here's a modification to client_hello_valid.py that will build a 'valid structured' 65k client hello by adding a lot of garbage padding extensions.

# note - this example is based off master
# create TLS Handhsake / Client Hello packet
TLSRecord.MAX_LEN = 2**16
p = TLSRecord() / TLSHandshakes(handshakes=[TLSHandshake() /
                                            TLSClientHello(compression_methods=range(0xff)[::-1],
                                                           cipher_suites=range(0xff),
                                                           extensions=[TLSExtension() / TLSExtPadding("a"*100)]*622)])

print(len(str(p)))
# 65502

let me know if that answers your questions.

cheers,
tin

[joh1686]

Hi @tintinweb
Thanks for the reply.
It does answer my question but this is a limitation when it comes to fuzzing. If the TLSRecord size is 65k MAX it will not be able to provide sufficient fuzzing. Some SSL implementation will only fail on very large overflow values.

As for gmt_unix_time, the test was inspired by Codenomicon Defensics TLS fuzzing suite. It sends a long string (10 million bytes) instead of the proper unix time. On scapy_tls I edited gmt_unix_time to be a variable length string and attempted to send a 10 million bytes string and that obviously failed.

[tintinweb]

Hi @AviDor,

scapy-ssl_tls does not limit you in any way to produce invalid tls records.
The rfc specifies TLSRecord.length to be an unsigned short (max=2^16). However, that does not mean you cannot override it or hint any record size you want.

The following (scapy-ssl_tls 1.2.3.2 compatible) example builds a 91k TLSClientHello by adding garbage TLSServerNameExtensions and setting all the length fields to max to prevent scapy from autocalculating the length. You have to manually set the length fields as scapy will likely complain that the length exceeds the maximum possible value for the record length (remember, 2**16-1).

TLSRecord.MAX_LEN = 2**64-1  # satisfy the fragmentation size check.. any high int.
# create TLS Handhsake / Client Hello packet
# note that we set all length fields to ushort max as we're going to exceed that anyway.
p = TLSRecord(length=2**16-1)/TLSHandshake(length=2**16-1)/TLSClientHello(compression_methods=range(0xff)[::-1],
                                            cipher_suites=range(0xff),
                                            extensions_length=2**16-1,
                                            extensions=[TLSExtension() / TLSExtServerNameIndication(server_names=[TLSServerName(data="www.dummysite.com")])]*3500)

p.show()
print(len(str(p)))
#91814

Codenomicon gmt_unix_time overflow leaves some questions as they're overflowing a fixed size 4 byte field and therefore garbling the next fields with non tls compliant stuff. Thats kind of the crowbar way to do things and a decent stack is likely going to abort the connection once you provide something non-tls-ish :) Would probably be similar to something like TLSRecord()/TLSHandshake()/RandString() in scapy-ssl_tls.

Hope that makes sense :)

cheers
tin

[joh1686]

thanks @tintinweb that's what I was looking for.