Który kernel wybrać? Sprawdżcie u siebie kwestię zabezpieczenia przed Spectre i Meltdown

Kącik początkującego Podstawy
1

Dotychczas trzymałem się zasady, że przełączam się na wyższą wersję kernela dopiero, gdy dana wersja jest oznaczona jako LTS i jest większa niż 10-ta wersja danego jądra, zakładając, że wtedy już będzie stabilna.

W tym kontekście, od kilku miesięcy używałem kernela 6.12.

Jednak b. przydatny pakiet z AUR pokazał mi, że byłem w tym czasie wystawiony na potencjalną pastwę podatności Spectre v2. Poniższa komenda pokazała na czerwono, że mój system nie jest w pełni zabezpieczony przed zagrożeniem CVE-2017-5715.

sudo spectre-meltdown-checker

Pomocny CzatGPT zasugerował mi, że:

  1. Kernel 6.12 to eksperymentalna wersja LTS (tak zwane early LTS), nie w pełni przetestowana na wszystkich konfiguracjach - (co mnie trochę zaskoczyło, bo to już wersja 44 tego kernela)
  2. Kernel 6.6 to sprawdzona, stabilna, klasyczna wersja LTS,

I rzeczywiście pod kernelem 6.6 ta podatność u mnie nie występuje (co pokazała powyższa komenda).

Wniosek dla mnie (i sugestia dla Was) na przyszłość:

  • nie speszyć się z przejściem na wyższy kernel,
  • poczekać do trochę wyższej wersji
  • i koniecznie sprawdzić czy nowy kernel jest na pewno zabezpieczony przed Spectre, Meltdown i podobnymi.
2

Zasadnym wydaje się pytanie: Czy to ma jakikolwiek wpływ na bezpieczeństwo mojego domowego PC lub laptopa? Czy istnieją metody wykorzystania tych błędów w procesorach zdalnie? Jak? Poprzez Java Script umieszczony na złośliwych stronach www?
Ktoś coś?

3

No to lecimy:

ChatGPT opowiada bajki, nie ma czegoś takiego jak

Pomijając wersje przeznaczone dla developerów i nienadające się do codziennego użytku mamy:

RC (release candidate) → stable → LTS (long term support) → EOL (end of life)

W dokładnie takiej kolejności, przy czym RC można uznać za betę, stable – to zwykły stabilny kernel, LTS to kernel o przedłużonym wsparciu, staje się LTS dopiero w momencie gdy wyjdzie następny stabilny kernel (i tylko raz w roku). A EOL to kernel już po zakończeniu wsparcia – tego raczej nie powinieneś używać.

Z tym programikiem jest kilka problemów

  • nie był aktualizowany od roku
  • służy do wykrywania tylko paru możliwych luk – jak się pojawi nowa, nieznana luka to program (właściwie skrypcik w bashu) jej nie wykryje – ma zahardkodowane wybrane luki, więc bez aktualizacji nie wykryje nowych
  • nowy kernel, więc niektóre sprawdzane parametry mogły ulec zmianie i dać false positive – tu masz przykład takiej zmiany, która zaszła w 6.9

No i przede wszystkim są inne programiki, które pokażą to samo, chociażby chyba domyślnie preinstalowane inxi: inxi -Ca. Możesz też nie polegać na niczym i po prostu sprawdzić zawartość /sys/devices/system/cpu/vulnerabilities – kernel samo dostarcza wszystkie potrzebne informacje.

W teorii tak – przynajmniej wg Wikipedii – w praktyce jednak nie do końca, bo praktycznie wszystkie liczące się przeglądarki dokładają od siebie zabezpieczenia, które to uniemożliwiają :wink: A jeśli chodzi o inny soft – jesteś raczej bezpieczny, o ile korzystasz tylko z zaufanych źródeł, czyli przede wszystkim oficjalne repozytoria, a nie nieznane skrypty z sieci czy nikomu nieznane pakiety z AUR :stuck_out_tongue:

A co do kerneli – ja zawsze trzymam się zasady najnowszy stabilny + ostatni LTS jako backup – czyli w tym momencie działam na 6.16, a 6.12 mam gdyby z pierwszym coś się stało :wink:

3 polubienia
4

Zgadza się. Dobrze by było, gdyby developer to zaktualizował. Jednak i w takiej wersji, w przypadku mojego sprzętu, na dwóch komputerach, z różnymi procesorami (AMD i Intel) skrypt ten wskazuje na problem z zagrożeniem CVE-2017-5715 na kernelu 6.12 i braku tego problemu na kernelu 6.6.

Natomiast inxi -Ca dla obu tych komputerów i kerneli nie wskazuje zagrożenia.

Nie wchodząc w próbę odpowiedzi, czy ten skrypt, czy inxi prawdę mówi, bazując na moich priorytetach, którymi są stabilność i bezpieczeństwo wolę korzystać z mojego “zapasowego” kernela 6.6, niż stresować się potencjalnym zagrożeniem w 6.12 (a może to tylko false positive, a może nie?) .

Jeśli za jakiś czas skrypt spectre-meltdown-checker nie będzie dawał ostrzeżenia przy 6.12, to wtedy chętnie przejdę na tą wersję.

Co do nieznanych pakietów z AUR, to masz rację. Jednak wydaje mi się w przypadku tego dosyć popularnego pakietu/skrypty typu open source nie ma powodu do obaw.

5
  1. Raczej nie doczekasz się aktualizacji – pakiet w AUR był aktualizowany ponad 2 lata temu i instaluje konkretnie wersję 0.46 – nie uwzględnia ona choćby poprawek dla kerneli 6.9+ (wyszedł w maju 2024), o których wspominałem :wink:
  2. W tej kwestii bardziej ufałbym programom z oficjalnych repozytoriów (inxi) czy wręcz samemu kernelowi (/sys/devices/system/cpu/vulnerabilities) – w końcu on jest głównym i jedynym źródłem wszystkich skryptów i programów, które to sprawdzają
