It was found that there are insufficient ASN.1 sequence length checks (a.k.a. an array index error) in the Linux kernel in the snmp_version() and snmp_helper() functions in the net/ipv4/netfilter/nf_nat_snmp_basic_main.c in the [nf_nat_snmp_basic] module making out-of-bounds read and write operations possible. A unprivileged local attacker can use this flaw to cause a kernel OOPS condition and thus a denial of service (DoS). Due to the nature of the flaw, an attack from the network or privilege escalation cannot be fully ruled out, although we believe it is unlikely.
An upstream commit:
Created kernel tracking bugs for this issue:
Affects: fedora-all [bug 1683192]
Jann Horn <firstname.lastname@example.org>
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
*** Bug 1679764 has been marked as a duplicate of this bug. ***
Name: Jann Horn