11 ms·

Out of bounds memory access in V8 in Google Chrome prior to 120.0.6099.224

138 points by keepamovin 3y ago

tester756 3y ago
Where git diff can be found?
- mccr8 3y ago
  Here's the diff: https://chromium.googlesource.com/v8/v8/+/389ea9be7d68bb189e16da79f6414edbd4f7594f%5E%21/#F0 https://chromium.googlesource.com/v8/v8/+/389ea9be7d68bb189e...
  - mike_hearn 3y ago
    Are you sure? That might be one of them, I think one of them is this one (see my other comment) https://chromium-review.googlesource.com/c/v8/v8/+/5173470 https://chromium-review.googlesource.com/c/v8/v8/+/5173470
    - mccr8 3y ago
      That commit says it is for 1515930. The Chrome releases page says that CVE-2024-0519 is associated with 1517354, which is what I linked to. There may be a connection between CVE-2024-0519 and CVE-2024-0517, but none is mentioned on the Chrome releases page which is what I'm going by.
eimrine 3y ago
Does it work with Chrome 60?
- 15457345234 3y ago
  "Showing 1000 of 9099 matching CPE(s) for the range" Yes it seems to go back to Chrome version 9 lol uhoh
  - Manouchehri 3y ago
    Impacted versions in CVE listings are normally not validated. For example, my CVE-2022-2007 in WebGPU also supposedly goes back to Chrome version 9. That's impossible, as WebGPU wasn't even a concept back then. https://nvd.nist.gov/vuln/detail/CVE-2022-2007 https://nvd.nist.gov/vuln/detail/CVE-2022-2007 It's relatively easy to find the offending commit by creating a unit test and using git bisect. I usually don't do it for public Chromium bug reports since it's extra work and $0 in extra rewards.
- themerone 3y ago
  Why are you concerned about a specific version released 7 years ago?
  - olliej 3y ago
    Yet another unuqdated Electron app?
    - timcobb 3y ago
      Or a joke on this subject
  - mschuster91 3y ago
    A lot of stuff embeds Chromium in one way or another.
- krackers 3y ago
  Given that this seems to be an issue with Maglev compiler which was introduced only M114 or so, I'd think that it would not be affected.
