[Bro] Attempting to use SSL analyser in 0.9a8

Jonathan Paisley jp-www at dcs.gla.ac.uk
Wed Mar 2 13:58:39 PST 2005


On 2 Mar 2005, at 17:44, Robin Sommer wrote:
> On Wed, Mar 02, 2005 at 17:22 +0000, Jonathan Paisley wrote:
>
>> 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.
>
> 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 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)




More information about the Bro mailing list