Ikke noe rart, ingen dramaer ... Men en annen er blitt oppdaget sårbarhet, CVE-2020-10713, som påvirker GRUB2 bootloader og Secure Boot. En publikasjon av Eclypsium-forskerteamet er den som har stått bak dette funnet og som de har kalt BootHole. Selv Microsoft har publisert en oppføring på sikkerhetsportalen, og advarer om den og hevder at det er en komplisert løsning for øyeblikket.
BootHole Det er et bufferoverløpssårbarhet som påvirker milliarder enheter med GRUB2 og til og med andre uten GRUB2 som bruker Secure Boot som Windows. I CVSS-systemklassifiseringen har den fått 8.2 av 10, noe som betyr at det er høy risiko. Og er det at en angriper kan dra nytte av dette for å kunne utføre vilkårlig kode (inkludert skadelig programvare) introdusert under oppstartsprosessen, selv med Secure Boot aktivert.
Så dispositivos nettverk, servere, arbeidsstasjoner, stasjonære og bærbare datamaskiner, så vel som andre enheter som SBC, visse mobile enheter, IoT-enheter, etc., vil bli berørt.
Videre, ifølge Eclypsium, vil det være komplisert å redusere og det vil ta tid å finne en løsning. Det vil kreve en dyp gjennomgang av bootloaders, og leverandører bør gi ut nye versjoner av bootloaders signert av UEFI CA. Samordnet innsats mellom utviklere i Microsoft open source og samarbeidsfellesskap og andre berørte systemeiere vil være pålagt å få ned BootHole.
De har faktisk laget en å gjøre listen for å kunne fikse BootHole i GRUB2 og du trenger:
- Plaster for å oppdatere GRUB2 og eliminere sårbarheten.
- At utviklerne av Linux-distribusjoner og andre leverandører slipper oppdateringene for brukerne sine. Både på nivået med GRUB2, installatører og shims.
- De nye shims må signeres av Microsoft UEFI CA for tredjeparter.
- Administratorer av operativsystemer vil åpenbart måtte oppdatere. Men det må inneholde både det installerte systemet, installasjonsbilder og også gjenopprettings- eller oppstartsmedier som de har opprettet.
- UEFI-tilbakekallingslisten (dbx) må også oppdateres i fastvaren til hvert berørte system for å forhindre kjøring av kode under oppstart.
Det verste er at når det gjelder firmware, må du være forsiktig og være forsiktig så du ikke får problemer og at datamaskinene blir værende i mursteinmodus.
For øyeblikket er selskaper som Red Hat, HP, Debian, SUSE, Canonical, Oracle, Microsoft, VMWare, Citrix, UEFI Security Response Team og OEM, samt programvareleverandører, de jobber allerede med å fikse det. Vi må imidlertid vente med å se de første oppdateringene.
OPPDATERING
Men å undervurdere effektiviteten til utviklerne og samfunnet ville være dumt. Allerede det er flere lappkandidater for å redusere det som kommer fra selskaper som Red Hat, Canonical, etc. De har markert dette problemet som topprioritet, og det lønner seg.
Problemet? Problemet er at disse oppdateringene forårsaker flere problemer. Det minner meg om hva som skjedde med Metldown og Spectre-lappene, at noen ganger er løsningen verre enn sykdommen ...