[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