This document document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.
f955987c95afee36773fb986f0bf5b02f89c6d9a9973c325dcbc1e926676ad9aWhitepaper called Practical Insight into Injections. This document describes the meaning, working, implementation, and impact of injection vulnerabilities.
6a5ae62578e03e5fae5499de0f9c9079fad4dbf7a91b087fa7ff48b6c628a503This document describes a stack overflow vulnerability that was found in October, 2019 and presented in the Pwn2Own Mobile 2019 competition in November 2019. The vulnerability is present in the UPNP daemon (/usr/sbin/upnpd), running on NETGEAR R6700v3 router with firmware versions V1.0.4.82_10.0.57 and V1.0.4.84_10.0.58. It allows for an unauthenticated reset of the root password and then spawns a telnetd to remotely access the account.
3ccd57c2afc9c37bec7729262aa2b172845c46c639bdb363b6009f40ca166d05openssl_seal() is prone to use uninitialized memory that can be turned into a code execution. This document describes technical details of the journey to hijack apache2 requests. It is a very well written and thoroughly documented piece of research.
7328b4676384b96b2489eec8e7c79cb066123cadf924ac7ffb3cdc3f203e52c4This document details a stack based buffer overflow vulnerability within TestDisk version 6.14. A buffer overflow is triggered within the software when a malicious disk image is attempted to be recovered. This may be leveraged by an attacker to crash TestDisk and gain control of program execution. An attacker would have to coerce the victim to run TestDisk against their malicious image.
7a37d596089ffb1fa811b151734f591791c8d53219a3fdd9ea5cf26e1b134cc6This document describes a method of reading and displaying previously used framebuffers from a variety of popular graphics cards. In all 4 tested laptops the content of the VRAM was not erased upon reboot. It is also possible to show that the content of the host VRAM can be accessed from a VirtualBox guest, thereby leaking possibly confidential information from a trusted host into an untrusted guest machine.
b4aaca0e9f25ac73a7469f0a528eb42aba706fce9a84dc3b2b658276a24ab28dThe subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue.
fa98023a273f3231dab648bba72fdf7f52dd2a529b75297420d89773222e1c25This is a draft of IPv6 Extension Headers in the Real World. IPv6 Extension Headers allow for the extension of the IPv6 protocol, and provide support for some core functionality such as IPv6 fragmentation. However, IPv6 Extension Headers are deemed to present a challenge to IPv6 implementations and networks, and are known to be intentionally filtered in some existing IPv6 deployments. This summarizes the issues associated with IPv6 extension headers, and presents real-world data regarding the extent to which packets with IPv6 extension headers are filtered in the public Internet, and where in the network such filtering occurs. Additionally, it provides some guidance to operators in troubleshooting IPv6 blackholes resulting from the use of IPv6 extension headers. Finally, this document provides some advice to protocol designers, and discusses areas where further work might be needed.
4f100808cfb77d0cea54d4c5b190d179c17b9bd141d9d61bb6013c9766d28960This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique- local addresses.
aea1ddd79e402a7e6cae6940341f56386d8efe61f639f9142e54a9dda4b93d71IPv6 Extension Headers with Neighbor Discovery messages can be leveraged to circumvent simple local network protections, such as "Router Advertisement Guard". Since there is no legitimate use for IPv6 Extension Headers in Neighbor Discovery messages, and such use greatly complicates network monitoring and simple security mitigations such as RA-Guard, this document proposes that hosts silently ignore Neighbor Discovery messages that use IPv6 Extension Headers.
88c1519d37583c204027fbdd3ae3a25828b219b714e31c6f02daeaa96b3e1490This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks.
46631cfae65fdb6654ab9e329ade0ad4a20f0dd648446b6619a9a7a7b9676a5dThe subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) products, may inadvertently result in VPN traffic leaks. That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear on the local network. This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. Additionally, it discusses possible mitigations for the aforementioned issue.
9effe2e0fcf845f3f698a422ede8446c43df6f4d6472aafb96dd9a13c554fe6aThis document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues.
903ddcb4eca069a1e4d2bb9516b478eda66b60596e5457b418a1891a5c85d510The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by some implementations as "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that fragmentation-based attack vectors against traffic employing "atomic fragments" are completely eliminated.
feac00abce76ecd39bf1bb5b6c8804af13f2781cf51012a6d77c2a65a15888dfThis Internet Draft specifies the security implications of predictable fragment identification values in IPv6. It primarily focuses on countermeasures and mitigations.
38ea3e1b37df89d887edc1122b9c494c6779e2d1a05a220fd84e7a860c114607When an IPv6 node processing an IPv6 packet does not support an IPv6 option whose two-highest-order bits of the Option Type are '10', it is required to respond with an ICMPv6 Parameter Problem error message, even if the Destination Address of the packet was a multicast address. This feature provides an amplification vector, opening the door to an IPv6 version of the 'Smurf' Denial-of-Service (DoS) attack found in IPv4 networks. This document discusses the security implications of the aforementioned options, and formally updates RFC 2460 such that this attack vector is eliminated. Additionally, it describes a number of operational mitigations that could be deployed against this attack vector.
fb4961bf8357488cad14ec9267d3578def97ef7eb554541ecd35f6f1114d3f2cNeighbor Discovery is one of the core protocols of the IPv6 suite, and provides in IPv6 similar functions to those provided in the IPv4 protocol suite by the Address Resolution Protocol (ARP) and the Internet Control Message Protocol (ICMP). Its increased flexibility implies a somewhat increased complexity, which has resulted in a number of bugs and vulnerabilities found in popular implementations. This document provides guidance in the implementation of Neighbor Discovery, and documents issues that have affected popular implementations, in the hopes that the same issues do not repeat in other implementations.
00f877672b0a83b4dcaf16a1fcdecc660203df4d41d883646ee612d312f28996Recent security research seems to indicate that a number of IPv6 Neighbor Discovery implementations fail to implement basic sanity checks on received packets and/or fail to properly manage protocol data structures, being subject of trivial Denial of Service (DoS) attacks. Additionally, some IPv6 protocol features allow a number of attacks, ranging from man-in-the-middle to Denial of Service (DoS). This document discusses how to conduct a security/robustness assessment of Neighbor Discovery implementations by means of the SI6 Networks' IPv6 toolkit - a free, portable, and fully-featured IPv6 security assessment and trouble-shooting toolkit. Additionally, it provides pointers to ongoing work in this area, such that the aforementioned issues can be mitigated where appropriate.
00689e040da9e663b0fd1da9b9db7839be24c443cac8af491a0154bbdf4e6c94Neighbor Discovery is one of the core protocols of the IPv6 suite, and provides in IPv6 similar functions to those provided in the IPv4 protocol suite by the Address Resolution Protocol (ARP) and the Internet Control Message Protocol (ICMP). Its increased flexibility implies a somewhat increased complexity, which has resulted in a number of bugs and vulnerabilities found in popular implementations. This document provides guidance in the implementation of Neighbor Discovery, and documents issues that have affected popular implementations, in the hopes that the same issues do not repeat in other implementations.
776720fc1a25b2e907c4a468e1b19348a3ea339fb5630e617a7932a7e2ea9b23IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore IPv6 address scanning attacks have long been considered unfeasible. This document analyzes how traditional address scanning techniques apply to IPv6 networks, and also explores a number of other techniques that can be employed for IPv6 network reconnaissance. Additionally, this document formally obsoletes RFC 5157.
048514499a17396a23d97600ebed59b44a15828ff936fd26e985822b271d5d5fThis document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues.
2ca68992f1e854362ce2fe5d00357f8634430a612c312dba8e00ad5d586e35f4This document specifies a mechanism that can be implemented in layer-2 devices to mitigate attack vectors based on Neighbor Discovery messages. It is meant to complement other mechanisms implemented in layer-2 devices such as Router Advertisement Guard (RA-Guard) and DHCPv6-Shield, with the goal of achieving a comprehensive IPv6 First Hop Security solution. This document is motivated by the desire to achieve feature parity with IPv4 with respect to First Hop Security mechanisms.
b0bd48d4dfcf7fc338169df812038a282998457c61b3f8cfb9294a669b43f80aThis document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks.
2167f8ff55bb0233568e045e7042373efab0919dd45517725399c88fa634ea33This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues.
b620fd364138e64c6e10717389b326fd4176c5005ea71cbad80cb84096381fe9IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform host scanning attacks against IPv6 networks, and therefore IPv6 host scanning attacks have long been considered unfeasible. This document analyzes the IPv6 address configuration policies implemented in most popular IPv6 stacks, and identifies a number of patterns in the resulting addresses lead to a tremendous reduction in the host address search space, thus dismantling the myth that IPv6 host scanning attacks are unfeasible.
3e402c5d8f47be6b853bd514ed35744c8ab3f764907fb96603770a5396359be0This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users.
2be85628520d1d07881dc0a60f77204594c41e42519ec05b5b14ddb2b2f10d7f
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed