How Google set a trap for Pwn2Own exploit team

(The VUPEN exploit team with Nicolas Joly at far right)

VANCOUVER -- Last May, when security researchers from VUPEN posted this video to gloat about demo a code execution exploit -- and sandbox bypass -- against the Google Chrome browser, the security response folks at Google took a close look and found enough evidence that the exploit actually hit the Chrome Flash Player plugin.

At the time, the two companies publicly sparred over the origin of the vulnerability with Google intent on making the distinction that the faulty code was supplied by Adobe and VUPEN insisting that it didn't matter because the exploit worked against the browser's default installation.

Fast forward to CanSecWest and Pwn2Own 2012.   As you know, Google launched an alternative to Pwn2Own to ensure it got the full rights to any sandbox exploitation so when the VUPEN team announced it would arrive here with a Chrome zero-day, the Google Chrome security team decided to set a trap.

Google could figure out very easily if a certain exploit technique  was being used.  Even more, if an attack targeted third-party (er, Adobe Flash Player)  code, they could pinpoint the technique.

In this case, the Google Chrome security knew that the Flash Player plugin sandbox is significantly weaker and that an exploit against Chrome's Flash Player would have to go through a certain path.

Having figured out that Vupen used that technique (from the May video), Google decided to add a specific protection for Flash.

On March 5, the protection was added to Google Chrome 17.0.963.65.  When the protection triggers, it generates a very unique signature -- 0xABAD1DEA -- which is hexidecimal that spells out "a bad idea." The protection was meant to make the browser resilient to certain attacks but in a bit of cat-and-mouse, it was left in there to see if anyone would find it and make a public comment.

The VUPEN team arrived at CanSecWest and during testing of its exploits for Pwn2Own, they stumbled into the exception.  VUPEN exploit writer confirmed on Twitter:

Once that tweet went out, it was clear to Google that VUPEN was targeting Flash Player to attack Chrome. Although the Googlers can't confirm 100% that VUPEN's tweet wasn't part of a big ruse, they knew for sure they were were attempting an exploit that triggered that specific exception.

VUPEN co-founder Chaouki Bekrar, an outspoken exploit writer who insisted the team deliberately targeted Chrome to prove a point, was uncharacteristically coy when asked if the faulty Chrome code came from Adobe.

”It was a use-after-free vulnerability in the default installation of Chrome,” he said. “Our exploit worked against the default installation so it really doesn’t matter if it’s third-party code anyway.” Bekrar told me.

His careful wording was a sign that Flash Player was indeed the Chrome weak link.

Maybe Google already knew this.  Because of a well-placed cat-and-mouse trap.

ALSO SEE:

Pwn2Own 2012: Google Chrome browser sandbox first to fall

CanSecWest Pwnium: Google Chrome hacked with sandbox bypass

Charlie Miller skipping Pwn2Own as new rules change hacking game

CanSecWest Pwn2Own hacker challenge gets a $105,000 makeover