How many times does this have to happen before we start rejecting components written in unsafe languages?
For example Go, while not totally memory safe, has shipped their Go-implemented crypto/tls library for a long time. (And also had some crypto correctness bugs - reminding us that memory safety is "necessary but not sufficient" for a TLS implementation)
Maybe it doesn't immediately sound as if this is related to security, but it is. If it is hard to model your data and hard to work with it, then people will go the "easy and fast" path.
Think Java: for each type you have to create a new file. Even with modern tooling that is still annoying. So people often shortcut and just use "String". Now you have "String password" and "String userid" and you can swap it up and print the password by accident. Artificial example, I know, but I hope it explains what I mean in general.
That's untrue, Java has inner classes, and they can even be public. A "public static" inner class is nearly indistinguishable from a normal top-level class (the only real difference is that its name in the bytecode has a $ character separating the names, that is, its name in the bytecode ends up being something like "org.example.Outer$Inner").
That being said, it maybe makes it slightly better, but I hope you agree that this is still very much a supoptimal solution and probably comes from a time where searching filenames was the best way to navigate code in the lack of modern IDEs.
Use a GC when you can, it's the biggest programming productivity and quality improvement in PLT of the last 60+ years.
[1] Though I know Zig has some interesting mitigations, some used and some under research: https://news.ycombinator.com/item?id=31853964 https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j
(I misspoke a bit with "Rust doesn't have GC", it does have opt in basic GC in the form of ref counting, but it's not used much because a headline feature of Rust is code without GC and I guess libs with interfaces requiring GC would be considered uncool)
[1]: there can be memory safety issues in the presence of data races, but this has ever been proven exploitable, doesn't cause the compiler to completely miscompile and is very rare in practice, so it's not comparable to unsafe memory languages.
I agree (typo exploit!)
See eg https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... & https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
(And also people shouldn't take "nobody developed an exploit for this vulnerability yet" as any kind of strong evidence, attacks techniques always get better, never worse, over time etc - crypto algorithm people have it right when they start bracing for impact quite early after signs of a theoretical break)
Might it be a crypto bug, or logic bug (eg in x.509)? Is there code that's used by both OpenSSL and Go (eg assembly implementations of algorithms both imported or modeled after a reference)?
See screenshot of the slack conversation: https://paste.pics/f5622033ae711b36e0bbcda393a67866
If this software was using Rust, it would be much harder to break them than is currently the case.
And tbh, I have to concur (somewhat). I have lost little-to-nothing due to software exploits, but have gained significantly. For example, reading epubs with my kindle or loading homebrew on game consoles.
You should do good things consistently, not bad things to offset worse things. If DRM is a serious problem in your life, put your money and time where your opinions are and avoid hardware and software products that enforce it rather than mandating insecurity for everyone else.
The Kindle was already 8 years old when I got it, isn't it better to re-use it with more current software? The same with router hardware that gets exploited to flash OpenWRT.
It's very hard to get a modern Smartphone (with acceptable cameras, battery life, performance and software availability) with manufacturer-intended root access.
While I agree that people should adopt Rust (and other approaches) for their security porperties, it's not hard to see how it may lead to exploits getting rarer and to more categories of devices & content that can't be reasonably used in a "free" way, even if not intended by the manufacturer. Thus making it much harder to have control over the devices you own (without becoming some kind of luddite).
That being said: I don't think the world is necessarily a worse place if (1) everybody's devices are more secure, and (2) consumers are a whole are disincentivized from buying into ecosystems that fundamentally don't respect their rights. At the risk of sounding like the luddite you mentioned: maybe we really could use a little separation between technology and literally every other domain of our lives.
The metaphor I like to use is "giving them better nooses to put around our necks."
...and I suppose you could argue that neither do guns kill people...?
Unfortunately for computer security this has been a wild west.
The same security flaw that lets you jailbreak a phone could also allow a hostile entity to say "we don't need you to unlock your phone/laptop, we'll just seize it and break into it using known security vulnerabilities".
Buy devices that you control. Don't try to make other people's devices less secure because you want to break into your own.
Caddy, Traefik, and Teleport are written in Golang and not using OpenSSL. It’s a start.
If the Go issues were distinct I’d imagine they’d choose a different day to disclose/release?
I think it's just a funny coincidence. That's going based on what I know about the OpenSSL one; I don't know anything about the Go one. We'll find out!
See screenshot of the slack conversation: https://paste.pics/f5622033ae711b36e0bbcda393a67866
The ones that use Rust - Firefox and Windows
Additionally even if C++ is unsafe, it is still better than plain old C, which since Vista has been the migration path from kernel code. Nowadays there are even template libraries that can be used on kernel and drivers like WIL.
Finally the Microsoft Security Guidelines are:
1 - use managed languages if one can afford it
2 - use Rust
3 - use C++, alongside SAL and Core Guidelines checkers
Wasn't there a fork the last time they fucked up badly with a security issue anyway?
When the pocket money gets affected all companies will care about security.
Things are thankfully moving into that direction, US security bill already calls out that one needs to think about delivering software written in C and C++. Only a matter of time until one needs some kind of clearance to deliver software to government agencies with unsafe languages.
Otherwise I look forward to the day when we stop driving unsafe cars, whatever that means. Accidents can always happen.
Needless gizmos.