Re: (RCE) Remote Code Execution bug/exploit in TCP/IP and work arounds.
skybuck2000 <[email protected]>
| Newsgroups | alt.comp.lang.borland-delphi |
|---|---|
| Message-ID | <[email protected]> |
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.
Please note that treating packets with LSRR as if they did not
contain this option can result in such packets being sent to a
different device than the initially intended destination. With
appropriate ingress filtering, this should not open an attack vector
into the infrastructure. Nonetheless, it could result in traffic
that would never reach the initially intended destination. Dropping
these packets prevents unnecessary network traffic and does not make
end-to-end communication any worse.
4.4. Strict Source and Record Route (SSRR) (Type = 137)
4.4.1. Uses
This option allows the originating system to 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, and the destination host (end-system) must
use the reverse of the path contained in the received SSRR option.
This option is similar to the Loose Source and Record Route (LSRR)
option, with the only difference that in the case of SSRR, the route
specified in the option is the exact route the packet must take
(i.e., no other intervening routers are allowed to be in the route).
The SSRR option can be of help in debugging some network problems.
Some ISP peering agreements require support for this option in the
routers within the peer of the ISP.
Gont, et al. Best Current Practice [Page 10]
RFC 7126 Filtering of IP-Optioned Packets February 2014
4.4.2. Option Specification
Specified in RFC 791 [RFC0791].
4.4.3. Threats
The SSRR option has the same security implications as the LSRR
option. Please refer to Section 4.3 for a discussion of such
security implications.
4.4.4. Operational and Interoperability Impact if Blocked
Network troubleshooting techniques that may employ the SSRR option
(such as ping or traceroute with the appropriate arguments) would
break when using the SSRR option. (Ping and traceroute without IPv4
options are not impacted.) Nevertheless, it should be noted that it
is virtually impossible to use the SSRR option for trouble-shooting,
due to widespread dropping of packets that contain such option.
4.4.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.
Please note that treating packets with SSRR as if they did not
contain this option can result in such packets being sent to a
different device that the initially intended destination. With
appropriate ingress filtering this should not open an attack vector
into the infrastructure. Nonetheless, it could result in traffic
that would never reach the initially intended destination. Dropping
these packets prevents unnecessary network traffic, and does not make
end-to-end communication any worse.
"
"
4.12. DoD Basic Security Option (Type = 130)
4.12.1. Uses
This option [RFC1108] is used by Multi-Level Secure (MLS) end-systems
and intermediate systems in specific environments to:
o transmit from source to destination in a network standard
representation the common security labels required by computer
security models [Landwehr81],
o validate the datagram as appropriate for transmission from the
source and delivery to the destination, and,
o ensure that the route taken by the datagram is protected to the
level required by all protection authorities indicated on the
datagram.
The DoD Basic Security Option (BSO) was implemented in IRIX
[IRIX2008] and is currently implemented in a number of operating
systems (e.g., Security-Enhanced Linux [SELinux2008], Solaris
[Solaris2008], and Cisco IOS [Cisco-IPSO]). It is also currently
deployed in a number of high-security networks. These networks are
typically either in physically secure locations, protected by
military/governmental communications security equipment, or both.
Gont, et al. Best Current Practice [Page 17]
RFC 7126 Filtering of IP-Optioned Packets February 2014
Such networks are typically built using commercial off-the-shelf
(COTS) IP routers and Ethernet switches, but they are not normally
interconnected with the global public Internet. MLS systems are much
more widely deployed now than they were at the time the then-IESG
decided to remove IPSO (IP Security Options) from the IETF Standards
Track. Since nearly all MLS systems also support IPSO BSO and IPSO
ESO, this option is believed to have more deployment now than when
the IESG removed this option from the IETF Standards Track.
[RFC5570] describes a similar option recently defined for IPv6 and
has much more detailed explanations of how sensitivity label options
are used in real-world deployments.
4.12.2. Option Specification
It is specified by RFC 1108 [RFC1108], which obsoleted RFC 1038
[RFC1038] (which in turn obsoleted the Security Option defined in RFC
791 [RFC0791]).
RFC 791 [RFC0791] defined the "Security Option" (Type = 130),
which used the same option type as the DoD Basic Security option
discussed in this section. Later, RFC 1038 [RFC1038] revised the
IP security options, and in turn was obsoleted by RFC 1108
[RFC1108]. The "Security Option" specified in RFC 791 is
considered obsolete by Section 3.2.1.8 of RFC 1122 [RFC1122] and
Section 4.2.2.1 of RFC 1812 [RFC1812], and therefore the
discussion in this section is focused on the DoD Basic Security
option specified by RFC 1108 [RFC1108].
Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement
[this option]".
Some private IP networks consider IP router-based per-interface
selective filtering of packets based on (a) the presence of an
IPSO option (including BSO and ESO) and (b) the contents of that
IPSO option to be important for operational security reasons. The
recent IPv6 Common Architecture Label IPv6 Security Option
(CALIPSO) specification discusses this in additional detail,
albeit in an IPv6 context [RFC5570].
Such private IP networks commonly are built using both commercial
and open-source products -- for hosts, guards, firewalls,
switches, routers, etc. Some commercial IP routers support this
option, as do some IP routers that are built on top of MLS
operating systems (e.g., on top of Trusted Solaris [Solaris2008]
or Security-Enhanced Linux [SELinux2008]).
Gont, et al. Best Current Practice [Page 18]
RFC 7126 Filtering of IP-Optioned Packets February 2014
For example, many Cisco routers that run Cisco IOS include support
for selectively filtering packets that contain the IP Security
Options (IPSO) with per-interface granularity. This capability
has been present in many Cisco routers since the early 1990s
[Cisco-IPSO-Cmds]. Some government-sector products reportedly
also support the IP Security Options (IPSO), for example, CANEWARE
[RFC4949].
Support for the IPSO Basic Security Option also is included in the
"IPsec Configuration Policy Information Model" [RFC3585] and in
the "IPsec Security Policy Database Configuration MIB" [RFC4807].
Section 4.6.1 of the IP Security Domain of Interpretation
[RFC2407] includes support for labeled IPsec security associations
compatible with the IP Security Options. (Note: RFC 2407 was
obsoleted by [RFC4306], which was obsoleted by [RFC5996].)
4.12.3. Threats
Presence of this option in a packet does not by itself create any
specific new threat. Packets with this option ought not normally be
seen on the global public Internet.
4.12.4. Operational and Interoperability Impact if Blocked
If packets with this option are blocked or if the option is stripped
from the packet during transmission from source to destination, then
the packet itself is likely to be dropped by the receiver because it
is not properly labeled. In some cases, the receiver might receive
the packet but associate an incorrect sensitivity label with the
received data from the packet whose BSO was stripped by an
intermediate router or firewall. Associating an incorrect
sensitivity label can cause the received information either to be
handled as more sensitive than it really is ("upgrading") or as less
sensitive than it really is ("downgrading"), either of which is
problematic.
4.12.5. Advice
A given IP router, security gateway, or firewall has no way to know a
priori what environment it has been deployed into. Even closed IP
deployments generally use exactly the same commercial routers,
security gateways, and firewalls that are used in the public
Internet.
Gont, et al. Best Current Practice [Page 19]
RFC 7126 Filtering of IP-Optioned Packets February 2014
Since operational problems result in environments where this option
is needed if either the option is dropped or IP packets containing
this option are dropped, but no harm results if the option is carried
in environments where it is not needed, the default configuration
SHOULD NOT (a) modify or remove this IP option or (b) drop an IP
packet because the IP packet contains this option.
A given IP router, security gateway, or firewall MAY be configured to
drop this option or to drop IP packets containing this option in an
environment known to not use this option.
For auditing reasons, routers, security gateways, and firewalls
SHOULD be capable of logging the numbers of packets containing the
BSO on a per-interface basis. Also, routers, security gateways, and
firewalls SHOULD be capable of dropping packets based on the BSO
presence as well as the BSO values.
4.13. DoD Extended Security Option (Type = 133)
4.13.1. Uses
This option permits additional security labeling information, beyond
that present in the Basic Security Option (Section 4.12), to be
supplied in an IP datagram to meet the needs of registered
authorities.
4.13.2. Option Specification
The DoD Extended Security Option (ESO) is specified by RFC 1108
[RFC1108].
"
Perhaps option 133 might also create some insecurity and this could be ongoing research. Seems also related to defense/military kind of thing, maybe even offense ;) :)
I wasn't sure about the 130, it's a bit fuzzy, but it's confirmed to exist in this doc:
https://myweb.ntut.edu.tw/~kwke/DC2006/ipo.pdf
(Open with special reader).
These seem like new options. I wonder if these options and vunerabilities would be present in windows nt 4 source code which has leaked onto the internet.
I would guess the ip options implementation might be there cause it looks quite old, however these specific options are newer, 2008 and so, and probably are not in windows nt. However maybe it is still possible to fool windows nt with strange option parameters in fragments.
The original options "framework/implementation/rfc" is from 1981:
https://tools.ietf.org/html/rfc791
I just took a closer look at it, surprisingly these options already existed in 1981. So it's most likely it may have ended up in windows nt and then truely all windows versions are vunerable ! QUITE WOW THERE.
That means examining leaked windows nt 4 source code can shed more light on how to exactly re-create this exact vunerability for testing purpose ! ;) =D
Bye,
Skybuck =D