lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Aug 2012 09:10:04 -0400
From: Dan Rosenberg <>
Subject: Re: debugfs exploit for a number of Android

> I haven't seen a reference to this in the archives, so for the sake of
> completeness here it is:
> Looks like on a number of devices you can symlink the block device
> that gets mounted on /system to something like /data/local/tmp, and
> then use debugfs to edit that file system.  This allows rooting by the
> local user, but also all sorts of nastiness by malicious apps that
> might bundle a copy of debugfs and then change arbitrary files in
> /system, raise privileges, etc.

So many things wrong here.

What's actually happening is these devices have a line in their /init.rc
scripts, which are run at boot as root by the init process, saying
something like:

    mkdir /data/local/tmp 0771 shell shell

For awhile after the release of Android 4.0 (ICS), a change was
introduced to init where even if the "mkdir" of an init script failed,
the provided path would be chmod'd/chown'd anyway to fix up the file
permissions.  This has since been fixed.

In this exploit, some devices erroneously have /data/local as
group-writable by group "shell", which is assigned to the Android
Debugging Bridge (ADB) shell.  As a result, if you replace
/data/local/tmp with a symbolic link, the target will become
shell-writable on reboot.

The sane way to exploit this is to make /data shell-writable, and create
or modify /data/local.prop to contain the string "ro.kernel.qemu=1",
which causes ADB to retain root privileges rather than dropping to user
"shell" since this property convinces it that the device is the
emulator.  Using debugfs to modify the filesystem is completely
unnecessary and potentially destructive.

This also can't be used by malicious apps, since you need user/group
"shell" to replace /data/local/tmp with a symbolic link, and normal
applications cannot be granted this user/group.


Content of type "text/html" skipped

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists