From: skybuck2000@hotmail.com   
      
   Here is some more information about the nature of these exploits, especially   
   the IPv4 exploit/bug:   
      
   https://unit42.paloaltonetworks.com/cve-2021-24074-patch-tuesday/   
      
   Most interesting and dangerous part:   
      
   "   
   CVE-2021-24074 Overview   
      
   An attacker can leverage this vulnerability by sending maliciously crafted   
   IPv4 packets to a victim, potentially causing a RCE on the system.   
      
   This vulnerability occurs due to confusing IPv4 options fields between two   
   fragments. The scenario pointed out by Microsoft shows two IPv4 fragments, the   
   first of which has the Security Options (Type 130) field, followed by a second   
   fragment with either    
   the Loose Source and Record Route (LSRR) option (Type 131) or the "Strict   
   Source and Record Route (SSRR) option (Type 137). The fragment offsets,   
   confusing the options and the header data together, cause an out-of-bound read   
   and write during reassembly    
   of the IP fragments, which introduces the potential for RCE on a Windows   
   machine.   
   "   
      
   Links to:   
      
   https://tools.ietf.org/html/rfc7126#section-4.3   
      
   Most interesting parts from this rfc:   
      
   "   
   2.  IP Options   
      
      IP options allow for the extension of the Internet Protocol.  As   
      specified in [RFC0791], there are two cases for the format of an   
      option:   
      
      o  Case 1: A single byte of option-type.   
      
      o  Case 2: An option-type byte, an option-length byte, and the actual   
         option-data bytes.   
      
      IP options of Case 1 have the following syntax:   
      
      +-+-+-+-+-+-+-+-+- - - - - - - - -   
      |  option-type  |  option-data   
      +-+-+-+-+-+-+-+-+- - - - - - - - -   
      
      The length of IP options of Case 1 is implicitly specified by the   
      option-type byte.   
      
      IP options of Case 2 have the following syntax:   
      
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -   
      |  option-type  | option-length |  option-data   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -   
      
      In this case, the option-length byte counts the option-type byte and   
      the option-length byte, as well as the actual option-data bytes.   
      
      
      
      
   Gont, et al.              Best Current Practice                 [Page 4]   
      
       
   RFC 7126            Filtering of IP-Optioned Packets       February 2014   
      
      
      All current and future options, except "End of Option List" (Type =   
      0) and "No Operation" (Type = 1), are of Class 2.   
      
      The option-type has three fields:   
      
      o  1 bit: copied flag.   
      
      o  2 bits: option class.   
      
      o  5 bits: option number.   
      
      The copied flag indicates whether this option should be copied to all   
      fragments in the event the packet carrying it needs to be fragmented:   
      
      o  0 = not copied.   
      
      o  1 = copied.   
      
      The values for the option class are:   
      
      o  0 = control.   
      
      o  1 = reserved for future use.   
      
      o  2 = debugging and measurement.   
      
      o  3 = reserved for future use.   
      
      This format allows for the creation of new options for the extension   
      of the Internet Protocol (IP).   
      
      Finally, the option number identifies the syntax of the rest of the   
      option.   
      
      The "IP OPTION NUMBERS" registry [IANA-IP] contains the list of the   
      currently assigned IP option numbers.   
   "   
      
   "   
      
   4.3.  Loose Source and Record Route (LSRR) (Type = 131)   
      
      RFC 791 states that this option should appear at most once in a given   
      packet.  Thus, if a packet contains more than one LSRR option, it   
      should be dropped, and this event should be logged (e.g., a counter   
      could be incremented to reflect the packet drop).  Additionally,   
      packets containing a combination of LSRR and SSRR options should be   
      dropped, and this event should be logged (e.g., a counter could be   
      incremented to reflect the packet drop).   
      
   4.3.1.  Uses   
      
      This option lets the originating system specify a number of   
      intermediate systems a packet must pass through to get to the   
      destination host.  Additionally, the route followed by the packet is   
      recorded in the option.  The receiving host (end-system) must use the   
      reverse of the path contained in the received LSRR option.   
      
      The LSSR option can be of help in debugging some network problems.   
      Some Internet Service Provider (ISP) peering agreements require   
      support for this option in the routers within the peer of the ISP.   
      
   4.3.2.  Option Specification   
      
      Specified in RFC 791 [RFC0791].   
      
      
      
      
      
      
      
   Gont, et al.              Best Current Practice                 [Page 8]   
      
       
   RFC 7126            Filtering of IP-Optioned Packets       February 2014   
      
      
   4.3.3.  Threats   
      
      The LSRR option has well-known security implications [RFC6274].   
      Among other things, the option can be used to:   
      
      o  Bypass firewall rules.   
      
      o  Reach otherwise unreachable internet systems.   
      
      o  Establish TCP connections in a stealthy way.   
      
      o  Learn about the topology of a network.   
      
      o  Perform bandwidth-exhaustion attacks.   
      
      Of these attack vectors, the one that has probably received least   
      attention is the use of the LSRR option to perform bandwidth   
      exhaustion attacks.  The LSRR option can be used as an amplification   
      method for performing bandwidth-exhaustion attacks, as an attacker   
      could make a packet bounce multiple times between a number of systems   
      by carefully crafting an LSRR option.   
      
         This is the IPv4 version of the IPv6 amplification attack that was   
         widely publicized in 2007 [Biondi2007].  The only difference is   
         that the maximum length of the IPv4 header (and hence the LSRR   
         option) limits the amplification factor when compared to the IPv6   
         counterpart.   
      
      Additionally, some implementations have been found to fail to include   
      proper sanity checks on the LSRR option, thus leading to security   
      issues.  These specific issues are believed to be solved in all   
      modern implementations.   
      
         [Microsoft1999] is a security advisory about a vulnerability   
         arising from improper validation of the Pointer field of the LSRR   
         option.   
      
      Finally, we note that some systems were known for providing a system-   
      wide toggle to enable support for this option for those scenarios in   
      which this option is required.  However, improper implementation of   
      such a system-wide toggle caused those systems to support the LSRR   
      option even when explicitly configured not to do so.   
      
         [OpenBSD1998] is a security advisory about an improper   
         implementation of such a system-wide toggle in 4.4BSD kernels.   
         This issue was resolved in later versions of the corresponding   
         operating system.   
      
      
      
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)