Hey Frederic, what's up with this?

Discussion in 'LnS English Forum' started by R3SiN, Sep 5, 2006.

Thread Status:
Not open for further replies.
  1. R3SiN

    R3SiN Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    14
    I’ve been in a discussion with Phant0m`` and he mentioned that there is a type of fragmentation that Look ‘n’ Stop currently doesn’t support, block or even detect:

    - IP fragment out of boundary, value of the Offset flag combined with the
    total packet length exceeds the maximum datagram length of 65535 bytes.

    Shouldn't this be in even basic firewalls? Seems like this could be an easilly added feature, no?
     
    Last edited: Sep 5, 2006
  2. Thomas M

    Thomas M Registered Member

    Joined:
    Jan 12, 2003
    Posts:
    355
    R3SiN,
    So, what are the consequences of this?
    Will you just fail the "full stealth" status, or is it possible for an attacker to crash my WinXP, to produce a buffer overflow and even inject some code through these packets?

    Thomas :)
     
  3. R3SiN

    R3SiN Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    14
    "In the IP layer implementations of nearly all OS, there are bugs in the reassembly code. An attacker can create and send a pair of carefully crafted but malformed IP packets that in the process of reassembly cause an individuals machine to panic and crash. A malicious person can exploit the vulnerability in server software by sending special constructed packets which can result in execution of arbitrary code on the system with "root" privileges."

    Also, filtering this allows for more clear logs.
     
  4. R3SiN

    R3SiN Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    14
  5. R3SiN

    R3SiN Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    14
    Here is what CheckPoint has to say on fragmentation

    "IP Fragmentation—IP fragmentation can be used to deliver and disguise
    attacks in order to avoid detection. This technique utilizes the resilience
    mechanisms inherent in the IP protocol itself (RFC 791 and RFC 815) to
    intentionally fragment attacks into multiple IP packets so they can circumvent
    firewalls that do not perform IP fragment reassembly. IP fragmentation can also
    be used to launch a DoS attack by inundating IP fragment reassembly devices
    with incomplete fragment sequences."

    I am wondering that Frederic has to say about this...
     
  6. Climenole

    Climenole Look 'n' Stop Expert

    Joined:
    Jun 3, 2005
    Posts:
    1,640
    Hey R3SiN , what's up ?

    From Secunia:

    «
    Description:
    Gandalf The White has reported a variant of some known vulnerabilities in Windows, which can be exploited by malicious people to cause a DoS (Denial of Service).

    The vulnerability is caused due to an error within the processing of fragmented packets. This can be exploited by sending a large number of small fragmented packets where some fragments are missing and then sending the final fragment repeatedly.

    Successful exploitation may consume a large amount of CPU resources on a vulnerable system and may cause legitimate fragmented packets to be dropped, if a sufficient amount of attacking systems is used.
    »
    Ref.: http://secunia.com/advisories/12670/

    1- Since the discovery of this vulnerability how many exploitation of this was done? And how many L'n'S users ?

    2- The vulnerability concern fragmented packets by the operation system.
    If the packets are dropped (blocked with no feed-back, as ususal) how this vulnerability may be exploited?

    If your rule set include a rule to drop fragmented TCP/UDP packets AND an other rule to drop TCP/UDP packets with the flag More Fragments these packets never reach the "vulnerable" O.S. ...

    (You may have also the equivalent rules for Icmp... ;-) )

    Here an other interesting information from digital.net:

    «
    Rose Fragmentation Attack
    =========================
    The first attack is fairly simple. Send the first few bytes of a fragmented packet at offset 0 (More Fragments Bit = 1) and then send a few bytes at the end of a 64k sized packet (More Fragments Bit = 0). The placement of the last fragment does not have to be at 64k, this is just an attempt to use more memory.

    Note that if you send with a random source address then the only way to track down the attack is to trace it hop by hop (router by router) back to the source.

    Source port does not matter because the packet has not "moved up the stack" yet, so the stack does not validate that the destination port is even valid. In some cases all legitimate fragmented packets are denied or impacted (UDP, TCP and ICMP) if you attack a machine in this manner.

    When you send enough of these tiny fragments the buffer in the receiving machine fills waiting for the rest of the fragments to arrive. Legitimate fragmented packets cannot enter the queue because it is already filled, waiting for the fragments that will never arrive.

    Some implementations of the IP stack drop "old" fragmented packets that have not completed thus thwarting (to a greater or lesser degree) this attack.
    »

    - So with the 2 rules I'm talking about how this "attack" can be done?

    - How many of these attacks are recorded since the discovery of the vulnerability?

    - How many of these recorded attacks was successfull?

    - How many of L'n'S users may be "victims" of this kind of attack?
    (Near ZERO, IMHO...)


    And last but not least: a funny experience.

    Here's my IP Address: 70.50.45.138

    Here's the method to make this attack:
    http://digital.net/~gandalf/Rose_Frag_Attack_Explained.txt

    And now do me a favor: try to crash my system. ;-)

    Go ahead! I'm waiting!

    Have fun.

    :-D

    P.S. There are more frequent "attacks" recorded by some L'n'S users: Personnal attacks... ;-)
     
    Last edited: Sep 5, 2006
  7. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    I don’t know about you two.., but I personally know I’m not qualified even remotely enough in the area of TCP/IP stack to be contradicting CheckPoint articles. ;)
     
  8. Climenole

    Climenole Look 'n' Stop Expert

    Joined:
    Jun 3, 2005
    Posts:
    1,640
    Hi Phant0m :)

    You say:

    "I personally know I’m not qualified even remotely enough in the area of TCP/IP stack to be contradicting CheckPoint articles"


    It's not a reason to believed it... ;-) ;-) ;-)

    How many systems has been reported crashed with this attack?
    Let me guess: huuum say not far to zero...

    The proof of the pudding is in the eating.

    Did somebody would like to crash my system with this attack please ?

    Still waiting...

    :-D

    Have a nice day Phant0m.
    :)
     
  9. R3SiN

    R3SiN Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    14
    Hey Climenole,

    I said "*These are general examples*"

    You said something about ruleset dropping fragmented packets. How can it drop what it doesnt recognize as fragmented? That is the issue here.
     
  10. R3SiN

    R3SiN Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    14
    Ohh, how many users have been exploited by the most detailed leaktests out there? You think Frederic should not be bothered about anything until it is widely used?
     
  11. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    Since it is not so frequent to receive datagrams with huge sizes, you can assume the biggest IP packet is 1500 (or your exact MTU), and then create a rule that will block any packet which is a fragment and that will lead to a datagram with a size > 65535-1500.
    Doing that there is no need to have a special mechanism to do a check with the "Total length" field + "Fragment Offset" field, which is effectively not possible with the current version of Look 'n' Stop.

    To do this kind of rule you need to use the RawEdition plugin.
    Also you have to take care of the MF flag (because it is not possible to combine a mask and a range in the same criteria).

    Frederic
     
  12. R3SiN

    R3SiN Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    14
    It was nice of you to mention that work-around, but would you mind adding support for oversized packet detection in the next final release of LnS? This would be much appreciated and allow for a more concrete product.
     
  13. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    Look ‘n’ Stop with the pre-bundled EnhancedRulesSet.rls ruleset file already made to support detection of IP fragmented packets for two types of bad occurrences, there are several types of bad occurrences that Look ‘n’ Stop does not currently support, for the two it does they are, giving by just their rule names ‘IP : Fragment Block’, and ‘IP : MF Flag Block’. Both of these rules are tied to TCP for IP Protocol, and should be set to ‘ALL’ really...

    With the install of Look ‘n’ Stop v2.05 and manual activation of the IPFragActive flag found in a registry file located in the Look ‘n’ Stop installed location, bundled with other non-related flags, Look ‘n’ Stop offers more support for IP fragmentations…

    “Frederic> support for IP Fragmented packets. When an IP datagram is fragmented, now the ruleset is applied only to the first packet of the datagram to know the behaviour (block/allow/alert), and same behaviour is applied to the other packets of the datagram."


    With Frederic assistances awhile back, we managed to determine that Look ‘n’ Stop could in-fact be made to handle many more types, … with the use of RawRule Look ‘n’ Stop plugin (ultimate power it gives when creating rules based on header information), and using some ‘hopefully’ temporarily workarounds. Like shown with my rule for IP fragment out of boundary, https://www.wilderssecurity.com/showpost.php?p=832297&postcount=11 you have to manually adjust the field values depending on the windows XOR router MTU value… See below for attached importable rule file….

    Therefore so far, here are the checks we can do now on fragmented packets for bad occurrences with the following characteristics;

    • Invalid fragmentation flags/offset - this event is triggered when either the DF and MF flags in the IP header are set to 1 OR if a header contains the DF flag set to 1 and an Offset value different than 0.

    • IP fragment offset too small - a non-zero Offset flag with a value that is smaller than 60 bytes.

    • First fragment too small - event triggered when a packet with the MF flag set to 1, the Offset value is at 0 and has total length smaller than 120 bytes. (Maximum combined header length)


    and now,

    • IP fragment out of boundary - event occurs if the value of the Offset flag combined with the total packet length exceeds the maximum datagram length of 65535 bytes.

    I’m not certain if there are some more characteristics that I’m leaving out; please bring it to my attention if there is…
     

    Attached Files:

  14. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    Here is the importable rules file... attached
     

    Attached Files:

  15. zozot

    zozot Registered Member

    Joined:
    Apr 26, 2006
    Posts:
    50
    Location:
    france
    hi,

    where i can add this rules ( in the list) if i use Climenole_rules ?
    and it s useful to add ?
     
  16. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    This here rule can be placed at the very top of the ruleset, It isn’t tied to just TCP or UDP, TCP / UDP or ICMP …. but the IP Protocol in general.

    It is definitely good to block such IP fragmentations, especially this type, however here’s the catch, you’ll need to ensure this rule isn’t going to be problematic; therefore it is no good to import before first knowing your windows MTU setting, if your Windows MTU setting has been customized / tweaked you must specify this MTU value in the Raw Rule Plugin Edition window, Field-3, Value2 (where 1499 MTU value is currently set). If there is no Windows MTU setting specified then it is likely 1500 MTU value, and if you using Routers this can also likely change things.

    Often Routers are using default MTU Value of 1500, and I’m not sure if Windows MTU is overriding by the Router MTU settings, I haven’t done my research that far…

    If you using a Router, just try the Windows MTU Value, using program like Dr.TCP http://www.dslreports.com/drtcp you can determine what the Windows MTU is, if the Windows MTU has been customized Dr.TCP will have a value, if not, the MTU value be blank in the Dr.TCP utility. Dr.TCP MTU value is blank, use 1500.
     
  17. zozot

    zozot Registered Member

    Joined:
    Apr 26, 2006
    Posts:
    50
    Location:
    france
    ok thx
     
  18. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    You are welcome :D
     
  19. RyanM

    RyanM Registered Member

    Joined:
    Jun 8, 2006
    Posts:
    23
    So if our Windows MTU value is 1500, do we need to change the LnS default value of 1499 to 1500, or can we leave it as 1499?

    Thanks for the new rule :D

    Ryan
     
  20. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    LOL, no you better make that change... Don't leave it at 1499! :ouch:
     
  21. RyanM

    RyanM Registered Member

    Joined:
    Jun 8, 2006
    Posts:
    23
    Okay thanks for clearing that up lol
    It's just odd that the default value for your LnS rule is so close to 1500, especially when the default Windows value is supposedly 1500! In any case, I've made the change.

    Thanks again.

    Ryan
     
  22. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    I made it so .... everyone has to check, and make a change.

    I wanted to be fair :)
     
  23. fred22

    fred22 Registered Member

    Joined:
    Dec 6, 2004
    Posts:
    229
    thanks phantom..added and changed to "1500"
     
  24. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    You are welcome :)
     
  25. tristantzara

    tristantzara Registered Member

    Joined:
    Mar 21, 2006
    Posts:
    78
    1300 i got

    so how did that happen :D
     

    Attached Files:

    • tcp.jpg
      tcp.jpg
      File size:
      26.7 KB
      Views:
      326
Thread Status:
Not open for further replies.