Wireshark-dev: [Wireshark-dev] [PATCH] Fix false malformed SSL handshake messages (Was: Catch 2
From: Sake Blok <[email protected]>
Date: Sat, 14 Apr 2007 14:35:31 +0200
Hi,

Although I'm still interested in a theoretical answer to the 
problem of keeping state info on a per packet basis (see below),
here is a workaround for the bug.

Could someone review this patch?

Cheers,


Sake


On Sat, Apr 14, 2007 at 01:00:24PM +0200, Sake Blok wrote:
> Hi All,
> 
> Because of a recent discussion on the users list about malformed
> SSL packets, I discovered a bug in the SSL dissector I am trying
> to fix. The bug I discoveres appears in a SSL handshake after the
> change cypher spec. The next SSL handshake record is encrypted. It 
> is indeed shown as a "Encrypted Handshake Message" most of the 
> times. But if the first octet of the Encrypted Handshake happens
> to be a valid Handshake Type, then the SSL dissector tries to
> dissect it and fails. This results in a malformed packet.
> 
> In trying to solve this, I thought I could use the struct
> SslDecryptSession which keeps the state of the ssl session. 
> Unfortunately this struct is only filled on the first pass and
> not in the second pass when the protocol tree is being built.
> When the SSL session is decrypted, this is not a problem, 
> because the data passed to dissect_ssl3_handshake is already
> decrypted. But when the SSL session in not decrypted, I need
> this state information to determine if the next SSL header needs
> to be dissected.
> 
> I guess that this approach is simply not possible, since building
> the protocol tree is like "random access", each packet can be
> selected at random, so the state information can't be kept.
> 
> Is there a way to keep some state-information per packet? I
> don't know exactly what is kept in the conversations, but I guess
> that it is on a flow basis, not on a packet basis. Are there 
> any other protocols where dissection depends on a per-packet
> state? How do they do that?
> 
> If a per-packet state is not possible, then I could fix this 
> bug with the workaround to do a sanity check on the length
> of the SSL-handshake. But, that would be a workaround, not
> a fix :(
> 
> Cheers,
> 
> 
> Sake
> _______________________________________________
> Wireshark-dev mailing list
> [email protected]
> http://www.wireshark.org/mailman/listinfo/wireshark-dev

Attachment: fix-malformed-ssl.patch.gz
Description: application/gunzip