6 ms·

Analysis of Chromium issue 1196683, 1195777 (2021)

74 points by luu 4y ago

achr2 4y ago
Looks well written/researched, but this page has broken scrolling that makes it very frustrating to read.
- kalupa 4y ago
  I noticed the same thing, though then I realized that I have to have my cursor over the main content area. Not a great thing, still.
- nayuki 4y ago
  I noticed the wonky scroll behavior, but it's debatable to call it broken. On most web pages, you can scroll the entire document by putting the cursor anywhere on the page. On this web site, you can only scroll if your cursor is within the <main> element, which has a rather narrow width. So most of the page area is not scrollable. Also, the CSS hides the scrollbar so that no affordances are given.
  - cyral 4y ago
    The author was probably trying to make the header and sidebar sticky by doing that, there are better ways though (such as literally the position: sticky CSS property)
- deleted 4y ago
  [deleted]
- tptacek 4y ago
  Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- loxias 4y ago
  It frustrates me too! No scrollbar either. I noticed once I clicked on the main content area it scrolled normally (by which I mean with the keyboard), but still... unnecessary frustration. Is there some reason this sort of user-hostile design is becoming more and more common? Is there something that I can do, client side perhaps, to fix it? I don't know anything about how modern web works, but perhaps there's an element I can remove with ublock origin to restore sane behavior? I'm aware of the HN guidelines re: complaining about tangential annoyances, so apologies in advance if this (my) comment is "part of the problem", but I suspect the readership here would be the sort of people who might have an answer. Edit: Making matters even worse, I can't even save the page as a PDF for reading later! It only captures what's visible at the time. :( Somebody outta do something about this...
- loxias 4y ago
  I found a fix! https://github.com/t-mart/kill-sticky https://github.com/t-mart/kill-sticky Just add a little bit of code to a bookmark button, it works wonderfully. Click the button and your scrollbar returns, the keyboard works again, _AND_ the page renders to a PDF beautifully. You're welcome. :)
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.
djcannabiz 4y ago
the amount of effort put into optimizing javascript engines blows my friggin mind every time i see something like this.
- titzer 4y ago
  The principal sin, IMHO, is that JavaScript technically has only one number type, double. But doubles are pretty slow, particularly if they are used as array indexes, so JS engines do a ton of numerical analysis (range analysis) to determine when it is safe to do integer math. That reasoning is extremely tricky and I've made gazongas amounts of bugs myself. (I'm the original author of the SimplifiedLoweringPass, which has evolved significantly since I last worked on that part of the code--circa 2015). Unfortunately static analysis of any kind really doesn't help...the implementation language (C++) isn't really at fault...because the bugs are manifesting at the compiler IR level, i.e. how it reasons about JS values in the representation of JS code.
  - kitten_mittens_ 4y ago
    Javascript has two number types. `number` and `bigint`. https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-bigint-objects https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec...
    - zarzavat 4y ago
      Technically it’s number. But bigint can be much larger than a 64-bit integer, so from the CPU’s perspective it’s an array rather than a single integer.
    - kevingadd 4y ago
      BigInt isn't super relevant here though, it's new and a distinct type so it doesn't come into play for any typical computations. You can't use it as the size of an array, etc.
tester756 4y ago
yet another JIT related vuln? c'mon, will we ever stop using JIT in browsers? Just take a look at this article from Microsoft Browser Vulnerability Research where they do challenge this and perform benchmarks without JIT >https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... >Looking at CVE (Common Vulnerabilities and Exposures) data after 2019 shows that roughly 45% of CVEs issued for V8 were related to the JIT engine.
- saagarjha 4y ago
  We’ll stop using JITs when it becomes acceptable to make computers 2x slower, or more.
  - Arnavion 4y ago
    Or when it becomes acceptable to make them 100x faster by not using JS, but that's even less likely to happen :)
    - kevingadd 4y ago
      No JIT also rules out most modern uses of Java and C#, along with things like LuaJIT.
      - Arnavion 4y ago
        >>>c'mon, will we ever stop using JIT in browsers?
        xboxnolifes 4y ago
        Not using JS means you need to replace it with something, which means you gotta put it into the browser.
        netr0ute 4y ago
devwastaken 4y ago
This is also why wasm in the browser is not specially "safe". It's the same jit optimization and execution as the JavaScript pipeline. Therefore vulns in that are sometimes useable in wasm. Speed is a tradeoff. And is why if you have a system that uses v8's or others wasm runtimes, it must be able to update.

