Naprawiamy w kernelu lukę CVE-2016-0728

-
Tu i ówdzie pojawiają się alarmujące informacje o odkrytej luce 0-day w kernelu linuksa, która otrzymała oznaczenie CVE-2016-0728. W istocie jest to o tyle groźne, że odkrywcy luki udostępnili również gotowego exploita zezwalającego na atak. Patch jest już jednak gotowy i udostępniony również.
W Archu kernele dystrybucyjne zostały już zaktualizowane i nałożona została odpowiednia łatka. Należy zatem dokonać aktualizacji systemu. Problem może dotyczyć osób, które korzystają z kerneli spoza dystrybucji (różne repozytoria nieoficjalne, AUR) i ich kernel jest co najmniej w wersji 3.8. W takiej sytuacji należy sprawdzić, czy udostępniona została nowa wersja kernela, nakładająca łatkę. Różnie bywa nazywana, ale w PKGBUILDzie, w opisie powinno się  znaleźć informacja, że nakładany jest patch łatający CVE-2016-0728. Jeśli tego nie znajdziecie, bądź sami budujecie kernel, to należy wykonać następujące czynności (zakładam, że wszelkie czynności dokonujemy w katalogu ze skryptami budującymi kernel); oczywiście dla porządku można też zmienić na wyższy numer pkgrel, to akurat nie jest bezwzględnie konieczne):
1. Pozyskujemy patch
wget -c https://projects.archlinux.org/svntogit/packages.git/plain/trunk/CVE-2016-0728.patch?h=packages/linux -O CVE-2016-0728.patch
2, Dowolnym edytorem edytujemy PKGBUILD i wprowadzamy następujące zmiany:
a) w sekcji source dodajemy:
"CVE-2016-0728.patch"
b) w sekcji prepare dodajemy:
# Fix for CVE-2016-0728
msg "Fix CVE-2016-0728
patch -Np1 -i "${srcdir}/CVE-2016-0728.patch" 
3. Aktualizujemy sumy kontrolne:
updpkgsums
4. Budujemy kernel (i jak chcemy od razu go instalujemy/aktualizujemy):
makepkg -sirc
Dodatkowe operatory -rc dokonają wyczyszczenia katalogu po zbudowaniu i zainstalowaniu kernela.

Komentarze

  1. Lucjan20 stycznia 2016 05:05

    Wszystkie kernele które udostępniam w AUR oraz na Githubie mają zaaplikowany ten patch.

    OdpowiedzUsuń

Prześlij komentarz

Popularne posty z tego bloga

Brak możliwości aktualizacji lub instalacji pakietów - zablokowana baza

-
Arch oferuje doprawdy świetne narzędzie do obsługi pakietów. Niemniej jednak zbliża się już koniec drugiej dekady XXI w. i przyzwyczajenia użytkowników, czy też ich oczekiwania w zakresie jakiegoś prostego, graficznego menedżera paczek są duże i poniekąd można je uznać za uzasadnione. Tymczasem pacman czuje się jak ryba w wodzie wyłącznie w konsoli. Natura nie znosi próżni, stąd też już od dawna powstają takie graficzne menedżery. Ostanio - głównie za sprawą ich domyślnego instalowania w dystrybucjach pochodnych - popularność zyskały pamac oraz octopi. Oba te programy oferują, działające nieustannie w tle, małe narzędzia monitorujące możliwość aktualizacji pakietów. W ich konfiguracji można sobie zmienić częstotliwość aktualizacji. Jeśli nic nie zmienimy w systemie, to owe narzędzia zainstalują się wraz ze wspomnianymi menedżerami i ustawione będą (o ile pamiętam) na sprawdzanie aktualizacji raz dziennie. Zwykle oznacza to, że rozpoczynają swe działanie zaraz po pierwszym uruchomieniu
Czytaj więcej

Radzimy sobie z: GPG: odbiór z serwera kluczy nie powiódł się: brak dirmngr

-
Od dłuższego już czasu Arch wprowadził podpisywanie paczek kluczem gpg. W zasadzie wszystko winno przebiegać bezboleśnie nawet, gdy trzeba owe klucze dodać. Niestety zdarza się (mi się niegdyś zdarzyło), że próba dodania klucza GPG zwraca następujący błąd: sudo pacman-key -r ID_KEY gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: Wywołanie connect dla IPC nie powiodło się gpg: odbiór z serwera kluczy nie powiódł się: Brak dirmngr Na nic nie zdają się również "zwykłe" próby poradzenia sobie w takich przypadkach, jak: # pacman-key --init # pacman-key --refresh-keys # pacman-key --populate Dalej otrzymujemy powyższy błąd. Nic straconego. Prawdopodobnie wydanie następującej komendy: dirmngr < /dev/null && sudo -i dirmngr < /dev/null spowoduje, że po jej użyciu klucze będzie już można dodawać bez żadnych problemów.
Czytaj więcej

Przywracamy działanie drukarek w CUPS 2.3.0

-
Co najmniej wraz z nastaniem CUPS 2.3.0 (choć problemy zgłaszane były już w późnych wersjach serii 2.2.x) część (i to spora) drukarek odmówiła współpracy. Nie było też możliwości ich zainstalowania. Problem związany był ze zmianą dokonaną w CUPS polegającą na tym, że przestał on "przyjmować" te PPD (czyli ogólnie sterowniki drukarek), które miały wpisane "Custom" w różnych deklaracjach. Obecnie CUPS przyjmował tam "Other", a "Custom" powodowało, że drukarki stawały się tańszą lub droższą, niemniej jednak wyłącznie ozdobą naszych biur i domów. Sama zmiana dokonana w CUPS nie była zachcianką jego deweloperów, a powodowana była chęcią uniknięcia sygnalizowanego innego błędu powodującego wykrzaczanie się cupsd. I wszystko dobrze, ale spowodowała unieruchomienie znacznej ilości urządzeń. Problem nie dotyczy wyłącznie Archa i jego pochodnych, ale dotknął niemal wszystkich w miarę świeżych dystrybucji. Oczywiście owe PPD winny zostać przerobione prze
Czytaj więcej