[Bro-Dev] [JIRA] (BIT-348) Reassembler integer overflow issues. Data not delivered after 2GB
Jon Siwek (JIRA)
jira at bro-tracker.atlassian.net
Mon Apr 28 08:05:07 PDT 2014
[ https://bro-tracker.atlassian.net/browse/BIT-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302#comment-16302 ]
Jon Siwek commented on BIT-348:
Alright, I'm giving up on reviewing the changes in TCP.cc, with the refactoring it's really hard to track what's part of the 64-bit changes vs. what's just moved around. I would certainly have preferred having the refactoring separately, though I understand that it's all related.
Sorry, but yeah it was "difficult" to treat that separately (without having worked much on that code beforehand).
I did some more testing on a large trace, and I am seeing differences in the duration of a few connections. Have you seen that as well / do you have an idea where that's coming from?
Not sure, a guess is it's treating the end as the FIN exchange instead of the end being the RST(s). If you can send a pcap, I'll look in to it?
> Reassembler integer overflow issues. Data not delivered after 2GB
> Key: BIT-348
> URL: https://bro-tracker.atlassian.net/browse/BIT-348
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: git/master
> Reporter: gregor
> Assignee: Robin Sommer
> Priority: High
> Labels: inttypes
> Fix For: 2.3
> The TCP Reassembler does not deliver any data to analyzers after the first 2GB due to signed integer overflow (Actually it will deliver again between 4--6GB, etc.) This happens silently, i.e., without content_gap events or Undelivered calls.
> This report superseded BIT-315, BIT-137
> The TCP Reassembler (and Reassem) base class use ``int`` to keep track of sequence numbers and ``seq_delta`` to check for differences. If a connection exceeds 2GB, the relative sequence numbers (int) used by the Reassembler become negative. While many parts of the Reassembler still work (because seq_delta still reports the correct difference) some parts do not. In particular ``seq_to_skip`` is broken (and fails silently). There might well be other parts of the Reassembler that fail
> silently as well, that I haven't found yet.
> See Comments in TCP_Reassembler.cc for more details.
> The Reassembler should use int64. However this will require deep changes to the Reassembler and the TCP Analyzer and TCP_Endpoint classes (since we also store sequence numbers there). Also, the analyzer framework will need tweaks as well (e.g., Undelivered uses ``int`` for sequence numbers, also has to go to 64 bit)
> As a hotfix that seems to work I disabled the ``seq_to_skip`` features. It wasn't used by any analyzer or policy script (Note, that seq_to_skip is different from skip_deliveries). Hotfix is in
This message was sent by Atlassian JIRA
More information about the bro-dev