4 ms·

> Intel management engine and Computrace decedent features are not always removable Intel ME and Computrace have nothing to do with UEFI secureboot. > “chain

> Intel management engine and Computrace decedent features are not always removable Intel ME and Computrace have nothing to do with UEFI secureboot. > “chain of trust between firmware and OS” assumes physical security in logistics and co-locations is perfect Secureboot isn't just about physical security. It also (probably even more important) ensures malware can't modify anything in the chain of trust. Meaning malware can't backdoor the bootloader and in turn also can't install a rootkit in the kernel. If you would modify the binary of the bootloader or kernel their signatures would be modified. The firmware (ie. UEFI) won't load the bootloader anymore (because the signature check fails) and the bootloader (which verifies the kernel signature) won't boot the kernel.

Joel_Mckay 4y ago
Except there are already POC UEFI level rootkits that can't be detected by the host OS. Thus, such systems would appear to function normally to the common users, but offers zero benefit and may actually worsen the situation. Are you sure you are not confusing this with the TPM extensions? Again, one wrongly assumes a supplier hardware comes into a facility clean in the first place, and historically this process has already proven problematic to secure (Acer, Asus, Lenovo, CISCO etc.) ;-)
- jsiepkes 4y ago
  > Except there are already POC UEFI level rootkits that can't be detected by the host OS. I don't see how that changes anything? There are also HDD firmware hacks which can't be detected by the OS. Does that mean we should do away with filesystem security and permissions? You still have to hack the UEFI to get a rootkit in there. And yes, everything can get hacked. But that's not an excuse not to have security, is it? > Thus, such systems would appear to function normally to the common users, Secure boot changes nothing in that scenario. You can also hack the UEFI and install a root kit without the UEFI even supporting secure boot. > Again, one wrongly assumes a supplier hardware comes into a facility clean in the first place, If you find supply chain security important, then you should choose your supplier accordingly. That has nothing to do with secure boot.
  - Joel_Mckay 4y ago
    "then you should choose your supplier accordingly" Yes, choose the refurbished, quietly restocked, and or disgruntled worker malware for your CEO. If you sell out, than don't go halfway dude... but buy a SSD/HDD retail like a sane person. ;) "I don't see how that changes anything?" Well... Lenovo just patched 70 models for UEFI security issues, so some people see this a little differently. While I respect you opinion, it is irresponsible to frame blatant illegal product tying as a security feature. "Secure boot changes nothing in that scenario" We can agree it does nothing for security in most scenarios, and it is really weird some are so emotionally invested in convincing people otherwise. "we should do away with filesystem security and permissions?" While I appreciate the off-topic rhetoric, one needs to recognize the main issue I see is who holds the signing keys. Would you buy a car someone in the next town needs to unlock for you everyday, well apparently some people are that lame. I think we will have to agree to disagree on this issue =)
- ChrisLomont 4y ago
  >Except there are already POC UEFI level rootkits that can't be detected by the host OS. Is this more common or less common with a chain of trust built in? Existence is not a useful metric - rates are.
  - Joel_Mckay 4y ago
    "Is this more common or less common with a chain of trust built in?" False dilemma, my point was... when someone else holds the signing keys... there is no longer a real chain of trust. Thus, determining whether that someone else is intentionally evil or just grossly incompetent after detected incidents is an irrelevant thought exercise. Have a gloriously wonderful day. =)
    - ChrisLomont 4y ago
      >False dilemma It's not a false dilemma. If it provides better protection to the overall set of customers, then it may be a net benefit. No one had validates every virus signature and each line of code (or reverse engineers) in their virus scanner, yet those provide immense value to everyday users. This is no different - adding a feature that protects many users that are not sophisticated enough to manage their own CA, or that don't care to. >there is no longer a real chain of trust I trust a large security focused team to keep machines safe much more than I do the average PC owner or enterprise. If you personally need the trust of your own CA, simply put on in. Many people here (and on the original blog post) point out how easy it is to do.
      - Joel_Mckay 4y ago
        It seems Lenovo just patched 70 laptop models for the exact arbitrary silliness we have seen countless times before: https://www.securityweek.com/lenovo-patches-uefi-code-execution-vulnerability-affecting-many-laptops https://www.securityweek.com/lenovo-patches-uefi-code-execut... Enhance you calm... =)
        SideQuark 4y ago

