0
submitted 1 year ago by KoolKai@fedia.io to c/firefox@fedia.io

On Monday morning we (Mozilla) detected a very large crash spike affecting #Firefox users on Linux, specifically on an older version of a Debian-based distribution. It turned out to be an interesting bug involving the #Linux kernel and #Google JavaScript code so let me tell you about it. A thread 🧵

you are viewing a single comment's thread
view the rest of the comments
[-] gorogorochan@lemmy.world 0 points 1 year ago

Not sure what you mean by OS-level. It crashed a browser which is really easy to do, especially with:

This is where things got weird, Google's code was allocating 20000 variables in a single frame.

It’s pretty much a DoS at this point.

[-] njaard@lemmy.world 0 points 1 year ago

Not sure what you mean by OS-level

By OS-level, I mean Linux terminated the process because the process tried to do an instruction it wasn't allowed to do, specifically, trying to access a memory location it wasn't allowed to. That leads to a segmentation fault, on Linux.

It’s pretty much a DoS at this point.

Calling it a DoS is missing a lot of nuance because you're blaming Google's script, not Firefox. Having 20000 variables in a single frame is something a javascript program is allowed to do; it's a well-formed program that doesn't violate any rules of Javascript, so the fault is not in google's script, but in Firefox's JS interpreter. That doesn't mean that Google's script is good quality, but it's still valid.

Finally, what makes this particularly bad? Any "undefined behavior" can be exploited as security holes [ § "Undefined Behavior and Security Don't Mix Well"].

Now, it is possible to get a segmentation fault without having gone through a undefined behavior: by allocating memory, and then asking linux to make that memory inaccessible.

It's also possible to have undefined behavior and not get a segmentation fault: by chance you go past the end of a memory allocation into another valid allocation. This would be very bad because then your program definitely has a security hole.

So, if we decide that "google's JS is so bad that we shouldn't run it", the script should stop running because Firefox's JS interpreter stops running it. Firefox should pop up a window saying "the Javascript on this page was cancelled because Google sucks". I think this is incorrect, because the script is valid, but it's not bad because at least there's no exploitable security hole.

Or, you could have Firefox force itself to exit without triggered undefined behavior. That would actually would be a DoS, but at least you can't steal encryption keys or whatever off the system.

[-] gorogorochan@lemmy.world 0 points 1 year ago

Thank you. I can see your point and I agree. I only disagree with the argument that it isn’t a (sort of) DoS because JS is allowed to do it. I mean most actual DoS attacks are utilizing perfectly normal behaviors, but simply in abnormal volumes - which seems to be a point here.

this post was submitted on 24 Jun 2023
0 points (NaN% liked)

Firefox

4 readers
24 users here now

The latest news and developments on Firefox and Mozilla, a global non-profit that strives to promote openness, innovation and opportunity on the web.

You can subscribe to this community from any Kbin or Lemmy instance:

Related

Rules

While we are not an official Mozilla community, we have adopted the Mozilla Community Participation Guidelines as far as it can be applied to a bin.

Rules

  1. Always be civil and respectful
    Don't be toxic, hostile, or a troll, especially towards Mozilla employees. This includes gratuitous use of profanity.

  2. Don't be a bigot
    No form of bigotry will be tolerated.

  3. Don't post security compromising suggestions
    If you do, include an obvious and clear warning.

  4. Don't post conspiracy theories
    Especially ones about nefarious intentions or funding. If you're concerned: Ask. Please don’t fuel conspiracy thinking here. Don’t try to spread FUD, especially against reliable privacy-enhancing software. Extraordinary claims require extraordinary evidence. Show credible sources.

  5. Don't accuse others of shilling
    Send honest concerns to the moderators and/or admins, and we will investigate.

  6. Do not remove your help posts after they receive replies
    Half the point of asking questions in a public sub is so that everyone can benefit from the answers—which is impossible if you go deleting everything behind yourself once you've gotten yours.

founded 1 year ago
MODERATORS