Public Vulnerability Reports

Multiple Vendor Snort IP Fragment TTL Evasion Vulnerability



Snort is an open source network intrusion detection (IDS) and prevention system (IPS). In addition to being available as a package for most Unix operating system distributions, various commercial hardware devices also use Snort as an IDS/IPS. For more information, see the vendor's website found at the following URL.


Remote exploitation of a design error vulnerability in Snort, as included in various vendors' operating system distributions, could allow an attacker to bypass filter rules.

Due to a design error vulnerability, Snort does not properly reassemble fragmented IP packets. When receiving incoming fragments, Snort checks the Time To Live (TTL) value of the fragment, and compares it to the TTL of the initial fragment. If the difference between the initial fragment and the following fragments is more than a configured amount, the fragments will be silently discarded. This results in valid traffic not being examined and/or filtered by Snort.


Exploitation of this vulnerability allows an attacker to bypass all Snort rules. In order to exploit this vulnerability, an attacker would have to fragment IP packets destined for a targeted host, ensuring that the TTL difference is greater than the configured maximum. By default, the maximum difference is 5.

If an attacker is successful, all fragments with invalid TTL differences will be dropped. No rules will be applied to them.


iDefense has confirmed the existence of this vulnerability in Snort 2.8 and 2.6. Snort 2.4 is not vulnerable.


In the snort.conf file, set the ttl_limit configuration value to 255 as shown below.

 preprocessor frag3_engine: ttl_limit 255 

This will set the allowable difference to the maximum possible value, and prevent fragments from being dropped.


Sourcefire has addressed this vulnerability by releasing version 2.8.1 of Snort. For more information consult their change log and source differences at the following URLs.


The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2008-1804 to this issue. This is a candidate for inclusion in the CVE list (, which standardizes names for security problems.


02/26/2008 Initial vendor notification
02/26/2008 Initial vendor response
05/21/2008 Coordinated public disclosure


This vulnerability was reported to iDefense by Silvio Cesare.

Get paid for vulnerability research

Free tools, research and upcoming events


Copyright © 2008 Verisign, Inc.

Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail customer service for permission.

Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.