74 points by luu 4y ago

achr2 4y ago

Looks well written/researched, but this page has broken scrolling that makes it very frustrating to read.

kalupa 4y ago
I noticed the same thing, though then I realized that I have to have my cursor over the main content area. Not a great thing, still.
nayuki 4y ago
I noticed the wonky scroll behavior, but it's debatable to call it broken. On most web pages, you can scroll the entire document by putting the cursor anywhere on the page. On this web site, you can only scroll if your cursor is within the <main> element, which has a rather narrow width. So most of the page area is not scrollable. Also, the CSS hides the scrollbar so that no affordances are given.
- cyral 4y ago
  The author was probably trying to make the header and sidebar sticky by doing that, there are better ways though (such as literally the position: sticky CSS property)
deleted 4y ago
[deleted]
tptacek 4y ago
Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
loxias 4y ago
It frustrates me too! No scrollbar either. I noticed once I clicked on the main content area it scrolled normally (by which I mean with the keyboard), but still... unnecessary frustration. Is there some reason this sort of user-hostile design is becoming more and more common? Is there something that I can do, client side perhaps, to fix it? I don't know anything about how modern web works, but perhaps there's an element I can remove with ublock origin to restore sane behavior? I'm aware of the HN guidelines re: complaining about tangential annoyances, so apologies in advance if this (my) comment is "part of the problem", but I suspect the readership here would be the sort of people who might have an answer. Edit: Making matters even worse, I can't even save the page as a PDF for reading later! It only captures what's visible at the time. :( Somebody outta do something about this...
loxias 4y ago
I found a fix! https://github.com/t-mart/kill-sticky https://github.com/t-mart/kill-sticky Just add a little bit of code to a bookmark button, it works wonderfully. Click the button and your scrollbar returns, the keyboard works again, _AND_ the page renders to a PDF beautifully. You're welcome. :)

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.

djcannabiz 4y ago

the amount of effort put into optimizing javascript engines blows my friggin mind every time i see something like this.

titzer 4y ago
The principal sin, IMHO, is that JavaScript technically has only one number type, double. But doubles are pretty slow, particularly if they are used as array indexes, so JS engines do a ton of numerical analysis (range analysis) to determine when it is safe to do integer math. That reasoning is extremely tricky and I've made gazongas amounts of bugs myself. (I'm the original author of the SimplifiedLoweringPass, which has evolved significantly since I last worked on that part of the code--circa 2015). Unfortunately static analysis of any kind really doesn't help...the implementation language (C++) isn't really at fault...because the bugs are manifesting at the compiler IR level, i.e. how it reasons about JS values in the representation of JS code.
- kitten_mittens_ 4y ago
  Javascript has two number types. `number` and `bigint`. https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-bigint-objects https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec...
  - zarzavat 4y ago
    Technically it’s number. But bigint can be much larger than a 64-bit integer, so from the CPU’s perspective it’s an array rather than a single integer.
  - kevingadd 4y ago
    BigInt isn't super relevant here though, it's new and a distinct type so it doesn't come into play for any typical computations. You can't use it as the size of an array, etc.

tester756 4y ago

yet another JIT related vuln? c'mon, will we ever stop using JIT in browsers? Just take a look at this article from Microsoft Browser Vulnerability Research where they do challenge this and perform benchmarks without JIT >https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... >Looking at CVE (Common Vulnerabilities and Exposures) data after 2019 shows that roughly 45% of CVEs issued for V8 were related to the JIT engine.

saagarjha 4y ago
We’ll stop using JITs when it becomes acceptable to make computers 2x slower, or more.
- Arnavion 4y ago
  Or when it becomes acceptable to make them 100x faster by not using JS, but that's even less likely to happen :)
  - kevingadd 4y ago
    No JIT also rules out most modern uses of Java and C#, along with things like LuaJIT.
    - Arnavion 4y ago
      >>>c'mon, will we ever stop using JIT in browsers?
      - xboxnolifes 4y ago
        Not using JS means you need to replace it with something, which means you gotta put it into the browser.
        netr0ute 4y ago

devwastaken 4y ago

This is also why wasm in the browser is not specially "safe". It's the same jit optimization and execution as the JavaScript pipeline. Therefore vulns in that are sometimes useable in wasm. Speed is a tradeoff. And is why if you have a system that uses v8's or others wasm runtimes, it must be able to update.