Attempting to use SSL analyser in 0.9a8

Zeek
1

Hi all,

I'm attempting to have a go with the SSL analyser, using bro 0.9a8. I'm encountering a problem that I've tracked down be caused by DataBlocks being deallocated but their data still being used following reassignment of a contents processor.

I realise the above description is a bit vague, but I wanted to check if anybody was interested in hearing more about this problem or not. I understand that the SSL analyser is a work-in-progress, so may not be expected to work at all at the moment.

Thanks for any pointers.
Jonathan

2

Yes, unfortunately, the SSL analyzer is broken at the moment.
However, there are two guys working on fixing it (cc'ed). I don't
really know what the current state is but I am sure they'll
appreciate any help in tracking the problem down.

Thanks!

Robin

3

Thanks for the info.

I'll go into a bit more detail here in case it's any use.

I have a trace file with a single HTTPS connection. I'm running bro like this:

   bro -r bro-test-ssl.pcap ssl

weird.log gives:

1109703962.146861 ** 130.209.243.215/32874 > 130.209.240.41/https: SSLv2: FATAL: recordLength doesn't match data block length!

A bit of debugging shows that the first two words of the stream content being parsed have been stomped. More investigation reveals that the malloc-ed block has been freed. Here is some more info (including a bit of a stack trace) from using valgrind:

==22627== Invalid read of size 1
==22627== at 0x812DC6B: SSLv2_Interpreter::NewSSLRecord(SSL_InterpreterEndpoint*, int, unsigned char*) (SSLv2.cc:150)
==22627== by 0x812D102: SSL_ConnectionProxy::DoDeliver(TCP_Endpoint*, int, int, unsigned char*) (SSLProxy.cc:728)
==22627== by 0x812D039: SSL_ConnectionProxy::NewSSLRecord(SSL_ProxyEndpoint*, int, unsigned char*) (TCP_Contents.h:116)
==22627== by 0x812D404: SSL_ProxyEndpoint::DoDeliver(int, unsigned char*) (TCP_Contents.h:116)
==22627== by 0x812C540: SSL_RecordBuilder::addSegment(unsigned char*, int) (SSLProxy.cc:206)
==22627== by 0x812D38C: SSL_ProxyEndpoint::Deliver(int, int, unsigned char*) (SSLProxy.cc:798)
==22627== by 0x81045A6: TCP_Contents::DeliverBlock(int, int, unsigned char*) (TCP_Contents.cc:397)
==22627== by 0x810395E: TCP_Reassembler::BlockInserted(DataBlock*) (TCP_Contents.cc:215)
==22627== Address 0x41B8F680 is 0 bytes inside a block of size 126 free'd
==22627== at 0x4002B6AE: operator delete[](void*) (vg_replace_malloc.c:190)
==22627== by 0x80DA498: Reassembler::ClearBlocks() (Reassem.cc:160)
==22627== by 0x80DA186: Reassembler::~Reassembler() (Reassem.cc:68)
==22627== by 0x810353C: TCP_Reassembler::~TCP_Reassembler() (Obj.h:200)
==22627== by 0x8104124: TCP_Contents::~TCP_Contents() (Obj.h:204)
==22627== by 0x812D305: SSL_ProxyEndpoint::~SSL_ProxyEndpoint() (SSLProxy.cc:767)
==22627== by 0x8105744: TCP_Endpoint::AddContentsProcessor(TCP_Contents*) (TCP_Endpoint.cc:89)
==22627== by 0x8103D22: TCP_Contents::TCP_Contents(TCP_Endpoint*, int) (TCP_Contents.cc:284)

I don't understand the object hierarchies fully yet, but my impression so far is that a new contents processor is assigned (TCP_Endpoint.c:89) which causes the old one to be deleted. This deletes the Reassembler instance, which frees the DataBlocks. However, there are still references (uchar*) to the data in the DataBlock which is soon to be used in NewSSLRecord.

I tried patching around this by transferring the DataBlocks ownership between Reassembler instances (before the old one gets deleted), but came up against another crashing issue that I haven't had time to track down.

I hope this is of some help. Please let me know if there's anything more I can do.

Thanks.

PS

The above error isn't the first reported by valgrind. After a few warnings relating to DNS_Mgr, the first SSL-related error is this:

==22627== Invalid read of size 2
==22627== at 0x812D018: SSL_ConnectionProxy::NewSSLRecord(SSL_ProxyEndpoint*, int, unsigned char*) (SSLProxy.cc:702)
==22627== by 0x812D404: SSL_ProxyEndpoint::DoDeliver(int, unsigned char*) (TCP_Contents.h:116)
==22627== by 0x812C540: SSL_RecordBuilder::addSegment(unsigned char*, int) (SSLProxy.cc:206)
==22627== by 0x812D38C: SSL_ProxyEndpoint::Deliver(int, int, unsigned char*) (SSLProxy.cc:798)
==22627== by 0x81045A6: TCP_Contents::DeliverBlock(int, int, unsigned char*) (TCP_Contents.cc:397)
==22627== by 0x810395E: TCP_Reassembler::BlockInserted(DataBlock*) (TCP_Contents.cc:215)
==22627== by 0x80DA2A1: Reassembler::NewBlock(double, int, int, unsigned char const*) (Reassem.cc:99)
==22627== by 0x8104269: TCP_Contents::DataSent(double, int, int, unsigned char const*) (TCP_Contents.cc:335)
==22627== Address 0x422469AC is 28 bytes inside a block of size 40 free'd
==22627== at 0x4002B54E: operator delete(void*) (vg_replace_malloc.c:188)
==22627== by 0x8105744: TCP_Endpoint::AddContentsProcessor(TCP_Contents*) (TCP_Endpoint.cc:89)
==22627== by 0x8103D22: TCP_Contents::TCP_Contents(TCP_Endpoint*, int) (TCP_Contents.cc:284)
==22627== by 0x812D213: SSL_ProxyEndpoint::SSL_ProxyEndpoint(TCP_Endpoint*) (SSLProxy.cc:756)
==22627== by 0x812CFEE: SSL_ConnectionProxy::NewSSLRecord(SSL_ProxyEndpoint*, int, unsigned char*) (SSLProxy.cc:686)
==22627== by 0x812D404: SSL_ProxyEndpoint::DoDeliver(int, unsigned char*) (TCP_Contents.h:116)
==22627== by 0x812C540: SSL_RecordBuilder::addSegment(unsigned char*, int) (SSLProxy.cc:206)
==22627== by 0x812D38C: SSL_ProxyEndpoint::Deliver(int, int, unsigned char*) (SSLProxy.cc:798)