Closing recent thread

I will close the GingerBreak post now since most comments
are meanwhile about particular versions or not related to
Android OS at all. It turned out that GingerBreak works
on Froyo, Gingerbread and Honeycomb. For some versions it
needs minor fixes like in the detecting-phase but overall
it is a good and stable softbreak. Thanks to those who
sent patches or test reports.
Smartphone security and Android security in particular seems
to be the new hype (WTF?! HTTP is sending data in
plaintext!?) and therefore it is about time to
fall back to monitor-only mode. If you ever see a # on an
Android device in future, always remember who was pioneer-ing
exploit development on that platform and remember where
all these spin-offs came from.


I have had the choice of writing scientific papers about security
and exploits, or to code exploits. And I chose the latter.

yummy yummy, GingerBreak!

[If you want to support smartphone hacking, check this.]


Free your phone, once again. Successfully tested on Gingerbread
(2.3.3) but might also run on Froyo and Honeycomb. If it fails
there, some offsets and indexes need to be adjusted which is
left to the reader.
NOTE: You use it at your own risk! I am not responsible for any
failure or damage. Make sure to read the README file carefully!
Download it here.
If you successfully run it anywhere, please make a comment
with exact device model/firmware running.
[This software is >1 year old meanwhile, most vendors fixed
the bug already. So its unlikely to run on new devices.]




[Update] I replaced the tarball with a new version to fix
some glitches while parsing vold.fstab. Should now also
work on the GalaxyS. Thx to Chainfire.

Evolution of race condition exploits (CVE-2011-0727 trickery)

I recently did a PoC for CVE-2011-0727. It was possible
to have a one shot exploit for a race condition which
is just a few (2 or 3 or so) syscalls in range.
I compared it with an old exploit I did in 2002
for OpenBSD/FreeBSD against pppd. I uploaded it for
historical reasons so you can see the evolution of
race condition exploits.


In userland almost all race
conditions (time of check - time of use: TOCTOU-exploits)
cook down to races in the filesystem. While in kernel
you also have other shared resources like pages in userland
or counters.


The situation around 2000 or before was that most systems only
have had one core (single CPU) and therefore there was
no real concurrency. The scheduler had to interrupt the
target process just in the right time and have the
exploit process chosen to run afterwards.
How did one achieve that in 2000? Slow down the box
with many processes which a) increases the overall chance
that the target process is put asleap inside the race
(nice(2) calls also help if applicable)
and b) having many exploitation processes increases chances
of an exploitation process to be picked up next.
As can be seen in pppdx.pl ,one process was always
switching between a real file and a symlink and another
was constantly forking of a lot of pppd processes.
Sometimes, this needed a bit of tuning, depending on how
fast the target machine was. But eventually after a few
minutes it used to succeed.


Years after that a new framework was introduced on Linux
where one could register notification hooks which were
called when a certain event happened (e.g. creating the
target file). In early times you needed to register a signal
handler which was delivered and nowadays there is
the inotify framework which allows to register hooks for
almost all use-cases. I used inotify in the KDM exploit.
It saves the exploit coder from creating a lot of
processes which constantly poll for an event because
reading from the event descriptor just returns when the
event happened. On single CPU systems one might still need
to fork a lot of processes since the scheduler must put the
target process to sleep at the right time nevertheless.


Now we have 2011, and writing race condition exploits
for file races has never been easier. Even the
cheapest mom-and-dad PC has got at least 2 cores, probably
more. Therefore we have true concurrency since we can
make the target process run on a different CPU-core than
the exploitation process. Therefore we no longer rely
on scheduler to interrupt the target at the right time.
We can just poll or sleep on an event with a single process
and are still fast enough with changing the target file.
One just has to ensure that (if more than 2 cores exist)
multiple exploitation processes do not interfer
with each other if the event happens.
The CVE-2011-0727 GDM PoC is doing exactly that.
With the KDM exploit it basically worked the same
(best on multi-core CPU systems) but with using
the inotify framework.

Testing and stuff

Gingerbreak is not that easy and needs to be carefully tested.
Additionally, I wait for a particular device to be
released. I am not waiting for the fun of it.
But as always, no guarantee for anything.

Zimperlich sources

Since there were some requests I made the source of
the zygote jailbreak, zimperlich, available here.


Its straight forward code just like the adb setuid() one.
Most of the time I spent getting the Makefile right and
tricking zygote to spawn the right amount of processes and
calling setuid() once more when we are already running.
Keeping in mind that I dont like Java.


