This shouldn't have happened: A vulnerability postmortem • Hacker News Board

Re: This shouldn't have happened: A vulnerability postmortem

#491

Post by lucb1e » Fri, Dec 03, 2021, 7:50 PM UTC

throwaway894345 wrote: post #113

lucb1e wrote: post #100

Earlier quoted context omitted.

Honestly I don't like the build process of most go/rust/javascript software any better than C++. It's harder to find the dependencies for building the latter, but the former has its own version of dependency hell. I have real trouble building both types of projects, though admittedly (especially when the building instructions don't work when followed to the letter) C++ a bit more than the strategy of "everything is j…

> everything is just pulled from github I hear this a lot, but I can't divine any substance from it. Why is GitHub a less-secure repository medium than SourceForge + random website downloads + various Linux package managers? Maybe this is a red herring and your real complaint is that the Rust ecosystem is less secure than the C/++ ecosystem? > you only have to make sure you've got gigabytes of free space in ~/.cache/…

> What does this even mean? You can compile Go or Rust programs on any Linux machine with the build tools.

I can't build github.com/restic/rest-server because my golang compiler is too old. Admittedly I'm running something relatively old (but still supported) at the moment but this isn't the first time. Such errors are my experience every time I try to build go/js code. If you're actually using a stable distribution you're simply out of luck and need to find another system to contribute to those projects.

> Why is GitHub a less-secure repository medium than SourceForge + random website downloads + various Linux package managers?

I'd trust GitHub a lot more than SourceForge, but GitHub is where everyone hosts everything these days so I meant it to mean: random repositories from the internet. When trying to build the aforementioned project, I saw a it pull from a ton of domains, but also a lot form GitHub (many different authors).

That's the crux: I may trust github itself and the author of this one repository (in this case, the author is actually a friend of a friend, in other cases it might just be a well-known person like cperciva or sircmpwn), and if my OS is compromised then I'm screwed anyway so the repositories are also considered mostly trusted, but I don't for a minute believe that the author of the code I'm trying to build managed to vet the 600 repositories it's pulling.

Also, six hundred repositories. All this thing does is spawn an http server and handle a few API calls, acting as a dummy storage server (implementing things like 'get me this file' or 'put this file here').

> Go programs absolutely don't run arbitrary code at compile/install time

I didn't actually know that, that's nice. I mean, still if I can't trust the binary then it's of little use to me personally, but any malicious code would presumably have to be called into and build servers will have an easier time serving binaries, so that's a good thing.

Re: This shouldn't have happened: A vulnerability postmortem

#492

Post by lucb1e » Fri, Dec 03, 2021, 7:53 PM UTC

fleventynine wrote: post #162

lucb1e wrote: post #96

Earlier quoted context omitted.

By 'complicated' in point 1, do you mean 'large'? Because a complex algorithm should be fine -- heck, it should be better in something like Python because it's relatively easy to write, so you have an easier time thinking about what you're doing, avoid making a mistake that would lead to an O(n³) runtime instead of the one you were going for, takes less development time, etc. I assume you meant 'large' because, as so…

By complicated I guess I mean "lots of types". Static typing makes up for its cost once I can't keep all the types in my head at the same time. Point number 2 excludes pretty much all network-connected software, and that's intentional. I suppose single-player games are ok to write in C or C++.

> 2 excludes pretty much all network-connected software

Not caring about local privilege escalation I see ;). Attack surface might be lower, but from lockscreens to terminals there is a lot of stuff out there that doesn't need to be connected to the internet itself before I find it quite relevant to consider whether it was written in a dumb language.

Re: This shouldn't have happened: A vulnerability postmortem

#493

Post by pcwalton » Fri, Dec 03, 2021, 8:29 PM UTC

IggleSniggle wrote: post #469

pcwalton wrote: post #248

Earlier quoted context omitted.

Zig is, however, not memory safe, which outweighs all of those benefits in this context.

It can be memory safe. It's up to you to choose memory safety or not. That's a piece of what I was getting at. Unless I misunderstand something. I've only dabbled with Zig.

I'm not aware of any memory safety that works in Zig, other than maybe Boehm GC. The GeneralPurposeAllocator quarantines memory forever, which is too wasteful to work in practice as one allocation is sufficient to keep an entire 4kB page alive.

Re: This shouldn't have happened: A vulnerability postmortem

#494

Post by vips7L » Fri, Dec 03, 2021, 9:08 PM UTC

blub wrote: post #445

davedx wrote: post #368

Earlier quoted context omitted.

You literally mention Java GUI apps in response to a post that calls out Android, a mobile OS and application ecosystem implemented in Java . The languages are not the issue.

It took Google more than a decade of trying and a VM rewrite to get close to the perceived performance of iOS. And anything performance intensive was done in the NDK anyway. All of this because of Java.

Android is not Java.

Re: This shouldn't have happened: A vulnerability postmortem

#495

Post by titzer » Sat, Dec 04, 2021, 4:48 PM UTC

pjmlp wrote: post #476

titzer wrote: post #472

Earlier quoted context omitted.

