How to defend from a Chrome 0day exploit?
-> Use Firefox ASan build.
Linux: firefox-ci-tc.services.mozilla.com/api/index/v1/t
Windows: firefox-ci-tc.services.mozilla.com/api/index/v1/t
Conversation
Replying to
ASan detects memory accesses outside of valid allocations rather than preventing exploitation which involves overwriting data within memory allocations. It adds substantial attack surface too. It's not an exploit mitigation and doesn't provide any kind of actual memory safety.
1
Replying to
You should read newer information including on the value that ASan provides for an attacker, including from people who work on it. There are substantial drawbacks to using it. It's not simply a way of getting some weak memory protections. It causes substantial harm too.
1
2
Replying to
could you please share us further details to support your claims? you mentioned about those 'values' and 'substantial harm'? would that affect the FF ASan build?
2
Replying to
You're proposing doing something that was temporarily adopted by the Tor Project for a variant of the Tor Browser and then later determined to be a mistake. It has been consistently recommended against by researchers and the developers of ASan. You can do what you want though.
1
1
I vaguely remember reading that AS AN introduces a predictable allocation address (used for allocation quarantine?) that can be used to bypass ASLR. Anyway there's value in being different so if you're the only one using ASAN build, you're probably safer
1
1
I thought the exploit's reliability is much lower because FF updates on a daily basis with ASan shipped on it. I thought that the exploit might be harder when you use something that is more uncommon and requires a bit different exploit
2
The issue with using a nightly build of a development branch will often have very blatant security vulnerabilities that are easy to exploit. A lot of stuff gets fixed before ever making it to a normal user.
Security fixes also tend to be shipped to the stable releases first.
They try to disclose and fix vulnerabilities with stable releases rather than leaking them early. It then has to be applied to the development branch. ESR on the other hand is probably a worse choice than the stable release: not all fixes are identified as security + backported.
1
2
As the release goes through the release channels, a lot of newly introduced bugs get caught and fixed. Ideally, when it gets to stable, there are security improvements outweighing the added attack surface and bugs from code churn. So, ideally, things get better over time.
1
1
Show replies