full-disclosure - Re: debugfs exploit for a number of Android devices

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <502B9FAC.20009@gmail.com>
Date: Wed, 15 Aug 2012 09:10:04 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: arpruss@...il.com, full-disclosure@...ts.grok.org.uk
Subject: Re: debugfs exploit for a number of Android
	devices

> I haven't seen a reference to this in the archives, so for the sake of
> completeness here it is:
> http://forum.xda-developers.com/showthread.php?t=1790104
>
> 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.

Regards,
Dan

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/