1 polubienie
6

Może i tak będzie.

Natomiast ja , pisząc wcześniej o czekaniu, rozważałem dwie opcje:

  • albo skrypt doczeka się aktualizacji (jeśli np. obecnie to on generuje false positive),
  • albo z nową wersją kernela 6.12 skrypt nie będzie sygnalizował zagrożenia CVE-2017-5715 ( jeśli obecnie problem leży w aktualnej wersji kernela 6.12).
7

Doczekał się już dawno temu - to pakiet w AUR nie został zaktualizowany :man_shrugging:

8

Z tego co widzę, w AUR jest najbardziej aktualny skrypt v46 (choć niestety sprzed 2 lat).

9

Jak wyjaśnisz to:

image
image1923×170 22.9 KB

Po lewej twoja wersja v46, po prawej najnowszy commit – v46 nie dość, że daje false positive to jeszcze sprawdza mniej luk :wink:

Poza tym (co też dobitnie pokazuje powyższy screen, a ja powtórzę to po raz trzeci – ten twój komunikat o podatności to false positive – problem jest znany i rozwiązany już rok temu, mniej więcej wtedy kiedy były ostatnie commity w repo. Dlaczego wtedy nie utworzono nowego release – nie mam pojęcia, pewnie zmiany były na tyle mało, że autor zdecydował się tego nie robić :man_shrugging:

Uporczywe trzymanie się czegoś, bo jakiś skrypt mówi, że jest niebezpiecznie, i to mimo tego, że problem jest od dawna znany, rozwiązanie także uważam za głupotę, a nie dbanie o własne bezpieczeństwo.

10

Gwoli ścisłości, nie ma żadnej “mojej” wersji, a jest jedynie ta dostępna w AUR.

To co pokazujesz, sugerowałoby, że wersja v46 pokazuje false positive.

Jednak z jakiegoś powodu ten commit nie został jeszcze uwzględniony przez developera skryptu (który, jak można sprawdzić, jest ciągle aktywny w innych wątkach na Github).

Widzę, że w AUR jest także pakiet spectre-meltdown-checker-git i jak się domyślam (po oszczędnym opisie) chyba zawiera on ten commit. (Być może nawet go pokazujesz po prawej stronie.) Może jutro go sprawdzę.

Jeśli ktoś ma odpowiednią wiedzę i jest w stanie ocenić treść tego commit, to może go zamiennie zastosować, w miejsce oficjalnej wersji. A jeśli komuś brakuje czasu lub wiedzy, to mimo wszytko wskazane jest czekanie. Prace na skryptem, choć się ślimaczą, trwają, co widać np. w podanych przez Ciebie linkach i datach postów (I nie nazywałbym tego głupotą).

11

Nie do końca – po prostu sklonowałem repo i odpaliłem skrypt raz z najnowszego commita, i raz po przełączeniu się na tag v0.46 – w tym naprawdę nie ma żadnej filozofii, same podstawy obsługi gita i uruchamiania bashowych skryptów.

Też bym się kłócił – skrypt robi 2 rzeczy – dostrzeżenie tego też wg mnie leży w kompetencji kogoś, kto zna podstawy basha

  1. jeśli masz w systemie sys/devices/system/cpu/vulnerabilities to po prostu robi grepa na wybranych plikach tym katalogu i ładny, kolorowy output
  2. jeśli tej ścieżki nie masz (a tu trzeba mieć bardzo stary kernel) to wtedy faktycznie robi trochę magii, którą może być ciężko rozszyfrować

Obie rzeczy to dosłownie kwestia poświęcenia max. 5 minut na analizę :wink:

1 polubienie
12

Dzięki za wyjaśnienie, w jaki sposób uzyskałaś wynik po prawej stronie na pokazanym wyżej rysunku.

Raz jeszcze gruntownie przeanalizowałem całość sprawy, co zajęło mi znacznie więcej niż 5 minut i tak:

1. Pakiet ten (w każdej wersji) umieszcza swój skrypt w pliku /usr/bin/spectre-meltdown-checker .

2. Skrypt z commit, użyty przez Ciebie, jest identyczny z tym instalowanym przez pakiet spectre-meltdown-checker-git z AUR.

3. Skrypt spectre-meltdown-checker z AUR (v.46) zawiera 6596 linii kodu, natomiast skrypt spectre-meltdown-checker-git zawiera 7436 linii kodu, gdzie 5756 linii jest pasujących, natomiast pozostałe 1680 linie kodu to są linie zmodyfikowane, dodane lub usunięte.

4. Nie podejmuję się, ani analizy tych zmian kodu, ani analizy żadnej z wersji tego skryptu, co - abstrahując od moich umiejętności - zajęłoby z pewnością znacznie więcej niż 5 minut.

5. Jeśli zaś chodzi o sam pakiet, to robi on znacznie więcej niż tylko odczytywanie wpisów z /sys/devices/system/cpu/vulnerabilities/ (odsyłam w tej kwestii do niezwykle pomocnych tu narzędziach AI w sieci).

Podsumowując, bazując na naszej dyskusji i znalezionych informacjach, wygląda na to, że można i należy zainstalować wersję spectre-meltdown-checker-git, która obecnie nie generuje fałszywych ostrzeżeń, w oczekiwaniu na pojawienie się nowej, zaktualizowanej wersji podstawowej w AUR.

Tym samym odwołuję podniesiony fałszywy alert i wracam do kernela 6.12.

Dzięki za twórczą dyskusję :wink: