3 ms·

As a casual observer of Firefox development (well, maybe not casual, I skim through the pushlogs occasionally), I find it interesting to compare this to some Fi

by Jap2-0 4y ago

As a casual observer of Firefox development (well, maybe not casual, I skim through the pushlogs occasionally), I find it interesting to compare this to some Firefox security bug guidelines.[0][1] Although it looks like in these cases the issues were reverse-engineered in <1 day (making release timing less of a solution), two items in those that stand out to me as potentially helpful are "land tests in-tree later" and "bundle with other changes in the same area." [0] https://firefox-source-docs.mozilla.org/bug-mgmt/processes/security-approval.html https://firefox-source-docs.mozilla.org/bug-mgmt/processes/s... [1] https://firefox-source-docs.mozilla.org/bug-mgmt/processes/fixing-security-bugs.html#fixing-security-bugs https://firefox-source-docs.mozilla.org/bug-mgmt/processes/f...

nightpool 4y ago
These kinds of security-by-obscurity guidelines are well-known and oft-touted, but only debatably useful when dealing with a codebase as closely monitored and security-sensitive as V8. Many professionals instead recommend full disclosure as early and as immediately as possible, including publishing CVEs and vulnerability warnings so that affected users can take appropriate steps as soon as a patch is available or deploy mitigations (for example, in very severe cases, disabling the V8 JIT, which is a well-known RCE mitigation). Also, in this case, both bugs would need to be combined with a zero-day Chrome sandbox escape vulnerability to achieve exploitability. If anything, I'm more worried that the fixes weren't backported more urgently and that CVEs do not seem to have been assigned. But this seems to have been a success for defense in depth, at least.
- titzer 4y ago
  Generally, security fixes like this are back-merged to the stable branch almost immediately, i.e. within hours. The issue is that the stable branch isn't integrated into Chromium, built, and released into stable until the next spin, which could be a couple days or even weeks.
- dblohm7 4y ago
  Former Firefox developer here. The reason for omitting tests is because they are essentially the exploits themselves; omission raises the barrier to entry, as somebody has to be skilled enough to craft an exploit based on the source code change. While security fixes are typically pushed out on all supported branches within a very short window of time, anything that buys time is useful imho.
- Jap2-0 4y ago
  Sibling comments address this pretty well, but the ideas I mentioned still seem like good ideas for a few reasons: - The article mentions the sample exploit is based on the test case - The point of obfuscation isn't to prevent exploitation, it's to delay it - A sibling mentions the delay between patch and release as an issue; because of the only ~1 day delay here it seems like this was intentionally merged right before release, so buying even a day (or two or three, to account for time to update) would be enough to mitigate most of the impact There's a big difference between reading a snippet of JS and understanding the inner workings of a JIT, especially under time pressure.

by Jap2-0 4y ago

nightpool 4y ago

These kinds of security-by-obscurity guidelines are well-known and oft-touted, but only debatably useful when dealing with a codebase as closely monitored and security-sensitive as V8. Many professionals instead recommend full disclosure as early and as immediately as possible, including publishing CVEs and vulnerability warnings so that affected users can take appropriate steps as soon as a patch is available or deploy mitigations (for example, in very severe cases, disabling the V8 JIT, which is a well-known RCE mitigation). Also, in this case, both bugs would need to be combined with a zero-day Chrome sandbox escape vulnerability to achieve exploitability. If anything, I'm more worried that the fixes weren't backported more urgently and that CVEs do not seem to have been assigned. But this seems to have been a success for defense in depth, at least.

titzer 4y ago
Generally, security fixes like this are back-merged to the stable branch almost immediately, i.e. within hours. The issue is that the stable branch isn't integrated into Chromium, built, and released into stable until the next spin, which could be a couple days or even weeks.
dblohm7 4y ago
Former Firefox developer here. The reason for omitting tests is because they are essentially the exploits themselves; omission raises the barrier to entry, as somebody has to be skilled enough to craft an exploit based on the source code change. While security fixes are typically pushed out on all supported branches within a very short window of time, anything that buys time is useful imho.
Jap2-0 4y ago
Sibling comments address this pretty well, but the ideas I mentioned still seem like good ideas for a few reasons: - The article mentions the sample exploit is based on the test case - The point of obfuscation isn't to prevent exploitation, it's to delay it - A sibling mentions the delay between patch and release as an issue; because of the only ~1 day delay here it seems like this was intentionally merged right before release, so buying even a day (or two or three, to account for time to update) would be enough to mitigate most of the impact There's a big difference between reading a snippet of JS and understanding the inner workings of a JIT, especially under time pressure.