xorl %eax, %eax

Archive for the ‘fun’ Category

GoboLinux lulz

with 5 comments

I just read this page of a distribution named GoboLinux. This is the first GNU/Linux distribution I am aware of with built-in rootkit!!! GoboHide FTW!!! :P

Written by xorl

July 21, 2009 at 23:11

Posted in fun

HAR2009 Program!!!

leave a comment »

Hello everyone and sorry for not posting anything recently despite that some really cool vulnerabilities have been disclosed.

The program for har2009 is released! There are some really awesome talks but as it happens in such gatherings the best part meeting new people that you respect or have met online someday. Anyhow, I’ll be staying there with ithilgore, sin and adis. I hope to see some of you there and drink some beers together!!! :D

Written by xorl

July 3, 2009 at 11:20

Posted in fun

Phrack #66

with 9 comments

Phrack is out.
UPDATE:

Introduction
It was kind of sad regarding the underground quotes.
Personally, I like mayhem’s comment for the French contributors. heh
Phrack Prophile on The PaX Team
Jesus! Pipacs on Phrack! I bet spender will be soooo sooo happy with this :P Admit it. the_uT’s one was more interesting.
The Objective-C Runtime: Understanding and Abusing
Once again nemo did it. He explores and exploits Objective C in Mac OS X. Also, his asl_* abuse was pretty neat :)
Developing a Trojaned Firmware for Juniper ScreenOS Platforms
This article by Graeme was great! It’s one of the very few articles dealing with backdoored image files in network devices. I really liked that!
Yet another free() exploitation technique
Man… I am flattered! A brilliant Greek from GRHack wrote one of the
best articles of this issue. Thank you hk!
Persistent BIOS Infection
Core Security shows us the way to BIOS infection. Even though this is not a new concept, they made some remarkable research in this article and it definitely deserves your time.
Exploiting UMA : FreeBSD kernel heap exploits
Hehe! The popular Greek coder argp and the well known researcher Karl Janmar from signedness wrote an innovative paper about FreeBSD kernel heap exploitation. This is not anything new but they did excellent work in documenting it in great detail. This is clearly the ultimate FreeBSD kernel heap exploitation article I am aware of.
Exploiting TCP and the Persist Timer Infiniteness
ithilgore and his crazy network stuff… I have to admit that when he told me about that design flaw I was unable to follow. This is an amazing article since it is theoretical, practical and innovative all in one :P Well done ithilgore! :)
MALLOC DES-MALEFICARUM
The third article in this issue about heap exploitation was written by blackngel. This is another excellent work on heap exploitation which as the author states, its aim is to make practical examples of the classic Malloc Maleficarum. Something like what K-sPecial did this in .aware alpha release. They went far beyond this with this paper!
A Real SMM Rootkit
This is written by Filip Wecherowski who makes at last, a real SMM rootkit. There has been a lot of hype about SMM rootkits since Phrack #65 article and Blackhat 2008 presentation. This article goes extensively through the details of such rootkits.
Alphanumeric ARM shellcode
This is written by Yves Younan and Pieter Philippaerts. Forgive me for that but I don’t think this is compared to the rest of the articles of #66. It is still great resource for ARM internals and the undocumented alphanumeric shellcoding in RISC ARM processors. Nevertheless, shellcoding for exotic CPUs is not something really innovative. It is still an amazing article, this is just my opinion in comparison to the rest of the papers.
Power cell buffer overflow
This article written by BSDaemon talks about CELL exploitation. As I said earlier, even though I love reading/studying such subjects from my geeky side, I found them impractical from my security side. Unless you’re planning to have some PS3 botnet…Anyhow, excellent analysis and great enhancement of the already known exploitation techniques for CELL.
manual binary mangling with radare
A great new framework for reverse engineering written by pancake. I haven’t studied radare in detail yet but from this article, it seems beautiful.
Linux Kernel Heap Tampering Detection
If you’re interested in Linux kernel heap exploitation or detection of tampering, this is just a great resource. It is written by Larry H. and explains all of the memory allocators used in Linux kernel in detail. Then it compares their limitations to OpenBSD and NetBSD implementations as well as the recent safe unlinking of Windows. Really cool article. It even deals with subverting SELinux and AppArmor.
Developing Mac OSX kernel rootkits
Two Swedish guys, ghalen and wowie wrote about OS X rootkits. I don’t know much about OS X and I was surprised to see how easy it really is to code rootkits (in comparison to Linux). Thank you guys for this article :)
How close are they of hacking your brain?
This is a completely different article written by dahut. It deals with concepts such as injecting content in our brains and similar subjects which I’m not really keen with. Still a really interesting article.

