[fulafel]

The start has happened, but it's happening unevenly with different users. Lots of TLS servers (in reverse proxies but also in backend apps and even Apache httpd[1]) are in memory safe 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)

[1] https://www.memorysafety.org/blog/memory-safe-httpd/

[stigz]

Speaking of go, it looks they will be patching this as well.

https://groups.google.com/g/golang-announce/c/dRtDK7WS78g

[fulafel]

Yep, this is interesting, I wonder what we can deduce about the nature of the bug from the fact that 2 separate implementations, one that's mostly memory safe, are impacted. (Of course Go didn't announce it's about the same thing, so it might be random, or might be some security research that found different bugs)

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)?

[Ayesh]

In the linked article, Global sign says they don't know what exactly the vulnerability is. I imagine the public root CAs to be informed if this was an x.509 related bug. But again, Global Sign is a pretty shitty CA to begin with, so I wouldn't be surprised if they were not informed intentionally.

[fulafel]

I'm not sure why CAs would be invited to the embargo, they're in the business of signing certs and while they do process untrusted certs so do zillions of other cert using folks.

[Ayesh]

Just an speculation; for an x.509/web of trust related vulnerability, I expect the CAs to be a prominent target. There are hundreds of them, and I'm pretty sure there are at least a few of them that use OpenSSL somewhere in their certificate issuing process. Just to avoid DigiNotar-like fiascos revoking certificates en-masse, it probably makes sense to give a head-start to CAs.

[komuW]

Filippo Valsorda(FiloSottile), who is the maintainer of Go's cryptography libraries said on Go's slack channel that the patch is unrelated.

See screenshot of the slack conversation: https://paste.pics/f5622033ae711b36e0bbcda393a67866

[valenterry]

Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.

[fulafel]

They don't have GC so they either make programs difficult to write (Rust) which hinders delivering secure replacements, or have use-after-free security problems (Zig) [1].

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

[drran]

Rust doesn't have GC, but it has very good automatic memory management. GC or memory management doesn't make programs immune to buffer overflows, which is the most common security vulnerability these days, while use-after-free is at 4th place.

[fulafel]

What do you mean by automatic memory management here?

(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)

[valenterry]

Sure, I agree - I don't think what you said contradicts my point.

[bitwize]

Modern automatic memory management techniques like RAII and ARC largely render GC obsolete.

[pjmlp]

Reference counting is hardly modern, and is a GC algorithm.

[littlestymaar]

I'm not a fan of Go but it is memory safe (with a very minor exception[1]), Zig isn't (it will likely end up safer than C, but it will be “modern c++”-safe but not memory safe.

[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.

[fulafel]

> this has ever been proven exploitable

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)

[littlestymaar]

Oh, I wasn't aware of the second blog post, thanks.

[nine_k]

What makes Zig safer than Go, to your mind?

[valenterry]

Features such as sum types (enums) that you can pattern match on. Or generics (well now Go got them as well, for a reason).

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.

[cesarb]

> Think Java: for each type you have to create a new file.

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").

[valenterry]

Well, you still have to define them inside of another class then and have to find one that makes sense. They also have an reference to the outer class which might not be desirable.

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.

[pjmlp]

No you don't, only for public types , types internal to the package can stay on the same file.

[pjmlp]

Rust yes, Zig is hardly any better than Modula-2.

[valenterry]

So that means Modula-2 is better than Go? :)