[Snort-devel] Detecting TCP Timestamp PAWS DoS from tracefile

Steven Sturges steve.sturges at ...402...
Sun Aug 7 18:51:47 EDT 2005


To clarify what Stream4 currently does:

Before adding a packet to the list of those included in
reassembly, it checks for a TCP Timestamp option that is set to 0.
Some Win32 systems use 0 on SYN packets, so that is allowed.

This is only done on Sessions for which Stream4 is doing
reassembly, so for any other traffic, Snort won't make a peep.

Based on the information on the web for this DoS, it would be
pretty trivial to ensure any TCP Timestamps fall within a certain
window.  If one is outside the window, the packet would be ignored,
dropped, etc.

As we work on the next Stream engine, we will take this DoS into
consideration and attempt to provide some means of detection.

Cheers.
-steve

> -----Original Message-----
> From: snort-devel-admin at lists.sourceforge.net 
> [mailto:snort-devel-admin at lists.sourceforge.net] On Behalf Of J.Smith
> Sent: Sunday, August 07, 2005 8:43 AM
> To: snort-users at lists.sourceforge.net; 
> snort-devel at lists.sourceforge.net; snort-sigs at lists.sourceforge.net
> Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS 
> from tracefile
> 
> Thanks, again.
> 
> "rmkml" <rmkml at ...879...> wrote:
> >
> > Snort support PAWS but possible not detect DoS
> >
> Yeah, that was my guess as well. If snort doesn't detect this 
> issue, would it be possible/feasible/easy to add a ruleset 
> that would allow snort to detect it ?
> 
> 
> >
> > Im detected PAWS discard (linux stack) with firestorm nids product :
> >
> Im not a developer myself, so im not quite sure what it is 
> that firestorm is supposed to check, but ... it looks like it 
> triggers an alert if any supplied TCP timestamp in a given 
> tcp session is set more than 24 hours into the future or past ?
> 
> 
> Sincerely,
> 
> 
> John Smith
> 
> 
> 
> PS:
> Just in case, Im adding the snort-sigs list to the thread. In 
> summary, the question is whether snort allows for the 
> detection of the following issue :
> 
> 
> Multiple Vendor TCP Timestamp PAWS Remote Denial Of Service 
> Vulnerability
> http://www.securityfocus.com/bid/13676
> 
> TCP does not adequately validate segments before updating 
> timestamp value
> http://www.kb.cert.org/vuls/id/637934
> 
> CAN-2005-0356
> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0356
> 
> ----- Original Message ----- 
> From: "rmkml" <rmkml at ...879...>
> To: "J.Smith" <lbalbalba at ...445...>
> Sent: Sunday, August 07, 2005 2:15 PM
> Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS 
> from tracefile
> 
> 
> > Snort support PAWS but possible not detect DoS (same Bro nids),
> > Im detected PAWS discard (linux stack) with firestorm nids product :
> >  firestorm-0.5.5/decode_plugins/tcpstream.c :
> >    *  o PAWS (rfc1323) evasion
> >    ...
> >    static struct alert alert_tcp3={
> >         .alert="PAWS discard",
> >    ...
> >    /* rfc1323: H1. Apply PAWS checks first */
> >    if ( rcv->flags & TF_TSTAMP_OK &&
> >       (tp->saw_tstamp=tcp_fast_options(tcph, &tp->tsval)) ) {
> >       if ( (int32_t)(rcv->ts_recent - tp->tsval) > 
> TCP_PAWS_WINDOW &&
> >          (u_int32_t)p->time.tv_sec < rcv->ts_recent_stamp
> >          + TCP_PAWS_24DAYS ) {
> >          alert_tag(cur.pkt, &alert_tcp3, -1);
> >          return;
> >        }
> >
> > Regards
> > Rmkml
> >
> >
> > On Sun, 7 Aug 2005, rmkml wrote:
> >
> >> Date: Sun, 7 Aug 2005 13:52:59 +0200 (CEST)
> >> From: rmkml <rmkml at ...879...>
> >> To: J.Smith <lbalbalba at ...445...>
> >> Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from 
> >> tracefile
> >>
> >> Possible send (anonymazing ip) tracefile/pcapfile to the list ?
> >>
> >>
> >> On Sun, 7 Aug 2005, J.Smith wrote:
> >>
> >>> Date: Sun, 7 Aug 2005 13:29:29 +0200
> >>> From: J.Smith <lbalbalba at ...445...>
> >>> To: rmkml <rmkml at ...879...>, snort-users at lists.sourceforge.net,
> >>>     snort-devel at lists.sourceforge.net
> >>> Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from 
> >>> tracefile
> >>>
> >>> Hi.
> >>>
> >>> Thanks for the information, but from the limited 
> information in the 
> >>> changelog I cannot actually determine if this is really 
> referring to the 
> >>> same ddos attack as the one that I am referring to.
> >>>
> >>>
> >>> If I understand the issue I originally mentioned 
> correctly, then the 
> >>> attacker injects a forged packet into the stream that has a TCP 
> >>> timestamp that lies somewhere into the future, causing 
> all subsequent 
> >>> packets to be dropped because they are deemed to be too 
> old or invalid, 
> >>> effectively 'stalling'  the connection.
> >>>
> >>> So if I understand correctly, then any relevant snort 
> ruleset would have 
> >>> to verify that at least all timestamps in a given tcp session are 
> >>> somewhat 'consecutive' ? Or if the timestamp value was 
> set to a large 
> >>> value by the attacker, then it will likely be larger than 
> the timestamp 
> >>> values in any subsequent incoming segments that belong to 
> the same tcp 
> >>> session - does any snort ruleset detect this ?
> >>>
> >>>
> >>> Thanks,
> >>>
> >>>
> >>> Sincerely,
> >>>
> >>> John Smith.
> >>>
> >>>
> >>> ----- Original Message ----- From: "rmkml" <rmkml at ...879...>
> >>> To: "J.Smith" <lbalbalba at ...445...>
> >>> Sent: Sunday, August 07, 2005 1:19 PM
> >>> Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from 
> >>> tracefile
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>> Found PAWS on src snort 240 : (ChangeLog)
> >>>>
> >>>> 2005-03-15 Jeremy Hewlett <jh at ...402...>
> >>>> ...
> >>>>     * etc/snort.conf:
> >>>>       Stream4 fixes - Handle PAWS, NULL TCP Flags in established 
> >>>> session,
> >>>>       limit overlaps in established session, update ACK 
> when server 
> >>>> sends
> >>>>       RST. Performance changes for cleaning up session 
> cache. Thanks
> >>>>       Steve Sturges and Andy Mullican for the patches.
> >>>>
> >>>> src/preprocessors/spp_stream4.c :
> >>>>  * 04 Feb 2005: SAS Updated to handle favor_old and 
> favor_new options.
> >>>>  *                  favor_new traverses the tree in the opposite
> >>>>  *                  direction and builds the stream using newer 
> >>>> packets.
> >>>>  *                  Also added checks for:
> >>>>  *                  - PAWS (Timestamp option is set and 0) on an
> >>>>  *                  establiahed session and ACK in the 
> packet.  Win32
> >>>>  *                  uses 0 Timestamp on Syn-only packets.
> >>>>
> >>>> Regards
> >>>> Rmkml
> >>>>
> >>>>
> >>>> On Sun, 7 Aug 2005, J.Smith wrote:
> >>>>
> >>>>> Date: Sun, 7 Aug 2005 12:43:23 +0200
> >>>>> From: J.Smith <lbalbalba at ...445...>
> >>>>> To: snort-users at lists.sourceforge.net, 
> >>>>> snort-devel at lists.sourceforge.net
> >>>>> Subject: [Snort-devel] Detecting TCP Timestamp PAWS DoS 
> from tracefile
> >>>>>
> >>>>> Hi.
> >>>>>
> >>>>>
> >>>>> At our site, we have the impression that we might have 
> been hit by the 
> >>>>> following issue :
> >>>>>
> >>>>> Multiple Vendor TCP Timestamp PAWS Remote Denial Of Service 
> >>>>> Vulnerability
> >>>>> http://www.securityfocus.com/bid/13676
> >>>>>
> >>>>> TCP does not adequately validate segments before 
> updating timestamp 
> >>>>> value
> >>>>> http://www.kb.cert.org/vuls/id/637934
> >>>>>
> >>>>>
> >>>>> In a nutshell, the issue manifests if an attacker transmits a 
> >>>>> sufficient TCP PAWS packet to a vulnerable computer. A 
> large value is 
> >>>>> set by the attacker as the tcp packet timestamp. When 
> the target 
> >>>>> computer processes this packet, the internal timer is 
> updated to the 
> >>>>> large attacker supplied value. This causes all other 
> valid packets 
> >>>>> that are received subsequent to an attack to be dropped 
> as they are 
> >>>>> deemed to be too old, or invalid. This effectively 'stalls' the 
> >>>>> connection, which will deny service for a target connection.
> >>>>>
> >>>>> Fortunately, we have a tracefile of some of the traffic 
> that hit our 
> >>>>> site at the time. I was wondering how easy it would be 
> to 'proof' that 
> >>>>> we did indeed experience this issue with the use of 
> snort ? I did a 
> >>>>> quick scan of the snort ruleset database, but it appears that 
> >>>>> detection of this issue is not included in the snort 
> database yet ?
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>>
> >>>>> John Smith.
> >>>>>
> >>>>>
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development 
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * 
> Testing & QA
> Security * Process Improvement & Measurement * 
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
> 





More information about the Snort-devel mailing list