Czy Ubuntu zazwyczaj publikuje aktualne aktualizacje zabezpieczeń?

Konkretny problem: pakiet Oneiric nginx jest w wersji 1.0.5-1, wydany w lipcu 2011 r. Zgodnie z dziennikiem zmian .

Luka pamięci niedawne ujawnienie ( strona doradcza , CVE-2012-1180 , DSA-2434-1 ) nie jest ustalona w 1.0.5-1. Jeśli nie mylę się ze stroną Ubuntu CVE, wszystkie wersje Ubuntu wydają się zawierać wrażliwy nginx.

1. Czy to prawda?

   Jeśli tak: Myślałem, że w Canonical jest zespół ds. Bezpieczeństwa, który aktywnie pracuje nad takimi problemami, więc spodziewałem się, że otrzymam aktualizację bezpieczeństwa w krótkim czasie (godziny lub dni) apt-get update.

2. Czy to oczekiwanie - że aktualizowanie moich pakietów jest wystarczające, aby powstrzymać mój serwer przed znanymi lukami - jest ogólnie błędne?

3. Jeśli tak: co powinienem zrobić, aby zapewnić bezpieczeństwo? Czytanie informacji o bezpieczeństwie Ubuntu nie pomogłoby w tym przypadku, ponieważ luka nginx nigdy nie została tam opublikowana.

Ubuntu jest obecnie podzielony na cztery składniki: główny, ograniczony, wszechświatowy i wieloświatowy. Pakiety w wersji głównej i ograniczonej są obsługiwane przez zespół ds. Bezpieczeństwa Ubuntu przez cały okres istnienia wersji Ubuntu, a pakiety we wszechświecie i na wielu urządzeniach są obsługiwane przez społeczność Ubuntu. Aby uzyskać więcej informacji, zobacz często zadawane pytania zespołu ds. Bezpieczeństwa .

Ponieważ nginx jest w składniku Wszechświata, nie otrzymuje aktualizacji od zespołu bezpieczeństwa. Do społeczności należy naprawa problemów związanych z bezpieczeństwem w tym pakiecie. Zobacz tutaj dokładnej procedury .

Możesz użyć Centrum oprogramowania lub ubuntu-support-statusnarzędzia wiersza poleceń, aby ustalić, które pakiety są oficjalnie obsługiwane i na jak długo.

Aktualizacja z przyszłości : Nginx przechodzi na main, więc w tym momencie otrzyma wsparcie od zespołu bezpieczeństwa Ubuntu. Jeśli nie masz pewności, czy Twoja wersja to zrobi, po prostu spójrz apt-cache show nginxi wyszukaj tag „Section”. Gdy jest to w Main, otrzymujesz wsparcie Canonical.

Pakiet nginx w ppa dla precyzyjnych jest na Version 1.1.17-2 uploaded on 2012-03-19.

Jeśli potrzebujesz łatek dla CVE, które są jeszcze w fazie kandydowania i nie zostały zaakceptowane, możesz rozważyć dodanie ppas .

O tym konkretnym pakiecie i błędzie oto kilka uwag ze śledzenia błędów pakietu .

Pakiety w głównym repozytorium Ubuntu są aktywnie aktualizowane przez Canonical. (Aby być częścią domyślnej instalacji, pakiet musi znajdować się w main.)

Jednak w przypadku pakietów takich jak nginx, które znajdują się w „wszechświecie”, nie spodziewałbym się terminowych aktualizacji zabezpieczeń. Wynika to z faktu, że pakiety te są utrzymywane przez wolontariuszy, a nie kanoniczne. Nie byłoby rozsądne oczekiwać, że Canonical będzie stale monitorował dziesiątki tysięcy pakietów istniejących we wszechświecie.

W przypadku pakietów opartych na dystrybucjach opartych na Debianie, takich jak Ubuntu, poprawki bezpieczeństwa są przenoszone z powrotem do bieżącej wersji. Wersje wersji nie są aktualizowane, ponieważ mogą wprowadzać niekompatybilne funkcje. Zamiast tego zespół ds. Bezpieczeństwa (lub opiekun pakietu) zastosuje poprawkę zabezpieczeń do bieżącej wersji i wyda poprawioną wersję.

1. Obecnie wdrażana wersja może być podatna na atak, ponieważ nie jest obsługiwana przez zespół ds. Bezpieczeństwa Ubuntu. Nie oznacza to, że jest podatny na ataki, ponieważ opiekun pakietu mógł go załatać. Sprawdź changelogw /usr/share/doc/nginxkatalogu, czy poprawka zabezpieczeń została przeniesiona. Jeśli nie, łatka może być w toku i będzie dostępna w wersji testowej.

2. Masz rację, zakładając, że aktualizowanie serwera znacznie skróci okres korzystania z niezabezpieczonego oprogramowania. Istnieją pakiety, które można skonfigurować do automatycznego pobierania i opcjonalnego instalowania aktualizacji. Mogą również powiadamiać, które łatki zostały zainstalowane lub są gotowe do instalacji.

3. W przypadku pakietów, które nie są obsługiwane przez zespół ds. Bezpieczeństwa, warto zwrócić uwagę na wszelkie zaległe problemy z bezpieczeństwem. Oceń ryzyko, ponieważ nie wszystkie luki można wykorzystać we wszystkich systemach. Niektóre mogą być zależne od konfiguracji lub wymagać lokalnego dostępu. Inne mogą nie być tak znaczące bez innych problemów, na przykład wykorzystanie warunków wyścigu do zastąpienia pliku z najlepszymi wynikami.