Twitter | Search | |
Ben Hawkes
Project Zero team lead
565
Tweets
280
Following
27,329
Followers
Tweets
Ben Hawkes Jan 30
Replying to @basalberts @taviso
Cool, hadn't seen laf-intel before. I suspect was the first to implement something like this. Sub-instruction profiling from "Making Fuzzing Dumber" in 2009.
Reply Retweet Like
Ben Hawkes retweeted
j00ru//vx Jan 30
Just published a follow-up to my Adobe Reader symbols story on the Project Zero blog. Turns out there's even more debug metadata to be found in some old (and new) builds, including private CoolType symbols. Enjoy!
Reply Retweet Like
Ben Hawkes Jan 9
Replying to @mdowd
Reply Retweet Like
Ben Hawkes Jan 9
Replying to @mdowd
Rare praise! The Pwnies are the Oscars of infosec, but the Mark Dowd "pretty good at computers" award is clearly the Nobel Prize.
Reply Retweet Like
Ben Hawkes Jan 9
Quick reminder that we're still updating the "0day detected in-the-wild" spreadsheet here: . The first entry for 2020 is now in the books -- CVE-2019-17026 is a type confusion issue in the JIT engine for Firefox, detected in active attacks by Qihoo 360 ATA.
Reply Retweet Like
Ben Hawkes Jan 9
Project Zero blog: "Remote iPhone Exploitation Part 3: From Memory Corruption to JavaScript and Back -- Gaining Code Execution" by Samuel Groß () --
Reply Retweet Like
Ben Hawkes Jan 9
Project Zero blog: "Remote iPhone Exploitation Part 2: Bringing Light into the Darkness -- a Remote ASLR Bypass" by Samuel Groß () --
Reply Retweet Like
Ben Hawkes retweeted
Samuel Groß Jan 9
I'm very excited to share my blogpost series (including PoC code) about a remote, interactionless iPhone exploit over iMessage:
Reply Retweet Like
Ben Hawkes Jan 9
Project Zero blog: "Remote‌ ‌iPhone‌ ‌Exploitation‌ ‌Part‌ ‌1:‌ ‌Poking‌ ‌Memory‌ ‌via‌ ‌iMessage‌ ‌and‌ ‌CVE-2019-8641‌" by Samuel Groß () --
Reply Retweet Like
Ben Hawkes Jan 7
Replying to @i0n1c
Also I suspect quite a few vendors will still want to align disclosure around security bulletins, and that's still an option.
Reply Retweet Like
Ben Hawkes Jan 7
Replying to @i0n1c
Related to this, note that we're going to be paying much more attention to variants: "Details of incomplete fixes will be reported to the vendor and added to the existing report (which may already be public)"
Reply Retweet Like
Ben Hawkes Jan 7
Replying to @i0n1c
Yeah, in the short term that's possibly true. The long-term goal though is to reduce the total time for users to receive a high quality patch on their device, which should ultimately reduce the viability of patch diffing for 1-day. If it doesn't work, we'll rebalance the policy.
Reply Retweet Like
Ben Hawkes Jan 7
Replying to @ejcx_ @taviso
Since affected users might have needed to rotate secrets, timely notification was considered to be very important (and still would be under our new policy!). Some more details are here:
Reply Retweet Like
Ben Hawkes Jan 7
Replying to @ejcx_ @taviso
For those following along, note that Tavis disclosed the details several days after the initial fix in practice. The main discussion (and disagreement) was around how much time to allow for cleanup (removing the user data that was cached by search engines) vs user notification.
Reply Retweet Like
Ben Hawkes retweeted
Matt Miller Jan 7
Kudos to the GPZ team for their willingness to explore new vulnerability disclosure policies in addition to doing great research :) At the risk of wading into a disclosure debate (plz no), I think these policy changes will help improve customer safety
Reply Retweet Like
Ben Hawkes Jan 7
Replying to @Junior_Baines
I think you're right that attacker's are incentivized to study patches in more detail than defenders though, so we'll be looking very closely at the gap between patch and disclosure to make sure the policy is well balanced.
Reply Retweet Like
Ben Hawkes Jan 7
Replying to @Junior_Baines
For the vendors that want to disclose information closer to the patch date, we still have that option though. I suspect quite a few will still want to align disclosure around security bulletins.
Reply Retweet Like
Ben Hawkes Jan 7
Replying to @Junior_Baines
Great question, I'm definitely concerned about it and it was a big part of our discussions. Talking to a lot of vendors, they're generally aware of this type of analysis, but it wasn't always the biggest factor in terms of motivating them to improve patch speed/quality/adoption.
Reply Retweet Like
Ben Hawkes retweeted
Tim Willis Jan 7
At Google Project Zero, the team spends a *lot* of time discussing and evaluating vulnerability disclosure policies and their consequences. It's a complex and controversial topic! Here's P0's policy changes for 2020 (with our rationale for the changes):
Reply Retweet Like
Ben Hawkes Jan 7
Project Zero Policy and Disclosure: 2020 Edition --
Reply Retweet Like