3 ms·

Would you find it similarly useful the day after someone else decided to re-image all your machines and then change BIOS password settings to further prevent yo

Would you find it similarly useful the day after someone else decided to re-image all your machines and then change BIOS password settings to further prevent you from fixing the problem? How about if they then decided to send you a ransom notice that you could regain access to your infrastructure for a particular sum of money? Stuff like this is real and happens all over the world. Businesses would rather not publically admit that they've been owned, either: it's spectacularly bad press. Fortunately, most of the security vulnerabilities that have been abused in this sort of way in the past are patched quickly. But what if it was impossible to patch systems because the vulnerability is baked into firmware? That's the horrifying case that we have here. If exploiting this software (and exploits HAVE ALREADY been published, so it's really just a matter of weaponisation at this point) becomes common, then many sysadmins will be in the unenviable position where someone who can download instructions from the Internet can cause immense damage to their systems and network on any given day. And that's just the tip of the iceberg. Imagining how these systems are very, very likely already being used to conduct digital espionage is similarly disturbing. It's easy to think that "no one would want to conduct espionage against my tiny company in ${small town}", but unfortunately the reality is quite different. https://www.fbi.gov/news/stories/economic-espionage https://www.fbi.gov/news/stories/economic-espionage has some reasonably interesting information about the sort of shenanigans that are routinely undertaken - unfortunately this is just a small example as many instances are not publically discussed.

ksk 9y ago
Discussion over security concerns is valid and helpful in moving the conversation forward. Outrage over something we don't even understand doesn't help anyone. Especially when people are presenting a strawman/misrepresenting the details. Computer security requires you to model the threat first, before proposing mitigations/solutions/tradeoffs/etc. Has this been done here? I'm merely asking since I don't know. Questions by themselves might lead us to an interesting path of inquiry, but we should also occasionally ground ourselves so we know what actually happens when the rubber meets the road.
- structural 9y ago
  It's interesting that this is being discussed again this year, because the critical part of the discussion really happened back in May of this year. https://nvd.nist.gov/vuln/detail/CVE-2017-5689 https://nvd.nist.gov/vuln/detail/CVE-2017-5689 is the CVE in question and existed for ~7 years, permitting exactly the scenarios I postulated to occur given unprivileged access to the network on which the servers reside. There's been some rapid threat modeling done already: for example, for datacenter environments, the impact of this issue is largely mitigated by reducing physical access to this network behind the firewall - https://software.intel.com/en-us/documentation/amt-reference/manageability-ports https://software.intel.com/en-us/documentation/amt-reference... indicates that we can firewall traffic so that only known management computers can access it from outside. (However, one compromised computer in the datacenter can be used as a source to trigger this exploit, so whole-datacenter monitoring/alerting for traffic on these ports is required). The overall risk involved is still fairly high, because this security posture is effectively "remote root-level access for anyone with unprivileged access to the local network".

ksk 9y ago

Discussion over security concerns is valid and helpful in moving the conversation forward. Outrage over something we don't even understand doesn't help anyone. Especially when people are presenting a strawman/misrepresenting the details. Computer security requires you to model the threat first, before proposing mitigations/solutions/tradeoffs/etc. Has this been done here? I'm merely asking since I don't know. Questions by themselves might lead us to an interesting path of inquiry, but we should also occasionally ground ourselves so we know what actually happens when the rubber meets the road.

structural 9y ago
It's interesting that this is being discussed again this year, because the critical part of the discussion really happened back in May of this year. https://nvd.nist.gov/vuln/detail/CVE-2017-5689 https://nvd.nist.gov/vuln/detail/CVE-2017-5689 is the CVE in question and existed for ~7 years, permitting exactly the scenarios I postulated to occur given unprivileged access to the network on which the servers reside. There's been some rapid threat modeling done already: for example, for datacenter environments, the impact of this issue is largely mitigated by reducing physical access to this network behind the firewall - https://software.intel.com/en-us/documentation/amt-reference/manageability-ports https://software.intel.com/en-us/documentation/amt-reference... indicates that we can firewall traffic so that only known management computers can access it from outside. (However, one compromised computer in the datacenter can be used as a source to trigger this exploit, so whole-datacenter monitoring/alerting for traffic on these ports is required). The overall risk involved is still fairly high, because this security posture is effectively "remote root-level access for anyone with unprivileged access to the local network".