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.