Allele Security Alert
ASA-2019-00124
Identifier(s)
ASA-2019-00124, CVE-2019-9213
Title
Virtual address 0 (NULL) is mappable via privileged write() to /proc/*/mem
Vendor(s)
Linux foundation
Product(s)
Linux kernel
Affected version(s)
Linux kernel versions before 5.0
Linux kernel versions 4.20.x before 4.20.14
Linux kernel versions 4.19.x before 4.19.27
Linux kernel versions 4.14.x before 4.14.105
Linux kernel versions 4.9.x before 4.9.162
Linux kernel versions 4.4.x before 4.4.177
Linux kernel versions 4.1.x before 4.1.18
Linux kernel versions 3.18.x before 3.18.137
Linux kernel versions 3.16.x before 3.16.66
Linux kernel since the following commit:
security: protect from stack expantion into low vm addresses
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8869477a49c3
Fixed version(s)
Linux kernel version 5.0
Linux kernel version 4.20.14
Linux kernel version 4.19.27
Linux kernel version 4.14.105
Linux kernel version 4.9.162
Linux kernel version 4.4.177
Linux kernel version 4.1.18
Linux kernel version 3.18.137
Linux kernel version 3.16.66
Linux kernel with the following commit applied:
mm: enforce min addr even if capable() in expand_downwards()
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a1d52994d440e21def1c2174932410b4f2a98a1
Proof of concept
Yes
Description
In the Linux kernel, expand_downwards() in mm/mmap.c lacks a check for the mmap minimum address, which makes it easier for attackers to exploit kernel NULL pointer dereferences on non-SMAP platforms. This is related to a capability check for the wrong task.
Technical details
The problem is in the following code path:
mem_write -> mem_rw -> access_remote_vm -> __access_remote_vm -> get_user_pages_remote -> __get_user_pages_locked -> __get_user_pages -> find_extend_vma
Then, if the VMA in question has the VM_GROWSDOWN flag set:
expand_stack -> expand_downwards -> security_mmap_addr -> cap_mmap_addr
This, if the address is below dac_mmap_min_addr, does a capability check:
ret = cap_capable(current_cred(), &init_user_ns, CAP_SYS_RAWIO, SECURITY_CAP_AUDIT);
But this check is performed against current_cred(), which are the creds of the task doing the write(), not the creds of the task whose VMA is being changed.
Credits
Jann Horn (Google Project Zero)
Reference(s)
Issue 1792: Linux: virtual address 0 is mappable via privileged write() to /proc/*/mem
https://bugs.chromium.org/p/project-zero/issues/detail?id=1792
Linux kernel: OOB R/W in SNMP NAT module (CVE-2019-9162); virtual address 0 mappable (CVE-2019-9213)
https://seclists.org/oss-sec/2019/q1/166
mm: enforce min addr even if capable() in expand_downwards()
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a1d52994d440e21def1c2174932410b4f2a98a1
security: protect from stack expantion into low vm addresses
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8869477a49c3
mm: enforce min addr even if capable() in expand_downwards()
https://github.com/torvalds/linux/commit/0a1d52994d440e21def1c2174932410b4f2a98a1
security: protect from stack expantion into low vm addresses
https://github.com/torvalds/linux/commit/8869477a49c3e99def1fcdadd6bbc407fea14b45
Linux 5.0
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0
Linux 4.20.14
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.20.14
Linux 4.19.27
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.27
Linux 4.14.105
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.105
Linux 4.9.162
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.162
Linux 4.4.177
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.177
Linux 4.1.18
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.18
Linux 3.18.137
https://cdn.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.18.137
Linux 3.16.66
https://cdn.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.16.66
Linux kernel exploitation experiments
https://github.com/a13xp0p0v/kernel-hack-drill
CVE-2019-9213 - Red Hat Customer Portal
https://access.redhat.com/security/cve/CVE-2019-9213
CVE-2019-9213
https://security-tracker.debian.org/tracker/CVE-2019-9213
CVE-2019-9213 | SUSE
https://www.suse.com/security/cve/CVE-2019-9213
https://people.canonical.com/~ubuntu-security/cve/CVE-2019-9213.html
CVE-2019-9213
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9213
CVE-2019-9213
https://nvd.nist.gov/vuln/detail/CVE-2019-9213
If there is any error in this alert or you wish a comprehensive analysis, let us know.
Last modified: November 29, 2019