Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


BootHole vulnerability that is more than just Intel
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

BootHole vulnerability that is more than just Intel

It's been a while since we have had vulnerabilities that's not just Intel:

https://ubuntu.com/blog/mitigating-boothole-theres-a-hole-in-the-boot-cve-2020-10713-and-related-vulnerabilities

Thanked by 1AlwaysSkint

Comments

  • Caused by MS UEFI - fanbois take note.

    Thanked by 1bugrakoc
  • TimboJonesTimboJones Member
    edited July 2020

    @AlwaysSkint said:
    Caused by MS UEFI - fanbois take note.

    Did you read the link whatsoever? Your comment is almost nonsensical.

    This provided a total of 8 vulnerabilities which then needed to be patched across the various Ubuntu releases of GRUB2 to fix these issues on existing systems.

    All operating systems using GRUB2 with Secure Boot must release new installers and bootloaders.

  • jsgjsg Member, Resident Benchmarker
    edited July 2020

    @poisson said:
    It's been a while since we have had vulnerabilities that's not just Intel:

    https://ubuntu.com/blog/mitigating-boothole-theres-a-hole-in-the-boot-cve-2020-10713-and-related-vulnerabilities

    Well, I always considered grub as cancerous and mindlessly make-shifted,especially grub2.
    While for the sake of fairness one must also see that the original cause/driver behind the mess was some large corporations force-feeding (U)EFI to us, the effective cause wrt grub was the usual mindless bazaar "engineering" of the linux people who just couldn't resist to use the opportunity to cram a sh_tload of modernity into their response/"solution" grub.

    But don't worry, there will be more creepy problems. The fertility of grub isn't exhausted by far. Oh, and be sure to use the newest linux version band-aid! (LOL)

    Thanked by 2AlwaysSkint bugrakoc
  • @TimboJones said:

    @AlwaysSkint said:
    Caused by MS UEFI - fanbois take note.

    Did you read the link whatsoever? Your comment is almost nonsensical.

    This provided a total of 8 vulnerabilities which then needed to be patched across the various Ubuntu releases of GRUB2 to fix these issues on existing systems.

    All operating systems using GRUB2 with Secure Boot must release new installers and bootloaders.

    Yes, I did and @jsg has kindly spelled it out for you a bit further. Can you possibly think which company wouldn't want you to easily boot into a different OS, by enforcing secure boot?

    Thanked by 1bugrakoc
  • hzrhzr Member

    @AlwaysSkint said: Yes, I did and @jsg has kindly spelled it out for you a bit further. Can you possibly think which company wouldn't want you to easily boot into a different OS, by enforcing secure boot?

    RHEL probably, can't think of any others

  • jsgjsg Member, Resident Benchmarker
    edited July 2020

    @AlwaysSkint said:
    Yes, I did and @jsg has kindly spelled it out for you a bit further. Can you possibly think which company wouldn't want you to easily boot into a different OS, by enforcing secure boot?

    Thanks for your reference, but actually @TimboJones isn't wrong either. Microsoft (U)EFI was the (initial) cause but wrt the topic it was grub, not MS, who f_cked up.
    And btw, if one looks for culprits one must also see that MS couldn't pull off the (U)EFI operation alone. It only worked because most in the hardware segment obediently played along.

    I'm certainly no MS fan, quite the contrary, but in this case while they played an initial role they are not the guilty party.

    Being at that we also need to note that MS has become much better re. safety/security while linux often is rather ignorant. If windows didn't have a market share next to which linux market share is all but insignificant, I guess Windows would actually be the safer choice today. Or in other words, if linux were attacked as frequently and massively by as massive an array of evil players, it would look considerably worse than Windows.

  • hzrhzr Member

    @jsg said: Being at that we also need to note that MS has become much better re. safety/security while linux often is rather ignorant. If windows didn't have a market share next to which linux market share is all but insignificant, I guess Windows would actually be the safer choice today. Or in other words, if linux were attacked as frequently and massively by as massive an array of evil players, it would look considerably worse than Windows.

    This is why I only run enterprise-supported RHEL, it isn't hole-ridden like the f/oss kind.

    @jsg said: It only worked because most in the hardware segment obediently played along.

    I'm wondering what other options there are to enable some form of secure boot equivalent but not controlled by any particular software or hardware company.

  • jsgjsg Member, Resident Benchmarker

    @hzr said:
    This is why I only run enterprise-supported RHEL, it isn't hole-ridden like the f/oss kind.

    IMO the major problem is not foss but rather bazaar vs. cathedral (with most companies naturally being very close to the cathedral). One can create safe and secure foss software and it has occasionally been done. Similarly one can create sh_tty software in the cathedral camp as many, many examples show.

    I'm wondering what other options there are to enable some form of secure boot equivalent but not controlled by any particular software or hardware company.

    Reasonable standards based on solid understanding, knowledge, and expertise in the field seems to be a good vector. Good and relevant example wrt (U)EFI: Have the user decide whom he trusts (by chosing which signed loaders he accepts) plus have stringent and solid standard for getting into the selection of candidates.

  • asasdasasd Member

    Pro tip of the day

    Less code, less attack surface. Just remove grub2 and use systemd-boot. I know you all use an os with systemd already... :)

Sign In or Register to comment.