3 ms·

I do not like the post. It seems scant on details and rife with conclusions. The Google presentation linked to has a bit more detail on the underlying technolog

by ngneer 9y ago

I do not like the post. It seems scant on details and rife with conclusions. The Google presentation linked to has a bit more detail on the underlying technologies. A modern processor is a complex beast, and a security argument can always be made to reduce complexity. Citation needed for espionage and privacy evasion use cases...

aylons 9y ago
Surely, this is more an opinion piece than a didactic article. Here you have a more detailed write-up on the issue, including a known vulnerability and how others could be lingering: https://www.eff.org/deeplinks/2017/05/intels-management-engine-security-hazard-and-users-need-way-disable-it https://www.eff.org/deeplinks/2017/05/intels-management-engi...
- ngneer 9y ago
  Thanks. The citation describes the existence of vulnerabilities and laments the lack of transparency. While the latter is indeed lamentable, and is known to be a contributing factor in increasing risk, vulnerabilities do exist in any system, including transparent ones (e.g., OpenSSL). Still am not seeing any evidence of malice by this vendor, as "providing a full set of entrenched vulnerabilities, user espionage tools and privacy-evading mechanisms" would perhaps imply. Vendors have a hard time with security. Chip vendors are no different, only the stakes are higher.
  - zAy0LfpBZLC8mAC 9y ago
    The important point is that in the case of OpenSSL, anyone who wanted to know could know, and plenty of people knew. Not the specific vulnerabilities, but the horrible quality of the code base was not just something that you could discover by looking at the source, it is something that plenty of people did discover. Also, obviously, anyone could in principle fix vulnerabilities they find in OpenSSL, without any need to wait for the OpenSSL project or anyone else to do anything.
zAy0LfpBZLC8mAC 9y ago
That's not how reliable, safe, secure engineering works. You don't consider stuff safe until someone proves that it will kill you/let people steal your data/whatever, but rather everything is suspect unless it can be demonstrated that according to current state of the art/best practices, it can reasonably be expected to be safe. A bridge isn't considered safe until it collapses, it is considered unsafe until it has been shown that according to our current understanding of physics and material properties, it can be expected to hold up. The same should obviously apply to software and computing hardware.
- ngneer 9y ago
  That implication was not intended. I was merely attempting to address the FUD. If anything, I took care to mention that all systems are vulnerable and must be assumed as such.
  - zAy0LfpBZLC8mAC 9y ago
    But the point is that it's not FUD if doubt is the correct default position, the situation is in fact uncertain, there is no reasonable way for you to resolve the uncertainty, and fear is justified in the face of that uncertainty. FUD is when you deliberately avoid getting an accurate picture of the uncertainty/danger so as to paint as bleak a picture as possible and thus induce gratuitous fear.

by ngneer 9y ago

aylons 9y ago

Surely, this is more an opinion piece than a didactic article. Here you have a more detailed write-up on the issue, including a known vulnerability and how others could be lingering: https://www.eff.org/deeplinks/2017/05/intels-management-engine-security-hazard-and-users-need-way-disable-it https://www.eff.org/deeplinks/2017/05/intels-management-engi...

ngneer 9y ago
Thanks. The citation describes the existence of vulnerabilities and laments the lack of transparency. While the latter is indeed lamentable, and is known to be a contributing factor in increasing risk, vulnerabilities do exist in any system, including transparent ones (e.g., OpenSSL). Still am not seeing any evidence of malice by this vendor, as "providing a full set of entrenched vulnerabilities, user espionage tools and privacy-evading mechanisms" would perhaps imply. Vendors have a hard time with security. Chip vendors are no different, only the stakes are higher.
- zAy0LfpBZLC8mAC 9y ago
  The important point is that in the case of OpenSSL, anyone who wanted to know could know, and plenty of people knew. Not the specific vulnerabilities, but the horrible quality of the code base was not just something that you could discover by looking at the source, it is something that plenty of people did discover. Also, obviously, anyone could in principle fix vulnerabilities they find in OpenSSL, without any need to wait for the OpenSSL project or anyone else to do anything.

zAy0LfpBZLC8mAC 9y ago

That's not how reliable, safe, secure engineering works. You don't consider stuff safe until someone proves that it will kill you/let people steal your data/whatever, but rather everything is suspect unless it can be demonstrated that according to current state of the art/best practices, it can reasonably be expected to be safe. A bridge isn't considered safe until it collapses, it is considered unsafe until it has been shown that according to our current understanding of physics and material properties, it can be expected to hold up. The same should obviously apply to software and computing hardware.

ngneer 9y ago
That implication was not intended. I was merely attempting to address the FUD. If anything, I took care to mention that all systems are vulnerable and must be assumed as such.
- zAy0LfpBZLC8mAC 9y ago
  But the point is that it's not FUD if doubt is the correct default position, the situation is in fact uncertain, there is no reasonable way for you to resolve the uncertainty, and fear is justified in the face of that uncertainty. FUD is when you deliberately avoid getting an accurate picture of the uncertainty/danger so as to paint as bleak a picture as possible and thus induce gratuitous fear.