Android sdcardfs changes current>fs without proper locking Vulnerability / Exploit
/
/
/
Exploits / Vulnerability Discovered : 2018-10-08 |
Type : dos |
Platform : android
This exploit / vulnerability Android sdcardfs changes current>fs without proper locking is for educational purposes only and if it is used you will do on your own risk!
Android used to use a FUSE filesystem to emulate external storage, but nowadays
an in-kernel filesystem called "sdcardfs" is used instead. This filesystem does
not exist in the upstream Linux kernel, but does exist in the AOSP common kernel
tree.
In sdcardfs_create() and sdcardfs_mkdir()
(https://android.googlesource.com/kernel/common/+/android-4.14/fs/sdcardfs/inode.c),
the following code is used to temporarily override the umask while calling into
the lower filesystem:
This is wrong; as a comment in include/linux/sched.h explains, ->fs must not be
accessed without holding the corresponding task lock:
/* Protection against (de-)allocation: mm, files, fs, tty, keyrings, mems_allowed, mempolicy: */
spinlock_t alloc_lock;
For example, the procfs per-task entries "root" and "cwd" access the ->fs member
of remote tasks under the task lock:
static int proc_cwd_link(struct dentry *dentry, struct path *path)
{
struct task_struct *task = get_proc_task(d_inode(dentry));
int result = -ENOENT;
if (task) {
task_lock(task);
if (task->fs) {
get_fs_pwd(task->fs, path);
result = 0;
}
task_unlock(task);
put_task_struct(task);
}
return result;
}
This bug can be triggered by any context that can create files in an sdcardfs
mount, so normal applications with zero permissions can hit it (by using
/sdcard/Android/data/{packagename}/, which does not require the external storage
permission).
To reproduce the bug in a simple way, compile the attached poc_viaadb.c:
Now you should see a lot of "target: [...]" messages, followed by the device
freezing and rebooting.
After rebooting, pull a bug report via ADB ("adb bugreport") and look for a
crash message in the "LAST KMSG" section. The type of crash you see might vary,
since there's a lot of different ways in which this code can crash, but here's
an example of how it might look - a crash inside the memory allocator:
Note that another possible way in which the memory corruption can happen is
corruption of a spinlock - in that case, the phone won't panic, but messages
about a soft kernel lockup will start appearing in dmesg after some time.
Experimentally, that seems to happen if the chaos_worker thread is removed from
the PoC.
I have verified that this bug can also be triggered from a normal Android app.
To reproduce that, follow these steps:
- install https://play.google.com/store/apps/details?id=org.connectbot on the
phone
- run "adb shell mkdir /sdcard/Android/data/org.connectbot"
- run "/usr/local/google/home/jannh/my-android-toolchain/bin/aarch64-linux-android-gcc -static -o poc poc.c -pthread"
- run "adb push poc /sdcard/Android/data/org.connectbot/"
- on the phone, open a local terminal in connectbot
- in the terminal:
$ cd /data/data/org.connectbot
$ cp /sdcard/Android/data/org.connectbot/poc .
$ chmod +x poc
$ ./poc
Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/45558.zip
Android sdcardfs changes current>fs without proper locking