Joel_Mckay 4y ago

Except there are already POC UEFI level rootkits that can't be detected by the host OS. Thus, such systems would appear to function normally to the common users, but offers zero benefit and may actually worsen the situation. Are you sure you are not confusing this with the TPM extensions? Again, one wrongly assumes a supplier hardware comes into a facility clean in the first place, and historically this process has already proven problematic to secure (Acer, Asus, Lenovo, CISCO etc.) ;-)

jsiepkes 4y ago
> Except there are already POC UEFI level rootkits that can't be detected by the host OS. I don't see how that changes anything? There are also HDD firmware hacks which can't be detected by the OS. Does that mean we should do away with filesystem security and permissions? You still have to hack the UEFI to get a rootkit in there. And yes, everything can get hacked. But that's not an excuse not to have security, is it? > Thus, such systems would appear to function normally to the common users, Secure boot changes nothing in that scenario. You can also hack the UEFI and install a root kit without the UEFI even supporting secure boot. > Again, one wrongly assumes a supplier hardware comes into a facility clean in the first place, If you find supply chain security important, then you should choose your supplier accordingly. That has nothing to do with secure boot.
- Joel_Mckay 4y ago
  "then you should choose your supplier accordingly" Yes, choose the refurbished, quietly restocked, and or disgruntled worker malware for your CEO. If you sell out, than don't go halfway dude... but buy a SSD/HDD retail like a sane person. ;) "I don't see how that changes anything?" Well... Lenovo just patched 70 models for UEFI security issues, so some people see this a little differently. While I respect you opinion, it is irresponsible to frame blatant illegal product tying as a security feature. "Secure boot changes nothing in that scenario" We can agree it does nothing for security in most scenarios, and it is really weird some are so emotionally invested in convincing people otherwise. "we should do away with filesystem security and permissions?" While I appreciate the off-topic rhetoric, one needs to recognize the main issue I see is who holds the signing keys. Would you buy a car someone in the next town needs to unlock for you everyday, well apparently some people are that lame. I think we will have to agree to disagree on this issue =)
ChrisLomont 4y ago
>Except there are already POC UEFI level rootkits that can't be detected by the host OS. Is this more common or less common with a chain of trust built in? Existence is not a useful metric - rates are.
- Joel_Mckay 4y ago
  "Is this more common or less common with a chain of trust built in?" False dilemma, my point was... when someone else holds the signing keys... there is no longer a real chain of trust. Thus, determining whether that someone else is intentionally evil or just grossly incompetent after detected incidents is an irrelevant thought exercise. Have a gloriously wonderful day. =)
  - ChrisLomont 4y ago
    >False dilemma It's not a false dilemma. If it provides better protection to the overall set of customers, then it may be a net benefit. No one had validates every virus signature and each line of code (or reverse engineers) in their virus scanner, yet those provide immense value to everyday users. This is no different - adding a feature that protects many users that are not sophisticated enough to manage their own CA, or that don't care to. >there is no longer a real chain of trust I trust a large security focused team to keep machines safe much more than I do the average PC owner or enterprise. If you personally need the trust of your own CA, simply put on in. Many people here (and on the original blog post) point out how easy it is to do.
    - Joel_Mckay 4y ago
      It seems Lenovo just patched 70 laptop models for the exact arbitrary silliness we have seen countless times before: https://www.securityweek.com/lenovo-patches-uefi-code-execution-vulnerability-affecting-many-laptops https://www.securityweek.com/lenovo-patches-uefi-code-execut... Enhance you calm... =)
      - SideQuark 4y ago