Re: Linux kernel: OOB R/W in SNMP NAT module (CVE-2019-9162); virtual address 0 mappable (CVE-2019-9213)

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: Linux kernel: OOB R/W in SNMP NAT module (CVE-2019-9162); virtual address 0 mappable (CVE-2019-9213)

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: Solar Designer &lt;solar () openwall com&gt;

Date: Sun, 10 Mar 2019 19:14:20 +0100

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
On Tue, Mar 05, 2019 at 10:02:49PM +0100, Jann Horn wrote:
virtual address 0 is mappable via privileged write() to /proc/*/mem
https://bugs.chromium.org/p/project-zero/issues/detail?id=1792
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a1d52994d440e21def1c2174932410b4f2a98a1
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.20.14
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.27
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.105
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.162

I think this is a big deal because (near-)NULL pointer dereferences are
a more common bug class than mmap_min_addr bypasses (like this one bug
is), so given that a combination of both is needed for a worse-than-DoS
exploit we should reasonably treat mmap_min_addr bypasses and not NULL
pointer dereferences as the actual vulnerabilities.

https://access.redhat.com/security/cve/cve-2019-9213 currently lists
RHEL 5, 6, 7 as "Under investigation" (and only RHEL7's kernel-alt as
"Affected"), but per my quick look I'd expect RHEL 5 &amp; 6 to be safe from
this (/proc/*/mem write() not yet enabled) and RHEL 7 to be vulnerable
(already has /proc/*/mem write(), although something else _might_ save
it from being vulnerable).

Upstream introduced /proc/*/mem write(2) support in 2.6.39, in 2011:

https://lwn.net/Articles/433326/

A related vulnerability that this exposed was found and fixed in 2012:

https://www.openwall.com/lists/oss-security/2012/01/18/1
https://git.zx2c4.com/CVE-2012-0056/about/
https://lwn.net/Articles/476947/

In its aftermath, a sysctl to (dis)allow /proc/*/mem read and/or write
was proposed:

https://lwn.net/Articles/476832/

Apparently, this idea was promptly dropped:

https://www.openwall.com/lists/kernel-hardening/2012/01/31/1

not to pollute the "kernel." sysctl namespace with various security
hardening and legacy feature knobs like this.  Unfortunately, it looks
like no alternative was proposed.  Perhaps this should be revisited.

Also, I think that a way to enforce mmap_min_addr regardless of any
process privileges should be introduced - perhaps as yet another sysctl
under some appropriate namespace, and/or a kernel configuration option.

Yes, having this kind of enforcement by default will break dosemu, but
that's legacy software that hardly anyone still uses (especially now
that we have dosbox and CPUs powerful enough for it).  We even already
have kernel configuration options CONFIG_VM86 and
CONFIG_MODIFY_LDT_SYSCALL.  Maybe it'd make sense to tie the default for
the mmap_min_addr enforcement sysctl to CONFIG_VM86, or would that be
unintuitive?  A topic for LKML.

Alexander

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

Linux kernel: OOB R/W in SNMP NAT module (CVE-2019-9162); virtual address 0 mappable (CVE-2019-9213) Jann Horn (Mar 06)

Re: Linux kernel: OOB R/W in SNMP NAT module (CVE-2019-9162); virtual address 0 mappable (CVE-2019-9213) Solar Designer (Mar 10)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->