Just a quick note to let you know that we got Firefox and Pwn2Own wrong in our last podcast…
…but we were right about Mozilla’s reaction in our last podcast promotional video:
Latest podcast 🎧 Listen now! Firefox & Pwn2Own, Apple and a 0-day… and the math that beat Pythagoras.https://t.co/HDrZPQzlAQ pic.twitter.com/DxgdC8VM1j
— Naked Security (@NakedSecurity) May 20, 2022
In the video we said (emphasis below):
In the podcast, we speculated, “Was it [recent Firefox fix] pushed just in time for Pwn2Own, hoping that would stop the attack from working? If that was the reason, it didn’t work. […] But we know Mozilla will be rushing to fix this one as soon as they get the Pwn2Own contest details.
To explain.
In a post from last weekend, after our Linux distribution received an out-of-band Firefox patch seemingly in a hurry, but the update still hadn’t posted to the Firefox website, we wondered: “Is there some sort of cybersecurity rush here? »
This update added a sandbox security feature called Win32k lock it had taken months, if not years, to prepare, but had just missed the planned 100.0 release.
As a result, we speculated that Firefox 100.0.1, a simple point release in which a whole new Windows security feature was suddenly enabled, was purpose-built, just in time for this year’s Pwn2Own hack contest. in Vancouver, Canada.
Why not wait?
We were surprised that Mozilla didn’t just wait for the next planned release, 101.0, to enable the new feature and announce it as a feature, rather than a “security patch”, given that it wasn’t not there to stop a clear and precise attack that was already known.
Usually, point releases come out to address pressing issues that really can’t wait, like new features that fail or zero-day bugs that suddenly appear in the wild and need to be addressed before the next major update deadline. four weeks. Turn around.
But with Pwn2Own happening this very week, and with Firefox in the crosshairs of experienced and successful bug hunter Manfred Paul, maybe Mozilla thought it was worth releasing 100.0.1 in time. for the contest?
Just in case the new sandbox feature might throw an unexpected wrench into Paul’s otherwise certain hacking session, and save the day?
On Wednesday, Paul’s session started with 30’00” on the clock counting down (an upper limit of 30 minutes is imposed on each competitor).
After a brief pause, the arbiter reached out and clicked a button to initiate the hack attempt by visiting a URL that was ready to trigger Paul’s double feat remotely. (The server was remote in terms of the network; physically it was on the same table as the attacked client.)
Basically, Paul was planning to break into Firefox, earning $50,000 in bug bounty for remote code executionthen get away with it, earning another $50,000 for a complete sandbox escape.
About seven seconds passed later, with a first pump of acknowledgment from the referee (Pwn2Own is exciting for everyone, not just hackers), and with an unsurprisingly happy smile from Manfred Paul, now better off by $100,000, the clock stopped, having just tipped over to show 29’52”.
Yes Win32k lock was supposed to stop the Pwn2Own attack, it didn’t, although we have no doubt that the new sandbox protection will make many future exploits harder to find and less reliable to use.
To claim a Pwn2Own prize, the deal is that you must “show your work”, in full explanatory detail, to the maker of the system you’ve just cracked, and give them initial advice on how to fix it.
All proper bug bounties work this way, of course, but Pwn2Own isn’t just about spotting possible bugs and calling them with a crash log, it’s about finding and writing about the bug and its dangers with careful and repeatable detail, up to and including a working feat.
Kudos to everyone involved
Well, this spectacular seven-second pwnage happened on Wednesday 2022-05-18.
And on Friday 2022-05-20, about an hour before midnight UK time, Firefox popped up to tell us, “An update is available for 100.0.2”.
Here are the associated security notes, from Mozilla Security Advisory 2022-19:
* CVE-2022-1802: Prototype pollution in Top-Level Await implementation.
Reporter: Manfred Paul via Trend Micro's Zero Day Initiative
Impact: Critical
Description: If an attacker was able to corrupt the methods
of an Array object in JavaScript via prototype pollution,
they could have achieved execution of attacker-controlled
JavaScript code in a privileged context.
* CVE-2022-1529: Untrusted input used in JavaScript object
indexing, leading to prototype pollution.
Reporter: Manfred Paul via Trend Micro's Zero Day Initiative
Impact: Critical
Description: An attacker could have sent a message to the
parent process where the contents were used to double-index
into a JavaScript object, leading to prototype pollution and
ultimately attacker-controlled JavaScript executing in the
privileged parent process.
What to do?
We’ve already patched – and you?
For the fourth time last week, we will say: Patch early, patch often.
With a response time like this, it would be rude not to!
Oh, and a very big one “Bravo and thank you” to everyone at every step of this bug finding and fixing process.
#Mozilla #fixes #Wednesdays #Pwn2Own #double #exploitFriday