Hacker News Reader

Comment by politelemon | Hacker News Reader

> an OS that requires frequent security patches > Security is not a feature that can be layered on. It has to be built in

This is a common misunderstanding, an OS that receives frequent security updates is a very good thing. That means attention is being paid to issues being raised, and risks are being mitigated. Security is not a 'checkbox' it's more of a neverending process because the environment is always in a state of flux.

So to flip it, if an OS is not receiving updates, or not being updated frequently, that's not great.

What you want is updates that don't destabilize an OS, and behind that is a huge history and layers of decisions at each 'shop' that runs these machines.

Security is meant to be in layers and needs to be built in.

> but it still doesn't work.

It does work because the 'scene' has been silent for so long, but what we as humans notice is the incident where it didn't.

View on HN

This sort of thinking is one of the main problems with the industry, in my opinion.

We've got a bunch of computers that mostly don't make mistakes at the hardware layer. On top of that, we can write any programs we want. Even though the halting problem exists, and is true for arbitrary programs, we know how to prove all sorts of useful security properties over restricted sets of of programs.

Any software security pitch that starts with "when the software starts acting outside of its spec, we have the system ..." is nonsense. In practice, "acting outside its spec" is functionally equivalent to "suffers a security breach".

Ideally, you'd use an operating system that has frequent updates that expand functionality, that is regularly audited for security problems, and that only rarely needs to ship a security patch. OpenBSD comes to mind.

If software has frequent security updates over a long period of time, that implies that the authors of the system will continue to repeat the mistakes that led to the vulnerabilities in the first place.

> and that only rarely needs to ship a security patch. OpenBSD comes to mind.

How is that accomplished? Are OpenBSD programmers somehow vastly more competent, that they make security mistakes only 0.1% as often as other OS's?

I find that hard to believe. People are people.

> If software has frequent security updates over a long period of time, that implies that the authors of the system will continue to repeat the mistakes that led to the vulnerabilities in the first place.

Why would that be the case? Authors come and go, systems live on.

Security updates arise from a combination of auditing/testing and competence. 100 times as many security updates can arise simply because one OS is being used and battle-tested 100x more than another.

Nobody's smart enough to write code that "only rarely needs to ship a security patch". Not at the scope of an entire OS with thousands of people contributing to it.

> Are OpenBSD programmers somehow vastly more competent

Put simply, yes. If you read open OpenBSD's website what philosophies and practices drive how the OpenBSD project is run, you'll have an idea.

You realize that you are personally insulting 100k people you've never met by judging their individual skills and abilities despite knowing nothing about them?

It makes it very hard to put any credence into your opinion when you are so judgemental with no information.

OpenBSD still has security updates. Software packages often installed on OpenBSD-based systems often issue security updates. OpenBSD has a much smaller footprint than Windows and still has security updates.

> Are OpenBSD programmers somehow vastly more competent

It's not about competence, it is about priorities.

OpenBSD obsesses about security, so that's what drives the decision-making.

All public companies are driven by profit above all, with the product being just a mechanism to get more profit. As a direct consequence, quality (and security, which is part of quality) is not the top priority. Security is only relevant to the extent its absence reduces profits (which very rarely happens).

CCC has a talk about the effectiveness of OpenBSD decisions.

TL;DW It isn't as much as people think.

I think that’s an oversimplification. If you have a Windows system handy, look for a file named “errata.inf” [0]. It’s a giant configuration file that is full of tweaks to make dodgy hardware work reliably.

Hardware, software and firmware are all prone to mistakes, errors and corner cases that are surprising. Security issues generally live in the intersection of systems with different metaphors. Hardware is not immune from issues, and software can help reduce that impedance mismatch.

[0] Found an instance here, no claim to its veracity or safety: https://www.gherush92.com/documents/744E.asp?type=2&file=C%3...

Remote update is a nice way of saying remote code execution. It is really really hard to ensure that only the entity that you want to update your system, can update your system, when facing a state-funded adversary. Sometimes that state adversary might even work in concert with your OS vendor.

That's before even addressing mistakes.

Is that really so hard? Isn’t the problem mostly solved by signing your update and verifying the update at the client? As long as you can keep the private key secret, that should be enough, right? Or are we assuming you can’t keep a single key private from your adversary?

Yes, this is really hard.

You could get a Solarwinds type situation where the adversary has the signing keys and ability to publish to the website.

You might also find that the vendor ships a library (like libxz) as a part of their invisible or hidden supply chain, that is able to be compromised.

You might find that one of the people working at the company makes a change to the code to enable remote access by the adversary in a targeted collaboration/attack.

The problem isn't that signing key (although I could delve into the lengths you'd need to go to to keep that secret under these threat models) - the problem is what they sign. A signed end release binary or series of packages isn't going to address the software source code itself having something added, or the dependencies of it being compromised.

Except for the first point, these things aren’t exclusive to remote updates though. I thought we were talking about the challenges of remote updates compared to other methods (like replacing the system or manually updating it with installation media). Supply chain and insiders would be affected that, too.

"If your adversary is the Mossad, YOU'RE GONNA DIE AND THERE'S NOTHING THAT YOU CAN DO ABOUT IT." [1]

Not patching is insane -- you'll let script kiddies in. Patching might not stop the next Stuxnet author, but you'll slow them down _and_ have fewer script kiddies.

A lot of people seem to be focusing on how the band-aid of automatic security updates can be ugly without considering the hemorrhaging that it's actually stemming. Nobody's stepping up with a realistic solution to the problem, which means we're stuck with the band-aids.

[1] https://www.usenix.org/system/files/1401_08-12_mickens.pdf

Frequent security updates are a good thing, frequent security auto-updates are not, at least when it comes to situations like this. Technology that runs 24 hour services such as airports and train stations should not be updated automatically just like that, because all software updates have high potential to break or even brick something. Automation is convenient and does saves money which would have to be paid for additional labor to do manual updates, but in cases like this, it should be understood that it's better not to break the airport and roll-out update manually in stages.

Reply on news.ycombinator.com