Sometimes measuring time using the trusty System.currentTimeMillis() static call isn’t of high enough resolution to measure the execution time of methods with any meaning. Fortunately for those facing this problem, Java 5 introduced a method of accessing the system’s most precise clock through the System.nanoTime() static call. This returns a long that represents the current clock time in nanoseconds, easily solving the problem of measuring time more precisely than milliseconds can provide.
Thus ends another quick post, get back to work :)
A quick search on google for “Reading environment variables in java” yielded a lot of (older) documentation stating that System.getEnv(”varname”) has been deprecated. This is no longer accurate, as System.getEnv(”varname”) and System.getEnv() have been reinstated as of Java 1.5. Quick post, I just wanted others to know that the API again exposes those useful method calls.
Yesterday I gave the second lecture in my “hacking” series. We’ve progressed beyond general descriptions and terminology and moved into the technical aspects of the stack, vulnerable code, and crafting exploits. The lecture ran about 45 minutes, and was accompanied by a live demonstration of exploiting vulnerable code.
For those that came late or missed it, the slides are available here (pdf format), although once again the real content was in the accompanying talk.
The demonstration used three source files. The shellcode was written by BreeZe of binbash.org, while the other two are my own. They are:
Running the Exploit
First, I only tested the exploit running on Debian Linux, running a 2.6.23 kernel on a 32bit x86 machine. It probably won’t work on Windows or a Mac, and it definitely won’t run on your SPARC.
Second, I used version 3.3 of gcc’s compiler. Newer versions contain checks to make stack smashing harder, but 3.3 is free of any of these security features. You’ll have to use it when compiling these, which can be done by issuing gcc-3.3 -o <name> <name.c>, like:
gcc-3.3 -o exploit exploit.c
Third, Linux kernels after 2.6.12 do virtual address space randomization, which will prevent the exploit from running successfully after being compiled. To disable this, issue (as root):
sysctl -w kernel.randomize_va_space = 0
Fourth and finally, if you want to trigger a core dump in the vuln program, you have to lift any restrictions on dumping core files. Something like the following should work:
ulimit -c 100000
Note that the shellcode file is superfluous, I only included it as an example and guide.
Next Time
At this point, I’m not sure what I’ll be covering next week. There is a lot I could do – writing shellcode, showcase more advanced shellcode, demonstrate gaining a remote shell (remote exploitation is a whole other beast), secure coding, polymorphic and self-modifying shellcode… there are a lot of topics, and only one lecture left before the end of the series.
Regardless, it will be fun, and we’ll all learn a hell of a lot.
I’ll be at Barcamp Rochester 3 this Saturday in GCCIS, and more likely than not I’ll be talking about anything and everything computer security. If you have any questions anything or find something I’ve said interesting, hit me up! I’m friendly, and always up for talking about computer security :)
After solving one of those “cascading problems,” the ones that seem to spawn three bugs for every one you squash, I can finally say my latest feature has been integrated in our project at work. Tag it, deploy it to the customer, *feel good.*
Some days it just feels good to get a win.
