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.