5 ms·

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

dotancohen 2y ago
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.
- echoangle 2y ago
  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?
  - g_p 2y ago
    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.
    - echoangle 2y ago
      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.
- NegativeK 2y ago
  "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 https://www.usenix.org/system/files/1401_08-12_mickens.pdf
hedora 2y ago
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.
- crazygringo 2y ago
  > 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.
  - commercialnix 2y ago
    > 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.
Alteran 2y ago
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.

dotancohen 2y ago

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.

echoangle 2y ago
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?
- g_p 2y ago
  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.
  - echoangle 2y ago
    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.
NegativeK 2y ago
"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 https://www.usenix.org/system/files/1401_08-12_mickens.pdf

hedora 2y ago

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.

crazygringo 2y ago
> 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.
- commercialnix 2y ago
  > 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.

Alteran 2y ago

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.