4 ms·

I understand the urge to remove networking capabilities, but why do privacy folks freak out about the entireties of UEFI/ME/SMM? It's a fact that the hardware i

I understand the urge to remove networking capabilities, but why do privacy folks freak out about the entireties of UEFI/ME/SMM? It's a fact that the hardware is the one with control of the system at boot, and you're always at the mercy of the vendors in terms of bad code (whether intentional or otherwise). You can't get rid of hardware-specific code, and you also don't have any control over the designs of the chips. Both of those are places where it will always be possible to do something nefarious if the vendor feels like it. Unless you feel like fabricating your own chips from scratch, at some point you have to trust all these layers. Why suddenly freak out when it comes to new layers?

AstralStorm 9y ago
Because SMM can be disabled. UEFI potentially replaced and should renounce direct hardware access after initialization and driver disable. ME cannot be disabled and has both networking and direct memory access bypassing even IOMMU. Running in background.
- throwaway613834 9y ago
  > UEFI should renounce direct hardware access after initialization and driver disable I don't follow. If it's nefarious then doesn't having control in the beginning already screw you? And if not, but if it gets compromised, then can't it be programmed not to do that?
cjbprime 9y ago
Did you follow yesterday's news? The ME is remotely vulnerable, has full control over the machine, and it's not even clear that it can be upgraded in a secure way. Why wouldn't you be interested in turning it off? And why would you classify people who'd rather not be running remotely vulnerable code they can't control as "privacy folks"?
- throwaway613834 9y ago
  I did follow the news about being remotely vulnerable. That's why I said I'd understand the urge to remove the networking stacks. Other vulnerabilities would require local access. > Why wouldn't you be interested in turning it off? I'm not asking why you'd be interested in it, I'm asking why you'd freak out so much about it given X/Y/Z are already true and you can't do anything about them. There's a bit more nuance in my argument than you're giving me credit for here. > And why would you classify people who'd rather not be running remotely vulnerable code they can't control as "privacy folks"? I already excluded the part about remote vulnerability. See first point above.
- ksk 9y ago
  > The ME is remotely vulnerable, Could you please post a link on that? I read about the AMT bugs, which require the user to manually provision it.
  - macns 9y ago
    http://cve.circl.lu/cve/CVE-2017-5712 http://cve.circl.lu/cve/CVE-2017-5712 Summary: Buffer overflow in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allows attacker with remote Admin access to the system to execute arbitrary code with AMT execution privilege EDIT: I'm not sure this was the one the GP referring to
  - cjbprime 9y ago
    I was thinking of: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5708 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5708

AstralStorm 9y ago

Because SMM can be disabled. UEFI potentially replaced and should renounce direct hardware access after initialization and driver disable. ME cannot be disabled and has both networking and direct memory access bypassing even IOMMU. Running in background.

throwaway613834 9y ago
> UEFI should renounce direct hardware access after initialization and driver disable I don't follow. If it's nefarious then doesn't having control in the beginning already screw you? And if not, but if it gets compromised, then can't it be programmed not to do that?

cjbprime 9y ago

Did you follow yesterday's news? The ME is remotely vulnerable, has full control over the machine, and it's not even clear that it can be upgraded in a secure way. Why wouldn't you be interested in turning it off? And why would you classify people who'd rather not be running remotely vulnerable code they can't control as "privacy folks"?

throwaway613834 9y ago
I did follow the news about being remotely vulnerable. That's why I said I'd understand the urge to remove the networking stacks. Other vulnerabilities would require local access. > Why wouldn't you be interested in turning it off? I'm not asking why you'd be interested in it, I'm asking why you'd freak out so much about it given X/Y/Z are already true and you can't do anything about them. There's a bit more nuance in my argument than you're giving me credit for here. > And why would you classify people who'd rather not be running remotely vulnerable code they can't control as "privacy folks"? I already excluded the part about remote vulnerability. See first point above.
ksk 9y ago
> The ME is remotely vulnerable, Could you please post a link on that? I read about the AMT bugs, which require the user to manually provision it.
- macns 9y ago
  http://cve.circl.lu/cve/CVE-2017-5712 http://cve.circl.lu/cve/CVE-2017-5712 Summary: Buffer overflow in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allows attacker with remote Admin access to the system to execute arbitrary code with AMT execution privilege EDIT: I'm not sure this was the one the GP referring to
- cjbprime 9y ago
  I was thinking of: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5708 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5708