Not sure what you were expecting, but no, Wasm doesn't magically make memory-unsafe languages internally uncorruptible, it limits all corruption to internal state. If you look at the PL research stretching back a couple decades on how to do that for C, you are looking at integer factor performance overheads in the general case. Wasm also doesn't make anything less safe than it was before (ok, ok, modulo the current l…

I was expecting that people don't oversell WebAssbemly as some kind of magic pixie dust of security, anyone that knows a bit about security spots those flaws. You know what is also sandboxed? An OS process. Ah, but an OS process has a wider syscalls surface, well lets than bring WASI or JavaScript bindings into the picture.

At least we are on the same page on the level of sandboxing provided. For the record, it was your comment that called it a "big mistake" to not have finer-grained memory protection. I explained why we did that. And now you're saying someone "oversold" it as magic pixie dust? I'm not sure which hype train you're referring to, TBH. It wasn't core members or the CG, as we understood very clearly which security properties we were gaining and which we were not gaining.

Re: This shouldn't have happened: A vulnerability postmortem

#496

Post by hedora » Sat, Dec 04, 2021, 5:22 PM UTC

astrange wrote: post #291

ajxs wrote: post #234

Earlier quoted context omitted.

Can you provide more information on this? I'd be interested to read about this topic.

He's confused it with Dual_EC_DRBG, a backdoored random number generator in a different non-international standard. SSL is complicated because we didn't understand how to design secure protocols in the 90s. Didn't need help.

No; this predated that by about a decade. They had moles on the committees that codified SSL in the 90’s. Those moles added a bunch of extensions specifically to increase the likelihood of implementation bugs in the handshake.

I’m reasonably sure it was covered in cryptogram a few decades ago. These days, it’s not really discoverable via internet search, since the EC thing drowned it out.

Edit: Here’s the top secret budget for the program from 2013. It alludes to ensuring 4G implementations are exploitable, and to some other project that was adding exploits to something, but ramping down. This is more than a decade after the SSL standards sabotage campaign that was eventually uncovered:

http://s3.documentcloud.org/documents/784159/sigintenabling-...

With SSL, the moles kept vetoing attempts to simplify the spec, and also kept adding complications, citing secret knowledge. It sounds like they did the same thing to 4G.

Note the headcount numbers: Over 100 moles, spanning multiple industries.

Re: This shouldn't have happened: A vulnerability postmortem

#497

Post by lenkite » Sat, Dec 04, 2021, 9:00 PM UTC

flohofwoe wrote: post #393

lenkite wrote: post #309

Earlier quoted context omitted.

Is it OK to remove modern C++ from your statement ? Using a `std::vector ` wouldn't cause this problem. Don't know why everyone always berates C++ for vulnerabilities in traditional C code.

People who memcpy bytes into a destination without caring if there's enough room would also not hesitate to use memcpy to copy bytes into a std::vector though.

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

Re: This shouldn't have happened: A vulnerability postmortem

#498

Post by titzer » Mon, Dec 06, 2021, 1:54 PM UTC

alophawen wrote: post #335

titzer wrote: post #281

Earlier quoted context omitted.

Have you measured the pause times of free()? Because they are not deterministic, and I have met few people who understand in detail how complex it can be in practice. In the limit, free() can be as bad as GC pause times because of chained deallocation--i.e. not statically bounded.

This is true, but for performance's sake, you should not alloc/free in a busy loop, especially not on a real time system. Allocate in advance, reuse allocated memory.

> Allocate in advance, reuse allocated memory.

In practice, almost all real-time systems use this strategy, even going so far as to allocate all memory at compile time. The first versions of Virgil (I and II) used this strategy and compiled to C.

When doing this, the whole debate of memory safe (automatic) vs unsafe (manual) is completely orthogonal.

Re: This shouldn't have happened: A vulnerability postmortem

#499

Post by burntsushi » Mon, Dec 06, 2021, 6:35 PM UTC

mleonhard wrote: post #180

tialaramex wrote: post #152

Earlier quoted context omitted.

I don't think there are any general purpose programming languages with decent performance which outright "prevent undefined behaviour" in something like NSS. Rust, for example, does not. safe Rust doesn't have undefined behaviour but of course you can (and a large project like this will) use unsafe Rust and then you need the same precautions for that code. This sharply reduces your exposure if you're doing a decent j…

> I don't think there are any general purpose programming languages with decent performance which outright "prevent undefined behaviour" in something like NSS. Rust, for example, does not. You know what I meant by "a language that prevents UB". Your comment argues semantics. That's not nice. Please stop. > safe Rust doesn't have undefined behaviour but of course you can (and a large project like this will) use unsafe…

> A large Rust project uses unsafe only because its authors don't care enough.

This is not true. That might account for some aspects of why there are some uses of 'unsafe', but it is not true of all uses of 'unsafe'.

The existence of 'unsafe' is itself the clearest demonstration of why you're wrong on this point. Its existence is a practical trade off that acknowledges it is sometimes necessary to use 'unsafe' to accomplish some goal, and that there is a long tail of such uses. Too long to feasibly build and enumerate every such case into the language. The goals might be rooted in functionality or performance or possibly other things.