masklinn 3y ago
The Fedora mailing list message actually lists 3 different CVE: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IIUBRVICICWREJQUVT67RS7E4PVZQ5RS/ https://lists.fedoraproject.org/archives/list/package-announ... - a type confusion - an out of bounds read - an out of bounds write All three are in V8, so node might also be affected?
- mccr8 3y ago
  If you are running untrusted code in Node, subtle JIT bugs are probably the least of your problems.
  - christophilus 3y ago
    Everyone who runs Node runs untrusted code (depending on your definition of untrusted). No one I’ve ever worked with made an effort to review the source of the thousands of dependencies they were slinging around.
    - GabrielTFS 3y ago
      I would expect "untrusted code" to mean "code in a sandbox" or "code I'm not gonna run at all anytime soon", so running code from thousands of dependencies in node is effectively trusting all of that code, unless it is your direct expectation that it is malicious (and even then, aren't you trusting it to be malicious ?). The trust we give to random dependencies like that is quite arguably unwarranted to a large degree, but it doesn't mean the code isn't trusted.
    - bee_rider 3y ago
      I’m pretty sure untrusted code means code you can’t trust, which includes any code that you haven’t either analyzed yourself or put through some sort of institutional review with auditable sign-offs. It is how these conversations always go: There’s a hole in the sandbox. If you were trusting the sandbox, you were already doomed. Nobody validates their code well enough to trust it. (we are here) The ecosystem and industry is just irreparably damaged. What am I supposed to do about that? Non-solutions, because it is an impossible problem to actually fix
mccr8 3y ago
There's not a lot of context in this submission, but presumably it is being linked because the release notes for this CVE says "Google is aware of reports that an exploit for CVE-2024-0519 exists in the wild." https://chromereleases.googleblog.com/2024/01/stable-channel-update-for-desktop_16.html https://chromereleases.googleblog.com/2024/01/stable-channel...
- deleted 3y ago
  [deleted]
- bri3d 3y ago
  https://blog.exodusintel.com/2024/01/19/google-chrome-v8-cve-2024-0517-out-of-bounds-write-code-execution/ https://blog.exodusintel.com/2024/01/19/google-chrome-v8-cve... Here’s the exploit writeup.
  - qingcharles 3y ago
    I wonder if they got a bounty from it?
    - costco 3y ago
      Exodus sells vulnerabilities to the government.
      - mianos 3y ago
        To quote their "ethics" statement: "We pride ourselves in our skillsets to parallel those of nation state hacking groups, and we tout that our expertise is unrivaled in our ability to discover and exploit vulnerabilities in a variety of product. Our intention as a Company is to provide this intelligence to US and Allied countries for their enterprise and governments to have a leg up over the malicious actors from around the world." Ouch.
  - Leszek 3y ago
    That's a different bug (CVE-2024-0517 vs CVE-2024-0519)
olliej 3y ago
Oof, another reminder that it does not matter how aggressively you fuzz, it’s still fundamentally stochastic and you can miss things like this for years :-/
- pjmlp 3y ago
  Yeah, but apparently we keep getting the feedback that with good engineering practices and good strong developers, this never comes to be.
  - josephg 3y ago
    Most hackers aren’t finding their own 0days like this. If a motivated state level attacker targets you, you’re in trouble. But most companies that get hacked fail in much dumber ways - like failing to update chrome long after a bug like this has been fixed. Or using stupid, guessable passwords. Of course we should have sympathy for the 1% of companies who fall victim to 0days from state level attackers. But I have no sympathy for the other 99% of data leaks where the devs forgot to put a password on a public mongodb instance, or let their login cookies be enumerable or something equally ridiculous. Just because we can’t make security perfect doesn’t mean we shouldn’t make it good.
    - mandevil 3y ago
      James Mickens gave a lecture at a conference (I think it's this one: https://www.youtube.com/watch?v=tF24WHumvIc https://www.youtube.com/watch?v=tF24WHumvIc but I don't have time to actually listen through it) about how there are two different threat models for computer security: bored five year olds and the Mossad. And bored five year olds just try the same three things again and again, and as long as you take basic precautions you can protect yourself against them. You cannot protect yourself against the Mossad, don't even try. When I first started paying attention to computer security I was at a start-up and tasked to rewrite their PCI infrastructure for credit card processing, so I did some research into the state of the art. That week news of a casino hack came out. Billionaire casino/media magnate and conservative donor Sheldon Adelson gave a speech in October 2013 about how the US should threaten to use nuclear weapons to destroy Iran's nuclear program. In February 2014 a 150 line VB virus was installed on his casino's network which wiped all of the hard drives it could find, costing the Sands hundreds of millions of dollars. This was at a casino, some place which absolutely cares about their computer security and presumably spends a lot on that security, and they failed to successfully protect themselves against a nation-state level threat. So whatever the hell startup I was working at had no chance if someone at that level wanted it. We could stop the five year olds. Just not the nation-states.
ck2 3y ago
btw last version on Windows7 is 109 so maybe millions of vulnerable installs out there there are 3rd party patches to install 120 on w7 but who would trust them?
- bee_rider 3y ago
  Windows 7 is like 15 years old.
  - toast0 3y ago
    Age is irrelevant. Market share is. The first search result [1] places Windows 7 at 3.34% of Windows marketshare currently, which is significant, IMHO, but your market may vary from whatever this statistic tracks. 8.1 at 1.66% and XP at 0.64% could be significant, too, depending on your market. If you're going to support 7, you may as well support 8 and 8.1 too because it may not be any more work. [1] https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/ https://gs.statcounter.com/windows-version-market-share/desk...
    - Workaccount2 3y ago
      I have the great honor of not only commandeering a windows 7 laptop at work, but also a windows XP one.
      - thfuran 3y ago
        Can you yet get a laptop that fits XP all in cache? Edit: It looks like you could probably pull it off with some trimming and a sufficiently expensive Epyc, but I think you'll have to wait a few years for laptops to manage. Hopefully by then you can take XP out back and but it once and for all.
        Workaccount2 3y ago
        It's used in an offline testing setup using a long forgotten serial interface scripting language. It's one of those "it works and there is no need to change it so we just leave it"
frankjr 3y ago
> [$16000][1515930] High CVE-2024-0517: Out of bounds write in V8. Reported by Toan (suto) Pham of Qrious Secure on 2024-01-06 > [$1000][1507412] High CVE-2024-0518: Type Confusion in V8. Reported by Ganjiang Zhou(@refrain_areu) of ChaMd5-H1 team on 2023-12-03 > [$TBD][1517354] High CVE-2024-0519: Out of bounds memory access in V8. Reported by Anonymous on 2024-01-11 Damn. Google should really hire HN's C++ experts because they would never make errors like this.
- kramerger 3y ago
  [flagged]
  - ajross 3y ago
    To take the point more seriously than you intended it: this is (apparently) a bug in a code generator. The C++ itself wasn't unsafe and didn't crash, it emitted binary code that did. A Rust/Python/whatever JIT could trivially have the same bug. Commenters aren't suggesting Rust because it's not an area where implementation language is able to provide safety.
- deleted 3y ago
  [deleted]
- zeusk 3y ago
  Ironically they need all this complexity to make an interpreted script run faster.
  - deleted 3y ago
    [deleted]
- fwsgonzo 3y ago
  I wonder if any of these are avoided by disabling JIT, which I have done. And also, just how much of the codebase is JIT related? I also don't think C++ is always the problem. This is a complex language run-time, and there's all sorts of issues that can be language and language run-time related, regardless of it being written in Rust or C++, that manifest as out-of-bounds errors. I couldn't find any information about work-arounds.
nolist_policy 3y ago
It says severity high everywhere, but doesn't the attacker also need to break out of the sandbox to do actual damage? With this vulnerability alone you only gain remote code execution inside the sandbox.
- bri3d 3y ago
  There’s also a very interesting wasm based Ubercage (V8) sandbox escape in the chain: https://blog.exodusintel.com/2024/01/19/google-chrome-v8-cve-2024-0517-out-of-bounds-write-code-execution/ https://blog.exodusintel.com/2024/01/19/google-chrome-v8-cve... I don’t think the Chrome process isolation sandbox is escaped though.
  - throwitaway1123 3y ago
    In the demo video they're running Chrome using the --no-sandbox flag. Can this be exploited without that option? I can't actually test this myself at the moment, because the vulnerability only works on x86_64 machines.
    - bri3d 3y ago
      Yes, it can be exploited, just inside the sandbox. I'm pretty sure this is why the write-up is always so careful to say "read/write inside the Chrome sandbox." With the chain that's documented, you basically end up with full R/W/X control inside of the sandbox process, so what you can do is highly platform and version specific. For example, IIRC you used to be able to unmask Tor and many VPN and proxy users from inside of the sandbox using either JavaScript or native networking APIs. It's my recollection that this is less true on newer Windows versions, but I don't keep up with Chrome sandbox protection that well. Presumably Exodus also have a sandbox escape that didn't get burned so they didn't include it in the writeup.
      - throwitaway1123 3y ago
        > Presumably Exodus also have a sandbox escape that didn't get burned so they didn't include it in the writeup. I certainly hope not. I know these zero day exploits tend to be used almost exclusively against high profile politicians and journalists, but the threat still tempts me to just disable the JIT altogether (and maybe WASM too).
costco 3y ago
I wonder how many bugs like this are found with and without fuzzing. I don't really know very much about this area but the diffs to fix these bugs are always a couple of lines and it's always very subtle. You'd basically have to have written the code yourself to know there's something wrong. Here's another example of what I'm talking about: https://zerodayengineering.com/insights/chrome-webrtc-cve-2023-7024.html https://zerodayengineering.com/insights/chrome-webrtc-cve-20...

138 points by keepamovin 3y ago

tester756 3y ago

Where git diff can be found?

mccr8 3y ago
Here's the diff: https://chromium.googlesource.com/v8/v8/+/389ea9be7d68bb189e16da79f6414edbd4f7594f%5E%21/#F0 https://chromium.googlesource.com/v8/v8/+/389ea9be7d68bb189e...
- mike_hearn 3y ago
  Are you sure? That might be one of them, I think one of them is this one (see my other comment) https://chromium-review.googlesource.com/c/v8/v8/+/5173470 https://chromium-review.googlesource.com/c/v8/v8/+/5173470
  - mccr8 3y ago
    That commit says it is for 1515930. The Chrome releases page says that CVE-2024-0519 is associated with 1517354, which is what I linked to. There may be a connection between CVE-2024-0519 and CVE-2024-0517, but none is mentioned on the Chrome releases page which is what I'm going by.

eimrine 3y ago

Does it work with Chrome 60?

15457345234 3y ago
"Showing 1000 of 9099 matching CPE(s) for the range" Yes it seems to go back to Chrome version 9 lol uhoh
- Manouchehri 3y ago
  Impacted versions in CVE listings are normally not validated. For example, my CVE-2022-2007 in WebGPU also supposedly goes back to Chrome version 9. That's impossible, as WebGPU wasn't even a concept back then. https://nvd.nist.gov/vuln/detail/CVE-2022-2007 https://nvd.nist.gov/vuln/detail/CVE-2022-2007 It's relatively easy to find the offending commit by creating a unit test and using git bisect. I usually don't do it for public Chromium bug reports since it's extra work and $0 in extra rewards.
themerone 3y ago
Why are you concerned about a specific version released 7 years ago?
- olliej 3y ago
  Yet another unuqdated Electron app?
  - timcobb 3y ago
    Or a joke on this subject
- mschuster91 3y ago
  A lot of stuff embeds Chromium in one way or another.
krackers 3y ago
Given that this seems to be an issue with Maglev compiler which was introduced only M114 or so, I'd think that it would not be affected.

masklinn 3y ago

The Fedora mailing list message actually lists 3 different CVE: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IIUBRVICICWREJQUVT67RS7E4PVZQ5RS/ https://lists.fedoraproject.org/archives/list/package-announ... - a type confusion - an out of bounds read - an out of bounds write All three are in V8, so node might also be affected?

mccr8 3y ago
If you are running untrusted code in Node, subtle JIT bugs are probably the least of your problems.
- christophilus 3y ago
  Everyone who runs Node runs untrusted code (depending on your definition of untrusted). No one I’ve ever worked with made an effort to review the source of the thousands of dependencies they were slinging around.
  - GabrielTFS 3y ago
    I would expect "untrusted code" to mean "code in a sandbox" or "code I'm not gonna run at all anytime soon", so running code from thousands of dependencies in node is effectively trusting all of that code, unless it is your direct expectation that it is malicious (and even then, aren't you trusting it to be malicious ?). The trust we give to random dependencies like that is quite arguably unwarranted to a large degree, but it doesn't mean the code isn't trusted.
  - bee_rider 3y ago
    I’m pretty sure untrusted code means code you can’t trust, which includes any code that you haven’t either analyzed yourself or put through some sort of institutional review with auditable sign-offs. It is how these conversations always go: There’s a hole in the sandbox. If you were trusting the sandbox, you were already doomed. Nobody validates their code well enough to trust it. (we are here) The ecosystem and industry is just irreparably damaged. What am I supposed to do about that? Non-solutions, because it is an impossible problem to actually fix

mccr8 3y ago

There's not a lot of context in this submission, but presumably it is being linked because the release notes for this CVE says "Google is aware of reports that an exploit for CVE-2024-0519 exists in the wild." https://chromereleases.googleblog.com/2024/01/stable-channel-update-for-desktop_16.html https://chromereleases.googleblog.com/2024/01/stable-channel...

deleted 3y ago
[deleted]
bri3d 3y ago
https://blog.exodusintel.com/2024/01/19/google-chrome-v8-cve-2024-0517-out-of-bounds-write-code-execution/ https://blog.exodusintel.com/2024/01/19/google-chrome-v8-cve... Here’s the exploit writeup.
- qingcharles 3y ago
  I wonder if they got a bounty from it?
  - costco 3y ago
    Exodus sells vulnerabilities to the government.
    - mianos 3y ago
      To quote their "ethics" statement: "We pride ourselves in our skillsets to parallel those of nation state hacking groups, and we tout that our expertise is unrivaled in our ability to discover and exploit vulnerabilities in a variety of product. Our intention as a Company is to provide this intelligence to US and Allied countries for their enterprise and governments to have a leg up over the malicious actors from around the world." Ouch.
- Leszek 3y ago
  That's a different bug (CVE-2024-0517 vs CVE-2024-0519)

olliej 3y ago

Oof, another reminder that it does not matter how aggressively you fuzz, it’s still fundamentally stochastic and you can miss things like this for years :-/

pjmlp 3y ago
Yeah, but apparently we keep getting the feedback that with good engineering practices and good strong developers, this never comes to be.
- josephg 3y ago
  Most hackers aren’t finding their own 0days like this. If a motivated state level attacker targets you, you’re in trouble. But most companies that get hacked fail in much dumber ways - like failing to update chrome long after a bug like this has been fixed. Or using stupid, guessable passwords. Of course we should have sympathy for the 1% of companies who fall victim to 0days from state level attackers. But I have no sympathy for the other 99% of data leaks where the devs forgot to put a password on a public mongodb instance, or let their login cookies be enumerable or something equally ridiculous. Just because we can’t make security perfect doesn’t mean we shouldn’t make it good.
  - mandevil 3y ago
    James Mickens gave a lecture at a conference (I think it's this one: https://www.youtube.com/watch?v=tF24WHumvIc https://www.youtube.com/watch?v=tF24WHumvIc but I don't have time to actually listen through it) about how there are two different threat models for computer security: bored five year olds and the Mossad. And bored five year olds just try the same three things again and again, and as long as you take basic precautions you can protect yourself against them. You cannot protect yourself against the Mossad, don't even try. When I first started paying attention to computer security I was at a start-up and tasked to rewrite their PCI infrastructure for credit card processing, so I did some research into the state of the art. That week news of a casino hack came out. Billionaire casino/media magnate and conservative donor Sheldon Adelson gave a speech in October 2013 about how the US should threaten to use nuclear weapons to destroy Iran's nuclear program. In February 2014 a 150 line VB virus was installed on his casino's network which wiped all of the hard drives it could find, costing the Sands hundreds of millions of dollars. This was at a casino, some place which absolutely cares about their computer security and presumably spends a lot on that security, and they failed to successfully protect themselves against a nation-state level threat. So whatever the hell startup I was working at had no chance if someone at that level wanted it. We could stop the five year olds. Just not the nation-states.

ck2 3y ago

btw last version on Windows7 is 109 so maybe millions of vulnerable installs out there there are 3rd party patches to install 120 on w7 but who would trust them?

bee_rider 3y ago
Windows 7 is like 15 years old.
- toast0 3y ago
  Age is irrelevant. Market share is. The first search result [1] places Windows 7 at 3.34% of Windows marketshare currently, which is significant, IMHO, but your market may vary from whatever this statistic tracks. 8.1 at 1.66% and XP at 0.64% could be significant, too, depending on your market. If you're going to support 7, you may as well support 8 and 8.1 too because it may not be any more work. [1] https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/ https://gs.statcounter.com/windows-version-market-share/desk...
  - Workaccount2 3y ago
    I have the great honor of not only commandeering a windows 7 laptop at work, but also a windows XP one.
    - thfuran 3y ago
      Can you yet get a laptop that fits XP all in cache? Edit: It looks like you could probably pull it off with some trimming and a sufficiently expensive Epyc, but I think you'll have to wait a few years for laptops to manage. Hopefully by then you can take XP out back and but it once and for all.
      - Workaccount2 3y ago
        It's used in an offline testing setup using a long forgotten serial interface scripting language. It's one of those "it works and there is no need to change it so we just leave it"

frankjr 3y ago

> [$16000][1515930] High CVE-2024-0517: Out of bounds write in V8. Reported by Toan (suto) Pham of Qrious Secure on 2024-01-06 > [$1000][1507412] High CVE-2024-0518: Type Confusion in V8. Reported by Ganjiang Zhou(@refrain_areu) of ChaMd5-H1 team on 2023-12-03 > [$TBD][1517354] High CVE-2024-0519: Out of bounds memory access in V8. Reported by Anonymous on 2024-01-11 Damn. Google should really hire HN's C++ experts because they would never make errors like this.

kramerger 3y ago
[flagged]
- ajross 3y ago
  To take the point more seriously than you intended it: this is (apparently) a bug in a code generator. The C++ itself wasn't unsafe and didn't crash, it emitted binary code that did. A Rust/Python/whatever JIT could trivially have the same bug. Commenters aren't suggesting Rust because it's not an area where implementation language is able to provide safety.
deleted 3y ago
[deleted]
zeusk 3y ago
Ironically they need all this complexity to make an interpreted script run faster.
- deleted 3y ago
  [deleted]
fwsgonzo 3y ago
I wonder if any of these are avoided by disabling JIT, which I have done. And also, just how much of the codebase is JIT related? I also don't think C++ is always the problem. This is a complex language run-time, and there's all sorts of issues that can be language and language run-time related, regardless of it being written in Rust or C++, that manifest as out-of-bounds errors. I couldn't find any information about work-arounds.

nolist_policy 3y ago

It says severity high everywhere, but doesn't the attacker also need to break out of the sandbox to do actual damage? With this vulnerability alone you only gain remote code execution inside the sandbox.

bri3d 3y ago
There’s also a very interesting wasm based Ubercage (V8) sandbox escape in the chain: https://blog.exodusintel.com/2024/01/19/google-chrome-v8-cve-2024-0517-out-of-bounds-write-code-execution/ https://blog.exodusintel.com/2024/01/19/google-chrome-v8-cve... I don’t think the Chrome process isolation sandbox is escaped though.
- throwitaway1123 3y ago
  In the demo video they're running Chrome using the --no-sandbox flag. Can this be exploited without that option? I can't actually test this myself at the moment, because the vulnerability only works on x86_64 machines.
  - bri3d 3y ago
    Yes, it can be exploited, just inside the sandbox. I'm pretty sure this is why the write-up is always so careful to say "read/write inside the Chrome sandbox." With the chain that's documented, you basically end up with full R/W/X control inside of the sandbox process, so what you can do is highly platform and version specific. For example, IIRC you used to be able to unmask Tor and many VPN and proxy users from inside of the sandbox using either JavaScript or native networking APIs. It's my recollection that this is less true on newer Windows versions, but I don't keep up with Chrome sandbox protection that well. Presumably Exodus also have a sandbox escape that didn't get burned so they didn't include it in the writeup.
    - throwitaway1123 3y ago
      > Presumably Exodus also have a sandbox escape that didn't get burned so they didn't include it in the writeup. I certainly hope not. I know these zero day exploits tend to be used almost exclusively against high profile politicians and journalists, but the threat still tempts me to just disable the JIT altogether (and maybe WASM too).

costco 3y ago

I wonder how many bugs like this are found with and without fuzzing. I don't really know very much about this area but the diffs to fix these bugs are always a couple of lines and it's always very subtle. You'd basically have to have written the code yourself to know there's something wrong. Here's another example of what I'm talking about: https://zerodayengineering.com/insights/chrome-webrtc-cve-2023-7024.html https://zerodayengineering.com/insights/chrome-webrtc-cve-20...