I was doing some testing on a server to see if it was vulnerable to a 0-day local exploit (the exploit was for gaining root privileges using a bug in the Linux kernel). There was no real information yet on how to know if your vulnerable or not except by running the exploit. Which I did and ended up getting a heap of trouble from the data center for doing so. With this being the case, what is the best way to check to see if your vulnerable? Can one assume that there will be a fix released for the vulnerability before they get hacked using the exploit (even with a hardened server)?

  • To know if the server is vulnerable to a certain exploit without testing it is almost impossible. I mean you need to know the internals of the target and how this exploit works, and this without even running it. Even the "creator" of the exploit had to test/debug it several times, then how would you expect to do it ? I think you can't. You had 2 options: 1- Ask the developer of the exploit about the version(s) that were vulnerable, at least what he has tested so far 2- Make a copy of the server and run it on a VM and test the exploit on it. Hope you weren't sued for this :)
    – HamZa
    Commented May 16, 2013 at 18:44
  • @HamZaDzCyberDeV Just about. They quickly suspended me (without even a warning) but luckily after reviewing my case, they unsuspended me. Commented May 16, 2013 at 23:18
  • @ub3rst4r I would assume if you have downloaded it from the Internet and someone is claiming it to be an 0-day, chances are it is some kind of a backdoor. A linux kernel 0-day is like a gem because of the wide spread deployment of Linux, from super computers to smart phones. Such exploits no longer exist free of cost. Therefore, make sure your system hasn't been infected.
    – void_in
    Commented May 17, 2013 at 8:15
  • It may be worth setting up a VM and running some File Integrity Monitoring software before trying out the exploit. You could then run the exploit and identify what files it has changed. Once you know what's changed, you know what the exploit does and can potentially take steps to protect yourself through reconfiguration of your production system so it's no longer vulnerable. If you can do this, you should share your patch process!
    – AndyMac
    Commented May 17, 2013 at 8:29
  • @ub3rst4r - This is what a virtual machine is used for. If its your server what does your host care?
    – Ramhound
    Commented May 17, 2013 at 14:17

2 Answers 2


I would consider 2 possible approaches - I note that you are trying to verify an exploit for escalation of privilege exploiting a bug in the kernel. For the sake of the experiment, I would ignore user space software even though this is probably a bad idea.

Approach #1 assuming that you may need access to data on the server in question, I would install a VM with the exact version of the Linux distro and kernel in question and try out your exploit. The VM will effectively sandbox the server from the real host and if you do succeed in crashing the VM - no harm done.

Approach #2 assuming that there are no data dependencies - I would install a VM with the same distro and kernel on any other Linux box you might have in the shop and try out your exploit.

If this is an important machine and your organization has assets worth attacking I would not make any assumptions regarding patches becoming available and being applied before you were attacked.

OTOH - if the machine is not mission critical and the general state of the server farm security countermeasures is good (machines patched regularly, firewalls maintained properly) - I would reduce your level of concern and take the time in the lab

  • If you can only determine your vulnerability by testing, then this is the way to go. Otherwise, check version numbers, etc. instead.
    – schroeder
    Commented May 16, 2013 at 18:16
  • What about when dealing with a VPS running on OpenVZ? Commented May 16, 2013 at 23:19

Find what the exploit takes advantage of. Is it your Linux kernel (version)? Then all systems with that version number may be effected.

Assuming you have a vulnerability, you should know what it attacks. If for some reason you don't know what the exploit does don't test it on production servers. If the exploit is a script, then you can just peak and see what it does. If the exploit is compiled into machine code, you will have to try and reverse engineer it to understand what it does or hire someone who can.

You can't assume there will be a fix before someone gets ahold of the exploit, unless the only person that has it is the developer. Developers will only be able to fix them if they know about it. They can learn about new exploits in their software if it is released to the public, sold to them, or found by them.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .