W warstwie Shim, stosowanej w wi\u0119kszo\u015bci dystrybucji Linux do weryfikowanej bootowania w trybie UEFI Secure Boot, wykryto luk\u0119 (CVE-2023-40547), kt\u00f3ra mo\u017ce prowadzi\u0107 do zdalnego wykonania kodu oraz omini\u0119cia mechanizmu weryfikowanego bootowania UEFI Secure Boot. Napastnik, kontroluj\u0105cy serwer HTTP, do kt\u00f3rego odwo\u0142uje si\u0119 Shim, mo\u017ce zwr\u00f3ci\u0107 specjalnie sformatowan\u0105 odpowied\u017a, prowadz\u0105c\u0105 do kontrolowanego zapisu w obszarze poza buforem, co umo\u017cliwia wykonanie kodu na wczesnym etapie uruchamiania. <\/p>\n
Vulnerability is caused by an error in the HTTP file upload code, which manifests when processing incorrect responses returned by the HTTP server that the shim accesses. The HTTPBoot mode in Shim has been supported since 2016 and allows for network booting using the HTTP protocol to retrieve the file with the loader called at the next stage. When loading files via HTTP, Shim allocates a buffer for incoming data, considering not the actual size of the data, but the size indicated in the HTTP header 'Content-Length'. Accordingly, by returning a smaller value in the Content-Length header, it is possible to cause the tail of the request to be written to memory outside the buffer. <\/p>\n
Shim jest podpisany cyfrowo przez Microsoft i weryfikuje GRUB2 w\u0142asnym certyfikatem, co pozwala programistom dystrybucji nie podpisywa\u0107 ka\u017cdej aktualizacji j\u0105dra i GRUB w Microsoft. Luka w Shim daje mo\u017cliwo\u015b\u0107 wnikni\u0119cia w \u0142a\u0144cuch zaufania przy aktywnym trybie Secure Boot oraz uzyskania pe\u0142nej kontroli nad dalszym procesem uruchamiania, na przyk\u0142ad do uruchamiania innego systemu operacyjnego, modyfikacji komponent\u00f3w systemu operacyjnego oraz omini\u0119cia ochrony Lockdown. <\/p>\n
Luka zosta\u0142a usuni\u0119ta w wydaniu Shim 15.8, ale w celu ca\u0142kowitego zablokowania ataku przez Shim wymagane jest podpisanie nowej wersji przez Microsoft i wprowadzenie jej do dystrybucji. Status usuni\u0119cia luki w dystrybucjach mo\u017cna oceni\u0107 na tych stronach: Debian, Ubuntu, SUSE, RHEL, Fedora. Problem polega na tym, \u017ce bez odwo\u0142ania podpisu dla starej wersji poprawka jest bezsensowna, poniewa\u017c napastnik mo\u017ce do skompromitowania UEFI Secure Boot u\u017cy\u0107 no\u015bnika startowego z podatn\u0105 wersj\u0105 Shim. Jednak odwo\u0142anie podpisu doprowadzi do niemo\u017cno\u015bci weryfikowanego uruchamiania dystrybucji, kt\u00f3re nadal korzystaj\u0105 ze starej wersji Shim. <\/p>\n
Aby zablokowa\u0107 podatno\u015b\u0107 bez wycofywania cyfrowego podpisu, dystrybucje mog\u0105 wykorzysta\u0107 mechanizm SBAT (UEFI Secure Boot Advanced Targeting), kt\u00f3rego wsparcie zosta\u0142o wdro\u017cone dla GRUB2, shim i fwupd w wi\u0119kszo\u015bci popularnych dystrybucji Linux. SBAT zosta\u0142 zaprojektowany wsp\u00f3lnie z Microsoftem i zak\u0142ada dodanie do wykonywalnych plik\u00f3w komponent\u00f3w UEFI dodatkowych metadanych, kt\u00f3re zawieraj\u0105 informacje o producencie, produkcie, komponencie i wersji. Podane metadane s\u0105 podpisywane cyfrowym podpisem i mog\u0105 by\u0107 osobno do\u0142\u0105czane do list dozwolonych lub zabronionych komponent\u00f3w dla UEFI Secure Boot. <\/p>\n
SBAT umo\u017cliwia blokowanie u\u017cycia podpisu cyfrowego dla poszczeg\u00f3lnych numer\u00f3w wersji komponent\u00f3w bez potrzeby rezygnacji z kluczy do Secure Boot. Blokowanie luk bezpiecze\u0144stwa za pomoc\u0105 SBAT nie wymaga korzystania z listy uniewa\u017cnionych certyfikat\u00f3w UEFI (dbx) i odbywa si\u0119 na poziomie wymiany wewn\u0119trznego klucza do generowania podpis\u00f3w oraz aktualizacji GRUB2, shim i innych dostarczanych przez dystrybucje artefakt\u00f3w rozruchowych. <\/p>\n
Opr\u00f3cz omawianej luki w Shim 15.8 naprawiono r\u00f3wnie\u017c kilka mniej niebezpiecznych problem\u00f3w, wykorzystywanych lokalnie: <\/p>\n