Related Weaknesses
| CWE-ID |
Weakness Name |
Source |
| CWE-416 |
Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
|
| CWE-787 |
Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer. |
|
Metrics
| Metrics |
Score |
Severity |
CVSS Vector |
Source |
| V3.0 |
7.8 |
HIGH |
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Base: Exploitabilty MetricsThe Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component. Attack Vector This metric reflects the context by which vulnerability exploitation is possible. A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file. Attack Complexity This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability. Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component. Privileges Required This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. The attacker is authorized with (i.e. requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources. User Interaction This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. The vulnerable system can be exploited without interaction from any user. Base: Scope MetricsAn important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges. Scope Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports. An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same. Base: Impact MetricsThe Impact metrics refer to the properties of the impacted component. Confidentiality Impact This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server. Integrity Impact This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component. Availability Impact This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable). Temporal MetricsThe Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability. Environmental Metrics
|
[email protected] |
| V2 |
7.2 |
|
AV:L/AC:L/Au:N/C:C/I:C/A:C |
[email protected] |
EPSS
EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.
EPSS Score
The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.
EPSS Percentile
The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.
Exploit information
Exploit Database EDB-ID : 46356
Publication date : 2019-02-11 23h00 +00:00
Author : Google Security Research
EDB Verified : Yes
This bug report describes *two* different issues in different branches of the
binder kernel code.
The first issue is in the upstream Linux kernel,
commit 7f3dc0088b98 ("binder: fix proc->files use-after-free");
the second issue is in the wahoo kernel (and maybe elsewhere? but at least the
android common kernel for 4.4 doesn't seem to contain this code...),
commit 1b652c7c29b7 ("FROMLIST: binder: fix proc->files use-after-free")
(WARNING: NOT the same as "UPSTREAM: binder: fix proc->files use-after-free" in
the android common kernel!).
Some background: In the Linux kernel, normally, when a `struct file *` is read
from the file descriptor table, the reference counter of the `struct file` is
bumped to account for the extra reference; this happens in fget(). Later, if the
extra reference is not needed anymore, the refcount is dropped via fput().
A negative effect of this is that, if the `struct file` is frequently accessed,
the cacheline containing the reference count is constantly dirty; and if the
`struct file` is used by multiple tasks in parallel, cache line bouncing occurs.
Linux provides the helpers fdget() and fdput() to avoid this overhead.
fdget() checks whether the reference count of the file descriptor table is 1,
implying that the current task has sole ownership of the file descriptor table
and no concurrent modifications of the file descriptor table can occur. If this
check succeeds, fdget() then omits the reference count increment on the
`struct file`. fdget() sets a flag in its return value that signals to fdput()
whether a reference count has been taken. If so, fdput() uses the normal fput()
logic; if not, fdput() does nothing.
This optimization relies on a few rules, including:
A) A reference taken via fdget() must be dropped with fdput() before the end of
the syscall.
B) A task's reference to its file descriptor table may only be duplicated for
writing if that task is known to not be between fdget() and fdput().
C) A task that might be between an elided fdget() and fdput() must not
use ksys_close() on the same file descriptor number as used for fdget().
The current upstream code violates rule C. The following sequence of events can
cause fput() to drop the reference count of an in-use binder file to drop to
zero:
Task A and task B are connected via binder; task A has /dev/binder open at
file descriptor number X. Both tasks are single-threaded.
- task B sends a binder message with a file descriptor array (BINDER_TYPE_FDA)
containing one file descriptor to task A
- task A reads the binder message with the translated file descriptor number Y
- task A uses dup2(X, Y) to overwrite file descriptor Y with the /dev/binder
file
- task A unmaps the userspace binder memory mapping; the reference count on
task A's /dev/binder is now 2
- task A closes file descriptor X; the reference count on task A's /dev/binder
is now 1
- task A invokes the BC_FREE_BUFFER command on file descriptor X to release the
incoming binder message
- fdget() elides the reference count increment, since the file descriptor
table is not shared
- the BC_FREE_BUFFER handler removes the file descriptor table entry for X and
decrements the reference count of task A's /dev/binder file to zero
Because fput() uses the task work mechanism to actually free the file, this
doesn't immediately cause a use-after-free that KASAN can detect; for that, the
following sequence of events works:
[...]
- task A closes file descriptor X; the reference count on task A's /dev/binder
is now 1
- task A forks off a child, task C, duplicating the file descriptor table; the
reference count on task A's /dev/binder is now 2
- task A invokes the BC_FREE_BUFFER command on file descriptor X to release the
incoming binder message
- fdget() in ksys_ioctl() elides the reference count increment, since the file
descriptor table is not shared
- the BC_FREE_BUFFER handler removes the file descriptor table entry for X and
decrements the reference count of task A's /dev/binder file to 1
- task C calls close(X), which drops the reference count of task A's
/dev/binder to 0 and frees it
- task A continues processing of the ioctl and accesses some property of e.g.
the binder_proc => KASAN-detectable UAF
To reproduce this on an upstream git master kernel on a normal machine, unpack
the attached binder_fdget.tar, apply the patch
0001-binder-upstream-repro-aid.patch to the kernel (adds some logging and an
msleep() call), make sure that the kernel is configured with Binder and KASAN,
build and boot into the kernel, then build the PoC with ./compile.sh.
Invoke "./exploit_manager" in one terminal and "./exploit_client" in another
terminal. You should see a splat like this in dmesg:
=================
[ 90.900693] BUG: KASAN: use-after-free in mutex_lock+0x77/0xd0
[ 90.903933] Write of size 8 at addr ffff8881da262720 by task exploit_client/1222
[ 90.908991] CPU: 4 PID: 1222 Comm: exploit_client Tainted: G W 4.20.0-rc3+ #214
[ 90.911524] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[ 90.913989] Call Trace:
[ 90.914768] dump_stack+0x71/0xab
[ 90.915782] print_address_description+0x6a/0x270
[ 90.917199] kasan_report+0x260/0x380
[ 90.918307] ? mutex_lock+0x77/0xd0
[ 90.919387] mutex_lock+0x77/0xd0
[...]
[ 90.925971] binder_alloc_prepare_to_free+0x22/0x130
[ 90.927429] binder_thread_write+0x7c1/0x1b20
[...]
[ 90.944008] binder_ioctl+0x916/0xe80
[...]
[ 90.955530] do_vfs_ioctl+0x134/0x8f0
[...]
[ 90.961135] ksys_ioctl+0x70/0x80
[ 90.962070] __x64_sys_ioctl+0x3d/0x50
[ 90.963125] do_syscall_64+0x73/0x160
[ 90.964162] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[...]
[ 90.984647] Allocated by task 1222:
[ 90.985614] kasan_kmalloc+0xa0/0xd0
[ 90.986602] kmem_cache_alloc_trace+0x6e/0x1e0
[ 90.987818] binder_open+0x93/0x3d0
[ 90.988806] misc_open+0x18f/0x230
[ 90.989744] chrdev_open+0x14d/0x2d0
[ 90.990725] do_dentry_open+0x455/0x6b0
[ 90.991809] path_openat+0x52e/0x20d0
[ 90.992822] do_filp_open+0x124/0x1d0
[ 90.993824] do_sys_open+0x213/0x2c0
[ 90.994802] do_syscall_64+0x73/0x160
[ 90.995804] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 90.997605] Freed by task 12:
[ 90.998420] __kasan_slab_free+0x130/0x180
[ 90.999538] kfree+0x90/0x1d0
[ 91.000361] binder_deferred_func+0x7b1/0x890
[ 91.001564] process_one_work+0x42b/0x790
[ 91.002651] worker_thread+0x69/0x690
[ 91.003647] kthread+0x1ae/0x1d0
[ 91.004530] ret_from_fork+0x35/0x40
[ 91.005919] The buggy address belongs to the object at ffff8881da2625a8
which belongs to the cache kmalloc-1k of size 1024
[ 91.009267] The buggy address is located 376 bytes inside of
1024-byte region [ffff8881da2625a8, ffff8881da2629a8)
[...]
=================
The code in the msm kernel (at least branches android-msm-wahoo-4.4-pie and
android-msm-wahoo-4.4-pie-qpr1) contains a different bug. In this version of the
code, the binder driver does not hold a long-lived reference to the files_struct
of each task, as it used to, but instead uses
binder_get_files_struct()->get_files_struct() to grab the file descriptor table
of the target task for short-lived operations. Apart from the problems in
interaction with non-bounded privilege transitions, this is also problematic
because it violates rule B: In particular task_close_fd() can close a file
descriptor in another process while that other process is potentially in the
middle of a filesystem operation that uses an elided fdget().
The bug triggers in the following scenario (not quite what my PoC does, but
should give you the basic idea):
- task B opens some file as file descriptor number Y
- task A starts sending a transaction to task B
- the kernel transfers one file descriptor to task B, creating file descriptor
number X in task B
- task B uses dup2(Y, X) to override file descriptor number X with file F
- task B closes file descriptor number Y
- task B enters a syscall such as read()/write()/... on file descriptor number
X
- the kernel continues transferring the transaction from A, but encounters an
error (e.g. invalid fd number) and has to bail out, triggering cleanup of
already-transferred file descriptors
- while task B is in the middle of a syscall, task A closes task B's file
descriptor number X
To test this on-device, I would have to write code to talk to the service
manager and somehow get the service manager to connect two binder files with
each other for me, which seems complicated. Therefore, instead, I took the
following files from the Android wahoo kernel and copied them into an upstream
git master tree, then fixed up the incompatibilities:
drivers/android/Kconfig
drivers/android/Makefile
drivers/android/binder.c
drivers/android/binder_alloc.c
drivers/android/binder_alloc.h
drivers/android/binder_trace.h
include/uapi/linux/android/binder.h
The attached binder_fdget_wahoo.tar contains three patches:
0001-copy-over-binder-files-from-wahoo-4.4.patch: copy the files from wahoo into
the upstream git master tree
0002-fix-up-for-git-master.patch: make it build
0003-binder-stuff-for-testing.patch: add some sleeps and prints for reproducing
the bug
Apply these to the upstream kernel and build it (make sure that it is configured
to build with binder and KASAN). Then compile the wahoo PoC with ./compile.sh,
run ./exploit_manager in one terminal, and run ./exploit_client in another
terminal. You should get a splat like this:
=================
[ 204.465949] BUG: KASAN: use-after-free in _raw_spin_lock+0x78/0xe0
[ 204.469894] Write of size 4 at addr ffff8881db79e84c by task exploit_client/1255
[ 204.473958] CPU: 6 PID: 1255 Comm: exploit_client Not tainted 4.20.0-rc3+ #218
[ 204.476098] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[ 204.479413] Call Trace:
[ 204.480169] dump_stack+0x71/0xab
[ 204.481187] print_address_description+0x6a/0x270
[ 204.482591] kasan_report+0x260/0x380
[ 204.484156] ? _raw_spin_lock+0x78/0xe0
[ 204.485336] _raw_spin_lock+0x78/0xe0
[...]
[ 204.491337] binder_update_ref_for_handle+0x34/0x280
[ 204.492811] binder_thread_write+0xab4/0x1b70
[...]
[ 204.511627] binder_ioctl_write_read.isra.55+0x155/0x3e0
[...]
[ 204.516826] binder_ioctl+0x5da/0x880
[...]
[ 204.522154] do_vfs_ioctl+0x134/0x8f0
[...]
[ 204.530212] ksys_ioctl+0x70/0x80
[ 204.531142] __x64_sys_ioctl+0x3d/0x50
[ 204.532193] do_syscall_64+0x73/0x160
[ 204.533495] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[...]
[ 204.553564] Allocated by task 1255:
[ 204.554521] kasan_kmalloc+0xa0/0xd0
[ 204.555507] kmem_cache_alloc_trace+0x6e/0x1e0
[ 204.556729] binder_open+0x90/0x400
[ 204.557681] misc_open+0x18f/0x230
[ 204.558603] chrdev_open+0x14d/0x2d0
[ 204.559573] do_dentry_open+0x455/0x6b0
[ 204.560620] path_openat+0x52e/0x20d0
[ 204.561618] do_filp_open+0x124/0x1d0
[ 204.562617] do_sys_open+0x213/0x2c0
[ 204.563588] do_syscall_64+0x73/0x160
[ 204.564580] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 204.566378] Freed by task 7:
[ 204.567156] __kasan_slab_free+0x130/0x180
[ 204.568251] kfree+0x90/0x1d0
[ 204.569059] binder_deferred_func+0x742/0x7d0
[ 204.570229] process_one_work+0x42b/0x790
[ 204.571304] worker_thread+0x69/0x690
[ 204.572289] kthread+0x1ae/0x1d0
[ 204.573265] ret_from_fork+0x35/0x40
[ 204.574643] The buggy address belongs to the object at ffff8881db79e628
which belongs to the cache kmalloc-1k of size 1024
[ 204.578833] The buggy address is located 548 bytes inside of
1024-byte region [ffff8881db79e628, ffff8881db79ea28)
[...]
=================
I think the robust fix for this might be to change ksys_ioctl() and the compat
ioctl syscall to use fget()/fput() instead of fdget()/fdput(). Unless someone
out there has a workload that very frequently calls ioctl() from concurrent
single-threaded processes that share a struct file, I doubt that this would have
significant performance impact, and I think it should be an appropriate fix for
the upstream kernel, too.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46356.zip
Products Mentioned
Configuraton 0
Google>>Android >> Version -
References
