sshttp is in the git

A few days ago, I put the sshttp project to the github.

It allows to run SSH and HTTP(S) on the same port

without changing them.

I also checked in new code for lophttpd, to support

IPv6 and bind's to specific addresses other than

INADDR_ANY.

The benchmarks I did were really satisfying, it outperforms

default apache2 installs (surprise, surprise) and also

ngnix. Hope to get some time to plot some statistics

about that.

All your servers are belong to us

We deliver. Worldwide. Up to 0x743c times. And if you
are still not there, we return to libc.


You just noticed it, there is a new front pic online. I'll rotate
this within the next months to show cool and the gang
in different positions inside the cloud. The experienced
reader also noticed that the shirts are all made of valid
RPM switches and indeed the most important ones.


While I myself will definitely keep up with mobile stuff, our
origin are servers and the code running there. We deliver
stable, fast and secure services. If you have any problems
with your server or code, just call us.

me hubbing and gitting on github

As of today you can also find me on github.
I am testing how good or bad it performs for my own projects.
For now, I made lophttpd a public repo where you can
watch the development process.
My openwall site and other places where I used to put code
stay the same and I will continue to upload .tgz files.

Censorship

In this' blog survey "Do you like surveys?", too many people voted that I am an idiot, rather than they dislike surveys (less amount 
than people who like surveys though) so I do it like middle east
dictatorship: I just cancel it :P

openpam trickery

While reviewing an entirely different server side component
of some code, I came across a funny vulnerability inside
OpenPAM (note that this is different from Linux-PAM)
as used in FreeBSD or Solaris. Yet, I only tested it on
a FreeBSD 8.1 machine. The bug is that a program,
namely kcheckpass, which is suid to root, is calling
pam_start() with a user provided argument which makes
the PAM stack parse user owned
config files which ends in loading of user
provided DSO's. WTF?!


Interestingly, OpenPAM recently introduced a filter for
the service name via


http://trac.des.no/openpam/changeset/478/trunk/lib/openpam_configure.c

commit but I dont think that any BSD or so vendor is
aware of it.


A really trivial PoC exploit can be found here.


[Update:] Solaris is not using OpenPAM (at least the OpenSolaris
version I checked), but I could not find code that strips
off certain character sequences. As the PAM setup is different
from the /etc/pam.d we know it is possible that there are no
consequences if the service argument is not filtered.
However a lot of BSD derivates
use OpenPAM and OSX as well. The question is whether one can
find a vector different than the kcheckpass which is usually
found with all KDE3 and KDE4 installs.
If you can confirm vulnerability on any Solaris or non-FreeBSD
machine, please let me know. Also if you found out how OSX
can be exploited this way.

Fun with git-upload-pack

The android git was recently moved so I was eager to check
out the new sources. But I always got a 403! What was wrong?
Looking into some forums showed that lots of folks seems to
have the same problems so I post this in the hope that it
saves other developers some hours of debugging. At the end it seems
just to be an issue about the git version or git setup.
I cloned a repo with a clean, new machine and compared the
HTTP stream with what I got from a working box to find
out why some checkouts worked and some dont. Heres is the
old git pull:

and here is the new one with the diff marked green:

Somewhat surprising since according to the download page
git 1.6.4 should just be fine.
Now everything works smoothly. Not a very technical issue indeed,
but tracking down strange issues helps to stay keen. More than
just searching the web for a solution.

AIO

I just uploaded my version of the AIO functions for Linux 2.6.
They use kernels io_ syscalls rather than doing everything with pthreads (like last time I checked with glibc).
It is available here.

New sshttp available

I uploaded a new sshttp tarball to fix potential slowdown
for a special usage pattern where thousands of clients
without sending data upon connect would slow down
other users connections.

refactored IPv6 load balancing software

In 2003 I attended a class at University about IPv6.
Students have had to choose a topic to work about and I
chose to write a load balancing software for IPv6
utilizing the netfilter QUEUE target. It was one of the first
available load balancers for IPv6 ever, long before the
LVS project implemented IPv6.

It has since then been shown on a lot of conferences and follow-up

classes.


Since the old code was not the most performing one (even though
bandwidth and latency tests showed acceptable results) and
the underlying netfilter changes made it useless on new
Linux systems, I re-wrote it. It is now better performing,
is able to use multiple cores/SMP and runs as user.
Additionally the failover code for IPv4 has been improved
(it is able to balance IPv4 traffic too).


You can argue that, since it runs in userspace, it will
always perform badly. However if you have a site for testing
with enough traffic, I'd like to see results.


If I'd be a professor at University, I would just let one
of my students write a thesis about its performance and let
him do some measuring, but I am not. :)
My performance test on a 100MBit link showed no real impact
on either throughput or latency. GBit performance measuring
has to be done. Anyone?


The code with a guiding README can be found here.


In any case it sharpened my skills about IPv6 and its sisters
and that alone was really worth re-mangling the code.
Great tools are about to be born (Hi Marc:)

pwnies 2011

As you might know or not, me and Marius have been nominated for the pwnie awards 2011 in the category best server side bug.
The CVE-2011-0997 DHCP bug was really funny and easy to exploit and often found in enterprise and campus network setups.
Unfortunally we didnt win, and to my surprise even taviso didnt win this time.
So I am likely the only one who has just one pwnie while all
the real good guys have at least two!


Nevertheless, congrats to the winners. In particular I like
pipacs' Lifetime Achievement award and $0ny's mastering in failure.
They both really deserve it.

crash

I uploaded a new version of crash, fixing API issues
it had with newer OpenSSL versions which silently
changed some SSL_METHOD* returns to const. Huhhh!

The lock sock

While developing a piece of code which requires locking
across processes (not threads) and which runs as nobody
user inside a non-writable chroot I came across the idea
to use abstract UNIX sockets for locking.
The advantage is that it is very easy to implement and use
and you dont need to create a file as you would when using
file based locking. You also dont need to mess with the
SVR4 IPC mechanisms and its portable as well. The idea is as
easy as beautiful so I think I am probably not the first
one abusing UNIX sockets that way. The code is here:

Basically you delegate the atomic lock operation to the
kernel via the bind() syscall since no more than one
process can bind to a given path at the same time. Since
there is no unbind() operation you have to close() the
socket in order to free the lock.

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.