{"id":182443,"date":"2026-07-02T22:53:28","date_gmt":"2026-07-02T20:53:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim"},"modified":"2026-07-02T22:53:28","modified_gmt":"2026-07-02T20:53:29","slug":"problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim","title":{"rendered":"Problemy z czyszczeniem kluczy szyfrowania dysku z RAM podczas przechodzenia systemu Linux w tryb u\u015bpienia","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Podczas portowania narz\u0119dzia cryptsetup-suspend dla NixOS zidentyfikowano b\u0142\u0105d w podsystemie szyfrowania dysk\u00f3w LUKS (Linux Unified Key Setup), kt\u00f3ry spowodowa\u0142, \u017ce od czasu wprowadzenia j\u0105dra Linux 6.9 (problemowy commit), wydanego w maju 2024 roku, usuwanie kluczy szyfrowania z pami\u0119ci RAM przesta\u0142o dzia\u0142a\u0107 przy przechodzeniu systemu w tryb u\u015bpienia. <\/p>\n
Narz\u0119dzie cryptsetup-suspend jest u\u017cywane w Debianie do automatycznego blokowania partycji LUKS przed przej\u015bciem w stan u\u015bpienia. Zak\u0142ada si\u0119, \u017ce w przypadku kradzie\u017cy laptopa w trybie u\u015bpienia, przest\u0119pca nie b\u0119dzie mia\u0142 mo\u017cliwo\u015bci uzyskania dost\u0119pu do danych, poniewa\u017c po wybudzeniu z u\u015bpienia b\u0119dzie wymagane wprowadzenie has\u0142a w celu odzyskania dost\u0119pu do zaszyfrowanych danych. Z powodu b\u0142\u0119du w j\u0105drze Linuxa po zablokowaniu partycji LUKS poleceniem \u00abcryptsetup luksSuspend\u00bb klucze nie by\u0142y usuwane z pami\u0119ci RAM i pozostawa\u0142y widoczne przez \/proc\/keys, co pozwala\u0142o atakuj\u0105cemu wyci\u0105gn\u0105\u0107 je na przyk\u0142ad poprzez metod\u0119 \u00abzimnego restartu\u00bb, i u\u017cy\u0107 do uzyskania dost\u0119pu do danych. <\/p>\n
Brak usuni\u0119cia kluczy zosta\u0142 wykryty podczas debugowania stanu wy\u015bcigu, co powodowa\u0142o problemy z przej\u015bciem w tryb u\u015bpienia. B\u0142\u0105d pojawi\u0142 si\u0119 po dokonaniu refaktoryzacji w j\u0105drze 6.9, w wyniku kt\u00f3rej klucze by\u0142y powi\u0105zane z w\u0105tkiem wywo\u0142uj\u0105cym i mia\u0142y by\u0107 usuwane po jego zako\u0144czeniu, ale w rzeczywisto\u015bci pozostawa\u0142y w pami\u0119ci. Proponowany jest jednowierszowy patch do j\u0105dra Linux, kt\u00f3ry eliminuje ten b\u0142\u0105d. <\/p>\n
Zg\u0142oszona poprawka nie zosta\u0142a zaakceptowana do j\u0105dra, poniewa\u017c wykryto w niej niedor\u00f3bk\u0119 \u2014 poprawka dzia\u0142a tylko dla fizycznych no\u015bnik\u00f3w, ale nie dzia\u0142a dla wirtualnych urz\u0105dze\u0144 loop. Zamiast naprawi\u0107 problem po stronie j\u0105dra, zesp\u00f3\u0142 odpowiedzialny za narz\u0119dzie cryptsetup zaproponowa\u0142 obej\u015bcie, kt\u00f3re pozwala na usuni\u0119cie kluczy. Ta zmiana zosta\u0142a ju\u017c zaakceptowana i wejdzie w sk\u0142ad wydania cryptsetup 2.8.7. <\/p>\n
Ponadto dla NixOS stworzono w\u0142asn\u0105 implementacj\u0119 skrypt\u00f3w do blokowania szyfrowanych dysk\u00f3w przed przej\u015bciem w tryb u\u015bpienia, w kt\u00f3rej wykorzystany jest stary patch do j\u0105dra, nieprzyj\u0119ty w 2015 roku, wymuszaj\u0105cy usuwanie kluczy z pami\u0119ci przed przej\u015bciem w tryb u\u015bpienia. \n \u0179r\u00f3d\u0142o: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"