4 ms·

> WebKit Bugzilla: 243557 https://bugs.webkit.org/show_bug.cgi?id=243557 https://bugs.webkit.org/show_bug.cgi?id=243557 (leading to https://github.com/WebKit/W

> WebKit Bugzilla: 243557 https://bugs.webkit.org/show_bug.cgi?id=243557 https://bugs.webkit.org/show_bug.cgi?id=243557 (leading to https://github.com/WebKit/WebKit/commit/1ed1e4a336e15a59b94a21b0300658e2f7dc9fef https://github.com/WebKit/WebKit/commit/1ed1e4a336e15a59b94a...) Shouldn’t this issue have been made inaccessible in order to mitigate exploitation?

cjbprime 4y ago
The bug doesn't seem to describe the vulnerability at all, though?
- sammoody 4y ago
  When making security patches it’s often best to leave those details out, as otherwise it’s used as a guide for bad actors
  - hulitu 4y ago
    The bad actors already exploit them.
    - dotty- 4y ago
      The really good bad actors already exploit them. The eager bad actors with less skills look for guides.
    - dymk 4y ago
      How do you know every bad actor already knows how to exploit it?
dandongus 4y ago
Not sure why people flagged you for this. It's very common for open source projects to make the details of security-related bugs private. One example is Firefox, nearly every security update references one or more bug tickets that the public doesn't have permission to view. I wonder if Apple listed the wrong webkit bug number, it almost looks like it.
- tposx 4y ago
  Looks like the vulnerability was something to do with incorrect JIT optimisations on Maps and Sets, if the included tests are any indication.
sneak 4y ago
The issue is made public when the OS patch is released. Binary diffs are a thing.