Nowe posty

xx Dystrybucja pod HP Omen (6)
Wczoraj o 23:30:08
xx [Poradnik] Wyszukiwanie Sterowników (2)
Wczoraj o 21:08:23
lamp Problem z Linux Lite po instalacji (0)
Wczoraj o 19:50:30
xx Ile pingwinów? (1)
Wczoraj o 08:59:24
xx konfiguracja pale moon (0)
2024-03-24, 21:53:42
xx Plasma 6 w Neonie ssie trochę mniej ... (10)
2024-03-23, 02:38:11
xx problem z instalacja sterowników do karty sieciowej (3)
2024-03-18, 18:10:16
xx Plik abc.001 (1)
2024-03-17, 17:48:27
xx Zlecę dopracowanie programu w MatLab (0)
2024-03-13, 15:28:40
xx Linux Mint 21.3 XFCE brak dźwieku po paru minutach (karta muzyczna zintegrowana) (5)
2024-03-12, 23:07:01

Autor Wątek: Włamanie na kernel.org - trwa sprawdzanie kodu żródłowego jądra.  (Przeczytany 3953 razy)

Offline Andrzej J

  • Users
  • Guru
  • *****
  • Wiadomości: 713
    • Zobacz profil
Przed chwilą czytałem o włamaniu na serwer Hera na kernel.org. Profilaktycznie chyba lepiej powstrzymać się z pobieraniem kerneli z tej strony. Trwa sprawdzanie kodu źródłowego. Wiecej na kernel.org

ra-v

  • Gość
Włamanie na kernel.org - trwa sprawdzanie kodu żródłowego jądra.
« Odpowiedź #1 dnia: 2011-09-01, 23:36:56 »
Może zapomnieli zaktualizować jądra... :->

  • Gość
Włamanie na kernel.org - trwa sprawdzanie kodu żródłowego jądra.
« Odpowiedź #2 dnia: 2011-09-02, 23:42:01 »
Mnie zastanawia taka kwestia. Ta infekcja miała podobno miejsce nie później niż 12 sierpnia. Odkryta została 17 dni później - 28 sierpnia. Na prywatnym komputerze jednego z deweloperów znaleziono trojana. Później okazało się, że również na serwerach Hera oraz Odin1 sytuacja wygląda podobnie. Pierwsze oznaki "kompromitacji" związane były z błędami Xnest na komputerze bez zainstalowanego serwera X Window.

Orientuje się ktoś czy podczas aktualizacji (np. yum, apt-get, etc) kernela, w pierwszej kolejności jest on pobierany z kernel.org, nakładane są łaty i dopiero póżniej ląduje w rezpozytoriach dystrybucyjnych? Czy jest zupełnie inczej np: dystrybucja X wydaje kilka tygodni przed tym zajściem kolejną, stabilną wersję z kernelem 2.6.32, i wszelkie znalezione dziury, nowe funkcje są dodawane tylko i wyłącznie na tym jajku, bez potrzeby ściągania żródeł z kernel,org?

Wydaje się, że w większości korzystają z tej strony ludzie chcący pobrać najnowsze kernele, w różnych celach poznawczo-testowych. Jeżeli były jakiekolwiek aktualizacje w czasie tych 17-stu dni to może być nieciekawie.

Pocieszające wydają się wypowiedzi:  "For each of the nearly 40,000 files in the Linux kernel, a cryptographically secure SHA-1 hash is calculated to uniquely define the exact contents of that file,” the statement explained. “Once it is published, it is not possible to change the old versions without it being noticed.”
“The Linux community and kernel.org take the security of the kernel.org domain extremely seriously, and are pursuing all avenues to investigate this attack and prevent future ones,” Wednesday's statement said.

  • Gość
Włamanie na kernel.org - trwa sprawdzanie kodu żródłowego jądra.
« Odpowiedź #3 dnia: 2011-09-03, 11:03:37 »
Cytat: plomyk
Orientuje się ktoś czy podczas aktualizacji (np. yum, apt-get, etc) kernela, w pierwszej kolejności jest on pobierany z kernel.org, nakładane są łaty i dopiero póżniej ląduje w rezpozytoriach dystrybucyjnych? Czy jest zupełnie inczej np: dystrybucja X wydaje kilka tygodni przed tym zajściem kolejną, stabilną wersję z kernelem 2.6.32, i wszelkie znalezione dziury, nowe funkcje są dodawane tylko i wyłącznie na tym jajku, bez potrzeby ściągania żródeł z kernel,org?
Zależy od dystrybucji. Na Debianie źródła mają z gita.

W Debianie nowe wersje pakietu (ze zwiększonym numerem oznaczającym Debian revision) są tworzone na podstawie źródeł (plik z nazwą zakończoną na .orig.tar.gz) z dodanymi łatkami dystrybucyjnymi. Plik z oryginalnymi źródłami znajduje się w infrastrukturze Debiana, więc pobieranie nowej wersji upstream przy wydawaniu nowej wersji binarnej wydaje mi się cokolwiek niepotrzebne.

  • Gość
Włamanie na kernel.org - trwa sprawdzanie kodu żródłowego jądra.
« Odpowiedź #4 dnia: 2011-09-03, 13:09:59 »
Tak, wygląda na to, że ze względu na git nie powinno być większych problemów spowodowanych tym incydentem.