The Register has a pretty good article on an exploit using the NULL pointer. They were even nice enough to include the code. Here is a pretty good summary:

The vulnerability is located in several parts of Linux, including one that implements functions known as net/tun. Although the code correctly checks to make sure the tun variable doesn’t point to NULL, the compiler removes the lines responsible for that inspection during optimization routines. The result: When the variable points to zero, the kernel tries to access forbidden pieces of memory, leading to a compromise of the box running the OS.

The “NULL pointer dereference” bug has been confirmed in versions 2.6.30 and 2.6.30.1 of the Linux kernel, which Spengler said has been incorporated into only one vendor build: version 5 of Red Hat Enterprise Linux that’s used in test environments. The exploit works only when a security extension knows as SELinux, or Security-Enhanced Linux, is enabled. Conversely, it also works when audio software known as PulseAudio is installed.

An exploitation scenario would most likely involve the attack being used to escalate user privileges, when combined with the exploitation of another component – say, a PHP application. By itself, Spengler’s exploit does not work remotely.

With all the hoops to jump through, the exploit requires a fair amount of effort to be successful. Still, Spengler said it took him less than four hours to write a fully weaponized exploit that works on 32- and 64-bit versions of Linux, including the build offered by Red Hat. He told The Register he published the exploit after it became clear Linus Torvalds and other developers responsible for the Linux kernel didn’t regard the bug as a security risk.

While it does take some effort, it will surely be added into a script run on metasploit before too much longer, making it twice as dangerous.

(Via The Register)

Java has always been the problem child in the family of web browsing. Tons of exploits, and lets not even get into performance issues. Java continues its nuisance in FireFox. Mozillanow has some egg on their face as their two week old Firefox 3.5 has been identified with a remote execute exploit.

Mozilla is warning users and administrators of a critical JavaScript flaw in its Firefox 3.5 browser.

The company said that the problem exists in the browser’s JavaScript tool within a component called ‘just in time’ (JIT). If exploited, the vulnerability could allow an attacker to remotely execute code on a targeted system.

Mozilla further warned that a working exploit has been publically released, increasing the risk of attacks occurring in the wild.

A Firefox security alert offers instructions on how to temporarily disable the JIT component through the browser’s about:config menu. Doing so will slow JavaScript performance, however.

(Via V3)

The ability to track your power usage via Google, is a perk I am looking forward to. Sure I could write down my meter reading everyday, but lets be honest. Unfortunately rushing into the smart meter era has some very negative side affects.

There’s just one problem: The newfangled meters needed to make the smart grid work are built on buggy software that’s easily hacked, said Mike Davis, a senior security consultant for IOActive. The vast majority of them use no encryption and ask for no authentication before carrying out sensitive functions such as running software updates and severing customers from the power grid. The vulnerabilities, he said, are ripe for abuse.

“We can switch off hundreds of thousands of homes potentially at the same time,” Davis, who has spent the past few months analyzing a half-dozen smart meters, told The Reg. “That starts providing problems that the power company may not be able to gracefully deal with.”

While having the ability to flick the power on and off would be entertaining, I want the hack to come out that we all really want. How can I make it so it only registers 1/4 of my actual power usage?

(Via The Register)

Here is a great write up by the guys over at Offensive Security. They managed to work the iTunes OS X exploit around and got it to work in Windows too. And for all of those wanting to use it, they did post the exploit at the bottom. Here is a little about how they got there.

Our new AWE course is about to go live for the first time, in BlackHat Vegas. We chose the most interesting exploitation cases we’ve encountered, and dove really deep into them. We had many exploits to choose from, some were too easy, and believe it or not, some were just too hard. This blog post is going to be a multipart post, describing our exploitation process of the recent iTunes overflow described here. This is possibly one of our most involved and interesting exploits to date.

An exploit for OSX was released and discussed here. Being naturally inquisitive, we checked to see if this exception would occur in Windows too, and indeed it was!

After attaching a debugger to the iTunes process, we noticed it was getting terminated after around 30 seconds. It looked like iTunes had anti-debugging features implemented. Fortunately, Immunity Debugger offers anti-debugging scripts which are useful for situations just like this. Invoking the !hidedebug command within ID allowed the debugger to continue running in hidden mode, bypassing our first hurdle.

Using the OSX exploit as a template, we attempted to crash iTunes several times, however the process would keep terminating with no opportunity for code redirection. After inspecting the call stack in one of the crash cases, we saw that one function was calling ZwTerminateProcess.

We assumed this was a stack protection mechanism. We placed a breakpoint there. This would halt ID just before the stack cookie check, allowing us to examine the vulnerable function in greater depth, and also to confirm our “stack protection” theory.

We soon realised that trying to approach the stack canary head on would be difficult. We attempted to increase the buffer length we were sending in order to get a SEH overflow, which would effectively bypass the canary protection. The Gods of buffer overflows were in our favour – and an SEH overwrite was achieved!

From here on, we expected things to get easier. Little did we know….

(Via Offensive Security)