{"id":99320,"date":"2021-03-03T16:22:39","date_gmt":"2021-03-03T14:22:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2021-03-03T16:22:39","modified_gmt":"2021-03-03T14:22:39","slug":"trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Trudnoustawialne luki w GRUB2, umo\u017cliwiaj\u0105ce omini\u0119cie UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ods\u0142oni\u0119to informacje o 8 lukach w bootloaderze GRUB2, kt\u00f3re pozwalaj\u0105 na obej\u015bcie mechanizmu UEFI Secure Boot i uruchomienie niezweryfikowanego kodu, na przyk\u0142ad na wprowadzenie z\u0142o\u015bliwego oprogramowania dzia\u0142aj\u0105cego na poziomie bootloadera lub j\u0105dra. <\/p>\n

Przypomnijmy, \u017ce w wi\u0119kszo\u015bci dystrybucji Linuxa, dla zweryfikowanego uruchamiania w trybie UEFI Secure Boot u\u017cywana jest ma\u0142a warstwa shim, certyfikowana cyfrowym podpisem Microsoft. Ta warstwa weryfikuje GRUB2 swoim w\u0142asnym certyfikatem, co pozwala tw\u00f3rcom dystrybucji nie certyfikowa\u0107 ka\u017cdej aktualizacji j\u0105dra i GRUB w Microsoft. Luki w GRUB2 pozwalaj\u0105 na wykonanie w\u0142asnego kodu na etapie po pomy\u015blnej weryfikacji shim, ale przed za\u0142adowaniem systemu operacyjnego, wplataj\u0105c si\u0119 w \u0142a\u0144cuch zaufania przy aktywnym trybie Secure Boot i uzyskuj\u0105c pe\u0142n\u0105 kontrol\u0119 nad dalszym procesem uruchamiania, w tym za \u0142adowaniem innego systemu operacyjnego, modyfikacj\u0105 komponent\u00f3w systemu operacyjnego i obchodzeniem ochrony Lockdown. <\/p>\n

Podobnie jak w przypadku zesz\u0142orocznej luki BootHole, aby zablokowa\u0107 problem, nie wystarczy zaktualizowa\u0107 bootloadera, poniewa\u017c atakuj\u0105cy, niezale\u017cnie od u\u017cywanego systemu operacyjnego, mo\u017ce dla skompromitowania UEFI Secure Boot u\u017cy\u0107 no\u015bnika bootuj\u0105cego z starsz\u0105, podatn\u0105 wersj\u0105 GRUB2, certyfikowan\u0105 cyfrowym podpisem. Problem rozwi\u0105zuje si\u0119 tylko poprzez zaktualizowanie listy uniewa\u017cnionych certyfikat\u00f3w (dbx, UEFI Revocation List), ale w tym przypadku utracona zostanie mo\u017cliwo\u015b\u0107 korzystania ze starych no\u015bnik\u00f3w instalacyjnych z Linuksem. <\/p>\n

Na systemach z oprogramowaniem uk\u0142adowym, w kt\u00f3rym zaktualizowano list\u0119 uniewa\u017cnionych certyfikat\u00f3w, w trybie UEFI Secure Boot b\u0119dzie mo\u017cna za\u0142adowa\u0107 tylko zaktualizowane wersje dystrybucji Linuxa. Dystrybucje b\u0119d\u0105 musia\u0142y zaktualizowa\u0107 instalatory, bootloadery, pakiety j\u0105dra, firmware fwupd i warstw\u0119 shim, generuj\u0105c dla nich nowe cyfrowe podpisy. U\u017cytkownicy b\u0119d\u0105 musieli zaktualizowa\u0107 obrazy instalacyjne i inne no\u015bniki bootuj\u0105ce, a tak\u017ce za\u0142adowa\u0107 list\u0119 uniewa\u017cnionych certyfikat\u00f3w (dbx) do firmware UEFI. Dop\u00f3ki dbx nie zostanie zaktualizowane w UEFI, system pozostaje podatny niezale\u017cnie od zainstalowanych aktualizacji w systemie operacyjnym. Status usuni\u0119cia luk mo\u017cna oceni\u0107 na tych stronach: Ubuntu, SUSE, RHEL, Debian. <\/p>\n

Aby rozwi\u0105za\u0107 problemy zwi\u0105zane z dystrybucj\u0105 odwo\u0142anych certyfikat\u00f3w, w przysz\u0142o\u015bci planowane jest wykorzystanie mechanizmu SBAT (UEFI Secure Boot Advanced Targeting), kt\u00f3rego wsparcie zosta\u0142o zrealizowane dla GRUB2, shim i fwupd. Od nast\u0119pnych aktualizacji b\u0119dzie on u\u017cywany zamiast funkcjonalno\u015bci oferowanej przez pakiet dbxtool. SBAT zosta\u0142 opracowany wsp\u00f3lnie z Microsoftem i zak\u0142ada dodanie do plik\u00f3w wykonywalnych komponent\u00f3w UEFI nowych metadanych, kt\u00f3re zawieraj\u0105 informacje o producencie, produkcie, komponencie i wersji. Wskazane metadane s\u0105 podpisywane cyfrowo i mog\u0105 by\u0107 dodatkowo uwzgl\u0119dniane na listach dozwolonych lub zabronionych komponent\u00f3w dla UEFI Secure Boot. Dzi\u0119ki temu SBAT umo\u017cliwi manipulowanie numerami wersji komponent\u00f3w w przypadku ich odwo\u0142ania bez konieczno\u015bci regenerowania kluczy dla Secure Boot oraz bez tworzenia nowych podpis\u00f3w dla j\u0105dra, shim, grub2 i fwupd. <\/p>\n

Zidentyfikowane luki: <\/p>\n