Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Oh, wait, that was Randal...nevermind... -- Larry Wall in <199709261754.KAA23761@wall.org>


programming / alt.lang.asm / Re: (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.

SubjectAuthor
* (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.skybuck2000
`* Re: (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.skybuck2000
 `- Re: (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.skybuck2000

1
Subject: (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.
From: skybuck2000
Newsgroups: alt.lang.asm
Date: Thu, 11 Feb 2021 15:34 UTC
X-Received: by 2002:ac8:6f06:: with SMTP id g6mr7812816qtv.360.1613057674095; Thu, 11 Feb 2021 07:34:34 -0800 (PST)
X-Received: by 2002:a9d:2270:: with SMTP id o103mr5924048ota.303.1613057673820; Thu, 11 Feb 2021 07:34:33 -0800 (PST)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.etla.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: alt.lang.asm
Date: Thu, 11 Feb 2021 07:34:33 -0800 (PST)
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=217.62.209.66; posting-account=np6u_wkAAADxbE7UBGUIOm-csir6aX02
NNTP-Posting-Host: 217.62.209.66
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <97af1e0b-1e02-45ba-84d0-c17868919406n@googlegroups.com>
Subject: (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.
From: skybuck2...@hotmail.com (skybuck2000)
Injection-Date: Thu, 11 Feb 2021 15:34:34 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 21
View all headers
IPv4 Source Routing requests bug in all versions of windows:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-24074

IPv6 re-assembly bug in all versions of windows that have IPv6:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-24094

Work around, run these two commands in ms-dos prompt with admin rights, (this will make system more secure):
netsh int ipv4 set global sourceroutingbehavior=drop
Netsh int ipv6 set global reassemblylimit=0

To re-enable later or never, (this will make system insecure):
netsh int ipv4 set global sourceroutingbehavior=dontforward
Netsh int ipv6 set global reassemblylimit=267748640

Skybuck's take on this:

To me it seems these are some kind of ipv4 and ipv6 fragment/re-assembly bugs in combination with these features/source request.

In default state windows systems might be protected, though this is unsure to me at this moment. Therefore it seems very wise to run these two commands to protect older systems. This also include the still popular and valuable windows 7 operating system !

Bye for now,
  Skybuck.


Subject: Re: (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.
From: skybuck2000
Newsgroups: alt.lang.asm
Date: Thu, 11 Feb 2021 23:57 UTC
References: 1
X-Received: by 2002:a37:b1c2:: with SMTP id a185mr320870qkf.95.1613087837826; Thu, 11 Feb 2021 15:57:17 -0800 (PST)
X-Received: by 2002:a9d:53cc:: with SMTP id i12mr327195oth.358.1613087837328; Thu, 11 Feb 2021 15:57:17 -0800 (PST)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: alt.lang.asm
Date: Thu, 11 Feb 2021 15:57:17 -0800 (PST)
In-Reply-To: <97af1e0b-1e02-45ba-84d0-c17868919406n@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=217.62.209.66; posting-account=np6u_wkAAADxbE7UBGUIOm-csir6aX02
NNTP-Posting-Host: 217.62.209.66
References: <97af1e0b-1e02-45ba-84d0-c17868919406n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <537f7ce3-175d-4db6-bab1-5d8f1f66f3b4n@googlegroups.com>
Subject: Re: (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.
From: skybuck2...@hotmail.com (skybuck2000)
Injection-Date: Thu, 11 Feb 2021 23:57:17 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 513
View all headers
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.




Gont, et al.              Best Current Practice                 [Page 9]

 
RFC 7126            Filtering of IP-Optioned Packets       February 2014


4.3.4.  Operational and Interoperability Impact if Blocked

   Network troubleshooting techniques that may employ the LSRR option
   (such as ping or traceroute with the appropriate arguments) would
   break when using the LSRR option.  (Ping and traceroute without IPv4
   options are not impacted.)  Nevertheless, it should be noted that it
   is virtually impossible to use the LSRR option for troubleshooting,
   due to widespread dropping of packets that contain the option.

4.3.5.  Advice

   Routers, security gateways, and firewalls SHOULD implement an option-
   specific configuration knob to select whether packets with this
   option are dropped, packets with this IP option are forwarded as if
   they did not contain this IP option, or packets with this option are
   processed and forwarded as per [RFC0791].  The default setting for
   this knob SHOULD be "drop", and the default setting MUST be
   documented.

Click here to read the complete article
Subject: Re: (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.
From: skybuck2000
Newsgroups: alt.lang.asm
Date: Fri, 12 Feb 2021 00:12 UTC
References: 1 2
X-Received: by 2002:ac8:75cb:: with SMTP id z11mr251261qtq.153.1613088734550;
Thu, 11 Feb 2021 16:12:14 -0800 (PST)
X-Received: by 2002:a05:6830:2092:: with SMTP id y18mr386237otq.76.1613088734206;
Thu, 11 Feb 2021 16:12:14 -0800 (PST)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: alt.lang.asm
Date: Thu, 11 Feb 2021 16:12:13 -0800 (PST)
In-Reply-To: <537f7ce3-175d-4db6-bab1-5d8f1f66f3b4n@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=217.62.209.66; posting-account=np6u_wkAAADxbE7UBGUIOm-csir6aX02
NNTP-Posting-Host: 217.62.209.66
References: <97af1e0b-1e02-45ba-84d0-c17868919406n@googlegroups.com> <537f7ce3-175d-4db6-bab1-5d8f1f66f3b4n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <29e7cc8f-81c4-4a1c-836c-433feb6068fdn@googlegroups.com>
Subject: Re: (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.
From: skybuck2...@hotmail.com (skybuck2000)
Injection-Date: Fri, 12 Feb 2021 00:12:14 +0000
Content-Type: text/plain; charset="UTF-8"
View all headers
From the work around it can be determined that it has something to do with "forwarding" and "routing".

Taking a look at windows nt 3.5 source code, iproute.c is my main suspect containing the bug.

Most likely the bug is in this piece of source code:

"
//** IPForward - Forward a packet.
//
//  The routine called when we need to forward a packet. We check if we're supposed
//  to act as a gateway, and if we are and the incoming packet is a bcast we check
//  and see if we're supposed to forward broadcasts. Assuming we're supposed to
//  forward it, we will process any options. If we find some, we do some validation
//  to make sure everything is good. After that, we look up the next hop. If we can't
//  find one, we'll issue an error.  Then we get a packet and buffers, and send it.
//
//  Input:  SrcNTE          - NTE for net on which we received this.
//          Header          - Pointer to received IPheader.
//          HeaderLength    - Length of header.
//          Data            - Pointer to data to be forwarded.
//          BufferLength    - Length in bytes available in the buffer.
//          DestType        - Type of destination.
//
//  Returns: Nothing.
//
void
IPForward(NetTableEntry *SrcNTE, IPHeader UNALIGNED *Header, uint HeaderLength,
    void *Data, uint BufferLength, NDIS_HANDLE LContext1, uint LContext2,
    uchar DestType)
{
    uchar           *Options;
    uchar           OptLength;
    OptIndex        Index;
    IPAddr          DestAddr;       // IP address we're routing towards.
    uchar           SendOnSource = FALSE;
    IPAddr          NextHop;        // Next hop IP address.
    PNDIS_PACKET    Packet;
    FWContext       *FWC;
    IPHeader        *NewHeader;     // New header.
    NDIS_STATUS     Status;
    uint            DataLength;
CTELockHandle TableHandle;
uchar ErrIndex;
IPAddr OutAddr; // Address of interface we're send out on.
Interface *IF; // Interface we're sending out on.
uint MTU;

    if (ForwardPackets) {

        DestAddr = Header->iph_dest;

        // If it's a broadcast, see if we can forward it. We won't forward it if broadcast
        // forwarding is turned off, or the destination if the local (all one's) broadcast,
        // or it's a multicast (Class D address). We'll pass through subnet broadcasts in
        // case there's a source route. This would be odd - maybe we should disable this?
        if (IS_BCAST_DEST(DestType)) {
            if (!ForwardBCast) {
                if (DestType > DEST_REMOTE)
                    IPSInfo.ipsi_inaddrerrors++;
                return;
            }
            if ((DestAddr == IP_LOCAL_BCST) ||
                (DestAddr == IP_ZERO_BCST) ||
(DestType == DEST_SN_BCAST) ||
                CLASSD_ADDR(DestAddr)) {
                return;
            }
        } else
            if (DestType == DEST_REMOTE) {
                SrcNTE = BestNTEForIF(Header->iph_src, SrcNTE->nte_if);
if (SrcNTE == NULL) {
// Something bad happened.
CTEAssert(FALSE);
return;
}
}

        // If the TTL would expire, send a message.
        if (Header->iph_ttl <= 1) {
            IPSInfo.ipsi_inhdrerrors++;
            SendICMPErr(SrcNTE->nte_addr, Header, ICMP_TIME_EXCEED, TTL_IN_TRANSIT,0);
            return;
        }

        DataLength = net_short(Header->iph_length) - HeaderLength;

        Index.oi_srtype = NO_SR;            // So we know we don't have a source route.
        Index.oi_srindex = MAX_OPT_SIZE;
        Index.oi_rrindex = MAX_OPT_SIZE;
        Index.oi_tsindex = MAX_OPT_SIZE;

        // Now check for options, and process any we find.
        if (HeaderLength != sizeof(IPHeader)) {
            IPOptInfo       OptInfo;

            OptInfo.ioi_options = (uchar *)(Header + 1);
            OptInfo.ioi_optlength = HeaderLength - sizeof(IPHeader);
            // Validate options, and set up indices.
            if ((ErrIndex = ParseRcvdOptions(&OptInfo, &Index)) < MAX_OPT_SIZE) {
                IPSInfo.ipsi_inhdrerrors++;
                SendICMPErr(SrcNTE->nte_addr, Header, ICMP_PARAM_PROBLEM, PTR_VALID,
                    net_long((ulong)ErrIndex + sizeof(IPHeader)));
                return;
            }

            Options = CTEAllocMem(OptInfo.ioi_optlength);
            if (!Options) {
                IPSInfo.ipsi_outdiscards++;
                return;                                 // Couldn't get an
            }                                           // option buffer, return;

            // Now copy into our buffer.
            CTEMemCopy(Options, OptInfo.ioi_options, OptLength = OptInfo.ioi_optlength);

            // See if we have a source routing option, and if so we may need to process it. If
            // we have one, and the destination in the header is us, we need to update the
            // route and the header.
            if (Index.oi_srindex != MAX_OPT_SIZE) {
                if (DestType >= DEST_REMOTE) {          // Not for us.
                    if (Index.oi_srtype == IP_OPT_SSRR) {
                        // This packet is strict source routed, but we're not the destination!
                        // We can't continue from here - perhaps we should send an ICMP, but
                        // I'm not sure which one it would be.
                        CTEFreeMem(Options);
                        IPSInfo.ipsi_inaddrerrors++;
                        return;
                    }
                    Index.oi_srindex = MAX_OPT_SIZE;    // Don't need to update this.

                } else {    // This came here, we need to update the destination address.
                    uchar   *SROpt = Options + Index.oi_srindex;
                    uchar   Pointer;

                    Pointer = SROpt[IP_OPT_PTR] - 1;    // Index starts from one.

                    // Get the next hop address, and see if it's a broadcast.
                    DestAddr = *(IPAddr UNALIGNED *)&SROpt[Pointer];
                    DestType = GetAddrType(DestAddr);       // Find address type.

Click here to read the complete article
1
rocksolid light 0.7.2
clearneti2ptor