2 ms·

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.

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

by ksk 9y ago

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