It’s vulnerability research, but not in its calm and undramatic “here’s a list of the many bugs we fixed this month” form.
Usually, finding a potentially-exploitable security hole gets your name listed against one of dozens of CVEs patched in the latest release of ${insert_browser_name} or ${choose_OS_type}.
If you’re not already employed by the relevant vendor, you might also get a quiet bug bounty payout.
Just finding a crash-causing bug such as a buffer overflow or a use-after-free bug is often enough on its own.
→ A buffer overflow is where you trick a program into accepting more data than will fit into the memory allocated for it. A use-after-free is when you trick a program into writing into a block of memory that was already handed back to the operating system. This typically overwrites chunks of memory that control other parts of the program. So, with a mixture of analysis and experimentation, you may be able to leverage this sort of bug from “just cause a crash” to “sneakily take over control.”
If you can envisage how determined attackers might wrangle the bug into tricking your software into doing something of their own choosing, you might as well assume it’s a bug worth patching promptly.
The bug part is called a vulnerability, because it represents a weak spot in security.
The part where a crook purposefully abuses the vulnerability for his ends is called an exploit, for obvious reasons.
The process of working out how to exploit a vulnerability is known as weaponising it. (For better or worse, war plays a significant metaphorical role in the computer security industry.)
One you’ve found a vulnerability, you can take two paths:
- Spend time to produce a proof-of-concept (Poc) exploit. The PoC helps vendors prioritise the danger, and may suggest additional mitigations for other related, but so-far unknown, vulnerabilties.
- Assume the worst, patch the vulnerability and move on. If you know your car’s brakes are spongy and badly-adjusted, you don’t need to do a few laps of the a test track before you decide to get them fixed.
The Pwn2Own path
Pwn2Own unashamedly takes the first approach above, and turns the process into a spectator spectacle.
The competition is a sort of Software Security Superbowl, where touchdowns are scored by sitting down behind a laptop screen and publicly pwning the computer, armed only with a browser.
You win a prize if your attack would have allowed a crook to infect the computer with malware without any of the standard system defences, such as ASLR, DEP, sandboxing and so on, throwing up any sort of warning.
To add a bit more spectator excitement into what really ought to be straight science and engineering, if there is more than one entrant in any category, they go into bat in a randomly-chosen order.
If the first guy succeeds (each attacker gets a maximum of 30 minutes), he wins the grand prize for that category and the prize money is halved for the next entrant, no matter that his exploit might be quicker and slicker.
But if the first batter strikes out, the full prize money goes forward.
There are bonuses for taking your exploit further, notably if you can promote your attack code from a user-level login to SYSTEM.
On Windows, SYSTEM privilege is a special sort of administrator or root level access that as good as gives you full control over the computer.
As a regular user, you can install software for your own use, access files that you already own, and much more, but you can’t install kernel drivers, read other people’s files, or change the low-level system configuration.
With SYSTEM, you can do all of those things, and you can do them quietly and unobtrusively in the background.
In this year’s Pwn2Own, promoting a remote code execution exploit to SYSTEM level was worth a $25,000 bonus, whether you were the first competitor into bat or not.
The Pwn2Own results
Here’s how the Pwn2Own “live attacks” paid out:
According to HP, the 11 attacks shown above, of which 10 were successful and four ended up with full SYSTEM-level access, resulted in the following count of vulnerabilities to be fixed:
Windows itself: 5 bugs Microsoft IE 11: 4 bugs Mozilla Firefox: 3 bugs Adobe Reader: 3 bugs Adobe Flash: 3 bugs Apple Safari: 2 bugs Google Chrome: 1 bug
A good result all round, especially for JungHoon Lee, who took home $225,000.
As HP joked in its own summary of the event, JungHoon was only out at bat for two minutes for his Chrome attack, giving him a rate of pay of “roughly $916 per second.”
By that metric, Mariusz Mlynski did way better, as his $55,000 payout for pwning Firefox took just 0.542 seconds, according to HP, so he earned at over $100k per second.
But those are silly numbers – if you converted Mlynski’s rate of pay to a 40-hour week, he’d be on close to three-quarters of a trillion dollars a year.
Even JungHoon’s $916/second comes out at about $7B when you annualise it.
Of course, that 0.542 second time to pwn Firefox was the result of an unstated amount of work and preparation done before the event.
In short, Pwn2Own is a bit of a mixture of drama and research.
Proponents will argue that it helps to keep bugs and vulnerabilities in the fronts of our minds; but critics might say that it makes security molehills into theatrical mountains.
Where do you stand on having a Software Security Superbowl of this sort?