| 1 |
El 15/02/11 16:52, Alex Efros escribió: |
| 2 |
> Hi!Quick Google and CVE searches shows there was many enough vulnerabilities |
| 3 |
> in all OSes (including Linux) IPv6 stack implementations. And, as we all |
| 4 |
> know, most of vulnerabilities will be found only after product become |
| 5 |
> popular and wide used, which doesn't happens to IPv6 yet. |
| 6 |
/me looks: |
| 7 |
"Summary: The ipv6_hop_jumbo function in net/ipv6/exthdrs.c in the Linux |
| 8 |
kernel before 2.6.32.4, when network namespaces are enabled, allows |
| 9 |
remote attackers to cause a denial of service (NULL pointer dereference) |
| 10 |
via an invalid IPv6 jumbogram, a related issue to CVE-2007-4567." |
| 11 |
Hardened kernels with UDEREF aren't vulnerable, also it was more than a |
| 12 |
year ago. |
| 13 |
|
| 14 |
"The selinux_parse_skb_ipv6 function in security/selinux/hooks.c in the |
| 15 |
Linux kernel before 2.6.12-rc4 allows remote attackers to cause a denial |
| 16 |
of service (OOPS) via vectors associated with an incorrect call to the |
| 17 |
ipv6_skip_exthdr function." |
| 18 |
"The ip6_dst_lookup_tail function in net/ipv6/ip6_output.c in the Linux |
| 19 |
kernel before 2.6.27 does not properly handle certain circumstances |
| 20 |
involving an IPv6 TUN network interface and a large number of neighbors, |
| 21 |
which allows attackers to cause a denial of service (NULL pointer |
| 22 |
dereference and OOPS) or possibly have unspecified other impact via |
| 23 |
unknown vectors." |
| 24 |
"Use-after-free vulnerability in net/ipv4/tcp_input.c in the Linux |
| 25 |
kernel 2.6 before 2.6.20, when IPV6_RECVPKTINFO is set on a listening |
| 26 |
socket, allows remote attackers to cause a denial of service (kernel |
| 27 |
panic) via a SYN packet while the socket is in a listening (TCP_LISTEN) |
| 28 |
state, which is not properly handled and causes the skb structure to be |
| 29 |
freed." |
| 30 |
Old kernels |
| 31 |
"The mipv6 daemon in UMIP 0.4 does not verify that netlink messages |
| 32 |
originated in the kernel, which allows local users to spoof netlink |
| 33 |
socket communication via a crafted unicast message." |
| 34 |
Not even linux. |
| 35 |
|
| 36 |
On apps: |
| 37 |
"Summary: The DHCPv6 server in ISC DHCP 4.0.x and 4.1.x before 4.1.2-P1, |
| 38 |
4.0-ESV and 4.1-ESV before 4.1-ESV-R1, and 4.2.x before 4.2.1b1 allows |
| 39 |
remote attackers to cause a denial of service (assertion failure and |
| 40 |
daemon crash) by sending a message over IPv6 for a declined and |
| 41 |
abandoned address." |
| 42 |
A DOS due to an assertion, bad but not SO bad. Anyway I doubt any |
| 43 |
security focused person will use DHCP if avoidable. |
| 44 |
|
| 45 |
"Summary: dns_internal.cc in Squid 3.1.6, when IPv6 DNS resolution is |
| 46 |
not enabled, accesses an invalid socket during an IPv4 TCP DNS query, |
| 47 |
which allows remote attackers to cause a denial of service (assertion |
| 48 |
failure and daemon exit) via vectors that trigger an IPv4 DNS response |
| 49 |
with the TC bit set." Bad yet not SO bad too, another DOS. |
| 50 |
|
| 51 |
Seriously I don't see any serious sec problem for hardened users in |
| 52 |
there which can't be solved by just not allowing ipv6 traffic/disabling |
| 53 |
the ipv6 stack from the kernel. |
| 54 |
Other than that I agree, the main difference I found is the lack of some |
| 55 |
sort of NAT to hide addresses but other than that ipv6 is not that |
| 56 |
different of ipv4 with a few extensions which are also there for ipv4. |
Archives