I solved this with a ContentProvider and giving it a new
process name in AndroidManifest.xml, so the ContentProvider
is guaranteed to be invoked as a new process.
If the NPROC limit is reached this will be the root
process.


Also, we want some native code carried along with the .apk
for convenient purposes. The Android ABI requires that
it must be named libNAME.so but in fact it is of
type ET_EXEC and not ET_DYN so we can execute it as
binary.


If you look at the Makefile you can imagine that this
was a horror. You require a complete Android build in
$AROOT to succeed.


Of course you could also mis-use the RageAgainstTheCage
binary to exploit zygote (and not adb) if called from
an .apk like the z4root did. But I think nobody noticed
or cared that a different setuid() bug was actually exploited.
Thats at least what my short analysis showed. If I am wrong
I will remove this paragraph. So, only use the original
old but gold code on the commandline as proposed
to get the real deal! :)

Cloud Clock trickery

I spent some time fumbling with HTTP again but not related
to Web 2.O. Rather I was interested in how HTTP could
replace NTP since web servers reply with a Date: string
upon each request. The result can be found here.
It is basically a daemon that fetches Date: of
pre-configured servers and tries to minimize RTT and
local I/O impact when setting the time. It also runs as
a user chrooted, keeping CAP_SYS_TIME.
It should also work with IPv6 nodes. If you want to use
my lophttpd web server along with httpdated, you need
to update it to the latest version.


Feel free to comment if you have ideas or see problems
but do not bother me with "NTP is much more better and
more correct". I know that :-)

ELF process dumping trickery

I made a small tool available here which allows to
dump ELF binaries from memory to disk in cases
where the original image has been altered/deleted/crypted
etc.
There is no way to make it 100% reliable as the state
of the program might not be the same as when just loaded
and therefore you can have dangling pointers etc.
in .data. However it works surprisingly well for a lot
of programs.
Some info is lost during loading anyway and has to be
restored heuristically. We rely on linear ascending
PLT jump-slots for example.


I only tested it on x86-64 but it has basic support
for x86 as well. The de-relocation of the image has
to be checked though. All other architectures like
PPC64 etc. can easily be added by adding appropriate
R_ types to the switch() clause.

Happy birthday to a good friend. You are not 25, you are almost 31 :-)

According to some news site its the 25th birthday of
the computer virus. Or not.


While most of the scientists and malware analysts know
that Fred Cohen did one of the first virus research in 1984,
it is a little known fact that in February 1980 a Diploma Thesis
at the University of Dortmund already discussed self replicating programs (in german). The 80's must have been such a great time. :-)
If you are interested, I also discussed some virus related issues
for UNIX in 2009 here.

adb trickery #2

Apparently some vendors have reviewed android and also fixed
the ashmem issue in 2.2.1 (along with adb and zygote).


However, I got the first reports for KillingInTheNameOf
working on 2.1 devices. So I made it available
here.


It was really my favorite and I hoped it would become
the Gingerbreak, but 2.3 is not using
ashmem for system properties. Thats life :)




[Update:] it seems like the property space has become
the new playground for breaking froyo devices since this post,
as the ashmem implementation has some shortcomings if
it comes to properly protecting the property space :-)
The security of the whole system relies on the property
space due to ro.secure and other properties.
However for Gingerbread, the property implementation has been
redesigned AFAIK.


Also check out this link for another method of exploiting
ashmem which apparently also works on 2.2.1 devices.


My Gingerbreak works, but I wont release it before a couple
of devices are in the wild so the issue is not fixed before
it can become useful.

Zygote trickery -- 743C 27C3 release

The Gingerbread source has recently been released and
a root vulnerability has been fixed inside the
zygote/dalvik framework (if you dont know what it is,
call it a framework). I hoped that this exploit would
still work on Gingerbread, but since the bug is too
similar to the adb issue it has been fixed as well.
Thus, this only affects android phones < 2.3 but
it also works without debugging being enabled e.g.
from inside an evil app.


As always: the code is AS IS.
If you use it, it may crash your
device and makes it totally useless, SO YOU USE IT AT YOUR OWN RISK! THERE IS NO GUARANTEE
THAT IT WILL WORK AT ALL.


If you dont know what jailbreaking is about, dont do it anyways.
Once executed it should create a /system/bin/rootshell or
+s /system/bin/sh.


The apk can be found here. Nevermind the simple GUI,
it was pasted together from various sample/demo programs
just to make it easier to have an activity to start
for zygote.


And fear my publishing skillz! :D