[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190310181420.GA29155@openwall.com>
Date: Sun, 10 Mar 2019 19:14:20 +0100
From: Solar Designer <solar@...nwall.com>
To: Jann Horn <jannhorn@...glemail.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Linux kernel: OOB R/W in SNMP NAT module (CVE-2019-9162); virtual address 0 mappable (CVE-2019-9213)
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 & 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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
