3 ms·
How many Heartbleeds[1] must software users and our national security interests endure before the industry treats memory safety as a best practice for systems w
by odyssey7 1mo ago
How many Heartbleeds[1] must software users and our national security interests endure before the industry treats memory safety as a best practice for systems with exposure to the Internet?
The V8 vulnerability being exploited today, CVE-2026-85046, is listed in NVD under CWE-843, "Access of Resource Using Incompatible Type ('Type Confusion')."[2] On this class of vulnerabilities, MITRE explains:
> When a memory buffer is accessed using the wrong type, it could read or write memory out of the bounds of the buffer
Memory safety is specifically intended to prevent errors like these from becoming arbitrary out-of-bounds memory access and native code execution. Even type safety --- from the 1970s --- can prevent type confusion.
The CISA and the NSA have called for the adoption of memory-safe languages.[3] We exercise poor engineering judgment and poor ethics, as an industry, when we continue to expose users to classes of wholly avoidable security weaknesses in Internet-facing software.
[1] https://en.wikipedia.org/wiki/Heartbleed https://en.wikipedia.org/wiki/Heartbleed
[2] https://cwe.mitre.org/data/definitions/843.html https://cwe.mitre.org/data/definitions/843.html
[3] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4223298/nsa-and-cisa-release-csi-highlighting-importance-of-memory-safe-languages-in-so/ https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...
- no-name-here 1mo ago[dead]
- dchest 1mo agoThere's more to it than just using a memory safe language.
- deleted 1mo ago[deleted]
- dundarious 1mo agoType confusion bugs exist in Rust programs too, the language does not eliminate all such issues (though it does help somewhat). I think it would be more prudent to wait until we have details before getting on the soapbox.
- mccr8 1mo agoJIT bugs like this are not easily solved simply by writing a browser in a typesafe language. Here's the commit that fixes this issue: https://chromium.googlesource.com/v8/v8/+/e0562d87ad9c17042b581582c99237d798572e67%5E%21/ https://chromium.googlesource.com/v8/v8/+/e0562d87ad9c17042b...
- odyssey7 1mo agoIf including JIT in a system renders its developer incapable of guaranteeing memory safety, then perhaps that developer’s approach to JIT is not yet mature enough to ethically distribute to non-technical consumers who are not positioned to evaluate that their security is being traded off by the developer on their behalf. We’re past the era where security issues emanating from memory-unsafe code were tolerated due to being unavoidable — continuing to expose your software’s users to them in this present day and age is simply a choice.
- jaen 1mo agoYou're just offering non-helpful ivory tower criticism without even understanding the problem space (which is actually one of the hardest open research problems in software engineering, cs.PL + formal methods). But if I'm wrong, dare say, how would you write a production memory-safe JIT compiler today?
- odyssey7 1mo agoIf I couldn't guarantee memory safety, I wouldn't. We're talking about an optional feature for JavaScript engines. Security is where the rubber hits the road. It's whether customers' identities get stolen. It's whether leaders of undemocratic countries can monitor communications, locations, and social networks of people whom they oppress. Calling this an "ivory tower" criticism is, ironically, a lack of acknowledgement of reality and that our actions have consequences to others.
- deleted 29d ago[deleted]
- Retr0id 1mo agoHow do you write a performant memory-safe JS JIT?
- deleted 1mo ago[deleted]
- richdougherty 1mo agoYou probably need a programming language more powerful than Rust that can encode and check the complicated invariants needed by the JIT. There are classes of type system—"dependently-typed"—where you can encode arbitrary predicates into the type checking. I've remember seeing examples where they could prove arbitrary facts at the assembly level, including self-modifying code. Lean is such a language, currently very popular, but there are others. Correctness of such programs depends on some basic assumptions about the CPU/memory environment, which should work absent hardware bugs like speculative execution or side channels. Although these could probably be encoded as well, and accounted for. Without such a general proof language, you could probably make a special language to support JIT development, although its type system would be very complicated and the language itself could be a source of bugs. Given such languages or proofs (maybe tractable now with AI-assisted theorem proving), you can actually make insanely performant code, since you don't really need to rely on other runtime protection so much (although maybe a good idea still).
- wavemode 1mo agoThis was a type confusion bug in generated JIT code, not in C++ code.