To conclude, in my opinion Phrack #66 is excellent even though it has some sort of “heap exploitation mania” :P Every single article is great. Congratulations to everyone involved to achieve this. On its downside, it didn’t include any “art of exploitation” article which I really liked and there was no “international scenes” article but I am aware of the problems you had to find one. Thank you all for this release :)

P.S.: Semi-irrelevant reply:

<@nemo> ah come on
<@nemo> who is xorl
<@nemo> i know you’re here :(
<@nemo> haha
<@nemo> :P

Indeed… I was there :P

Written by xorl

June 11, 2009 at 10:59

Posted in fun, phrack

Linux kernel airo_get_encode() Buffer Overflow

with 5 comments

This issue affects Linux kernel 2.6.30 prior to 2.6.30-rc6 (just kidding, it affects that one as well) where this was patched (or at least attempted). Credits go to John Linville and Eugene Teo. The bug can be found at drivers/net/wireless/airo.c where the Aironet driver for 4500 and 4800 series cards is located. Here is the vulnerable code from 2.6.30-rc5 release of the Linux kernel:

6460 /*
6461  * Wireless Handler : get Encryption Key
6462  */
6463 static int airo_get_encode(struct net_device *dev,
6464                            struct iw_request_info *info,
6465                            struct iw_point *dwrq,
6466                            char *extra)
6467 {
6468         struct airo_info *local = dev->ml_priv;
6469         int index = (dwrq->flags & IW_ENCODE_INDEX) - 1;
6470         u8 buf[16];
        ...
6477         /* Check encryption mode */
6478         switch(local->config.authType)  {
        ...
6502         /* Copy the key to the user buffer */
6503         dwrq->length = get_wep_key(local, index, &buf[0], sizeof(buf));
6504         memcpy(extra, buf, dwrq->length);
6505
6506         return 0;
6507 }

This function is used to obtain the encryption key (if there is any). At line 6503 it invokes get_wep_key() to retrieve the WEP key and store its retrurn value in dwrq->length. dwrq is a iw_point pointer to structure which is defined in include/linux/wireless.h like this:

679 /*
680  *      For all data larger than 16 octets, we need to use a
681  *      pointer to memory allocated in user space.
682  */
683 struct  iw_point
684 {
685   void __user   *pointer;       /* Pointer to the data  (in user space) */
686   __u16         length;         /* number of fields or size in bytes */
687   __u16         flags;          /* Optional params */
688 };

And get_wep_key() is a utility function located at drivers/net/wireless/airo.c and used to retrieve the WEP key. Here is a snippet:

5198 /* Returns the WEP key at the specified index, or -1 if that key does
5199  * not exist.  The buffer is assumed to be at least 16 bytes in length.
5200  */
5201 static int get_wep_key(struct airo_info *ai, u16 index, char *buf, u16 buflen)
5202 {
       ...
5207         rc = readWepKeyRid(ai, &wkr, 1, 1);
5208         if (rc != SUCCESS)
5209                 return -1;
       ...
5217                 rc = readWepKeyRid(ai, &wkr, 0, 1);
5218                 if (rc != SUCCESS)
5219                         return -1;
       ...
5221         return -1;
5222 }

As you can see, there are at least three cases in which this function will return -1 and all of them are not that hard to trigger. If this function returns -1 for any of the above reasons, airo_get_encode() will attempt to copy 0xffff bytes to buffer extra since length is of type __u16. However, buf is only 16 bytes long (check out line 6470). To fix this buffer overflow, the following patch was applied:

     dwrq->length = get_wep_key(local, index, &buf[0], sizeof(buf));
-    memcpy(extra, buf, dwrq->length);
+    if (dwrq->length != -1)
+        memcpy(extra, buf, dwrq->length);
+    else
+        dwrq->length = 0;

This performs an additional check for -1 in the length parameter… Well, I was just laughing when I saw this. First of all, dwrq->length is an unsigned value, thus it could never contain a negative number, secondly, dwrq->length is just 16 bits long, meaning that even if we assign -1 to it, it will truncate it to 0xffff which is 65535. I believe that this is not an important bug that’s why I’m leaking this information. It was hilarious! Even GCC says it:

sh-3.1$ cat -n malakies_tou_linux.c
     1  #include <stdio.h>
     2  typedef unsigned short __u16;
     3
     4  int
     5  main(void)
     6  {
     7     __u16 length = -1;
     8     if (length != -1)
     9       printf("length (%u) != -1\n", length);
    10     else
    11       printf("length (%u) == -1\n", length);
    12
    13     return 0;
    14  }
    15
sh-3.1$ gcc malakies_tou_linux.c -o malakies_tou_linux
malakies_tou_linux.c: In function ‘main’:
malakies_tou_linux.c:8: warning: comparison is always true due to limited range of data type
sh-3.1$ ./malakies_tou_linux
length (65535) != -1
sh-3.1$

They did the same thing to airo_get_encodeext() as well, it was:

6606 /*
6607  * Wireless Handler : get extended Encryption parameters
6608  */
6609 static int airo_get_encodeext(struct net_device *dev,
6610                             struct iw_request_info *info,
6611                             union iwreq_data *wrqu,
6612                             char *extra)
6613 {
6614         struct airo_info *local = dev->ml_priv;
6615         struct iw_point *encoding = &wrqu->encoding;
6616         struct iw_encode_ext *ext = (struct iw_encode_ext *)extra;
6617         int idx, max_key_len;
6618         u8 buf[16];
         ...
6660         /* Copy the key to the user buffer */
6661         ext->key_len = get_wep_key(local, idx, &buf[0], sizeof(buf));
6662         memcpy(extra, buf, ext->key_len);
6663
6664         return 0;
6665 }

And they patched it to this:

     ext->key_len = get_wep_key(local, idx, &buf[0], sizeof(buf));
-    memcpy(extra, buf, ext->key_len);
+    if (ext->key_len != -1)
+        memcpy(extra, buf, ext->key_len);
+    else
+        ext->key_len = 0;

     return 0;


Again, I’m still a supporter of non-disclosure but this was so funny that it was deserving a post. Many bugs don’t get patched properly and since this was an unimportant one (at least for me), I made this post.

Clarification, this is lul disclosure :P

Written by xorl

May 19, 2009 at 15:55

Posted in bugs, fun, linux

Douglas Mezzer’s ISP story

leave a comment »

One of the funniest links I read today. You can read it here.

Written by xorl

May 11, 2009 at 16:24

Posted in fun

rm -rf / sucks

with 3 comments

Well, I spend the weekend with some friends and during our lulz times we decided to rm a box. I don’t usually rm boxes or participating in such acts, but we knew the admin and it would be definitely fun, so… I haven’t rm’d any box for quite some time and after getting local root using one common exploit I typed:

rm -rf /

I was kind of surprised when I realized that it didn’t work. Of course, we could do something more fun like:

cat /dev/urandom > /dev/hda

Anyway, we did this:

cd / && rm -rf *

It worked, but I was curious who was the gay developer that did this to rm :(

Here is some code found at rm.c from the latest release of GNU core-utils:

227 int
228 main (int argc, char **argv)
229 {
230   bool preserve_root = true;
231   struct rm_options x;
     ...
351   if (x.recursive & preserve_root)
352     {
353       static struct dev_ino dev_ino_buf;
354       x.root_dev_ino = get_root_dev_ino (&dev_ino_buf);
355       if (x.root_dev_ino == NULL)
356         error (EXIT_FAILURE, errno, _("failed to get attributes of %s"),
357                quote ("/"));
358     }

So… from now on, we should rename rm -rf to:

rm -rf --no-preserve-root /

Which is way more gay and ugly and it seems they no longer have “preserve-root” disabled by default. There are even more retarded users that report this feature as a bug. I hate you. You take all the fun out of it and you’re making things worst since from now on I’ll be issuing something like this (you know… or dd(1), shred(1) etc.):

cat /dev/urandom > /dev/your_hard_disk

P.S.: To the guy that made this behavior default: Shame on you.

Written by xorl

May 11, 2009 at 15:23

Posted in fun

Matasano uudecode old Sendmail trick

leave a comment »

I just read a nice post written by Mike Tracy of matasano security. It’s just a nice little story! :-)

Written by xorl

May 6, 2009 at 21:45

Posted in fun