Dlaczego aktualizacje nienadzorowane nie naprawiają błędu serca?

Postępowałem zgodnie z instrukcjami, aby zainstalować aktualizacje nienadzorowane, aby zainstalować automatyczne aktualizacje zabezpieczeń na moim serwerze (serwer Ubuntu 13.10).

https://help.ubuntu.com/community/AutomaticSecurityUpdates

Czy możesz mi pomóc zrozumieć, dlaczego dziś rano wciąż mam na sercu błąd związany z sercem?

$ openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Wed Jan  8 20:58:47 UTC 2014
platform: debian-amd64

inne informacje:

$ cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

$ cat /var/log/apt/history.log
....
Start-Date: 2014-04-03  15:33:59
Commandline: apt-get install nginx
Install: libxau6:amd64 (1.0.8-1, automatic), libx11-data:amd64 (1.6.1-1ubuntu1, automatic), libxcb1:amd64 (1.9.1-3ubuntu1, automatic), libvpx1:amd64 (1.2.0-2, automatic), libgd3:amd64 (2.1.0-2, automatic), libxdmcp6:amd64 (1.1.1-1, automatic), libxslt1.1:amd64 (1.1.28-2, automatic), nginx-common:amd64 (1.4.1-3ubuntu1.3, automatic), nginx:amd64 (1.4.1-3ubuntu1.3), nginx-full:amd64 (1.4.1-3ubuntu1.3, automatic), libx11-6:amd64 (1.6.1-1ubuntu1, automatic), libxpm4:amd64 (3.5.10-1, automatic)
End-Date: 2014-04-03  15:34:02

Start-Date: 2014-04-04  10:26:38
Commandline: apt-get install unattended-upgrades
Install: unattended-upgrades:amd64 (0.79.3ubuntu8)
End-Date: 2014-04-04  10:26:40

Dziękuję Ci

Na serwerze nie ma luki Heartbleed, OpenSSL został załatany, aby naprawić ten problem (bez aktualizacji).

W danych wyjściowych wersji OpenSSL pominięto kilka ważnych wierszy, dzięki czemu wiesz, że zostało załatane, a nie numer wersji:

openssl version -a                                                                ✭
OpenSSL 1.0.1e 11 Feb 2013
built on: Mon Apr  7 20:33:19 UTC 2014
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

Liczy się linia „buduj dalej”, 7 kwietnia lub później: jesteś dobry. W przeciwnym razie: masz kłopoty.

Aktualizacja, ponieważ data kompilacji nie wydaje się być dobra:

Być może aktualizacja nienadzorowana jeszcze się nie uruchomiła, na moim serwerze skrypty w cron.daily są skonfigurowane do działania o 6:25

25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Sprawdź także zawartość /etc/apt/apt.conf.d/10periodic i sprawdź, czy są zainstalowane aktualizacje zabezpieczeń:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

Źródło: https://help.ubuntu.com/lts/serverguide/automatic-updates.html

Najpierw musisz wykonać aktualizację. Aktualizacje nienadzorowane są uruchamiane tylko raz dziennie, a od czasu wprowadzenia poprawki upłynął mniej niż 1 dzień (2014-04-07 około 20:00 GMT). Dla pyskaty, upewnij się, że uaktualniłeś do libssl1.0.0wersji 1.0.1e-3ubuntu1.2 lub nowszej. (Dokładnie, poprawka pojawiła się w wersji 1.0.1-4ubuntu5.12.)

Następnie zauważ, że jest to bardzo zła podatność: mogła umożliwić atakującym uzyskanie poufnych danych przez połączenie się z twoim podatnym na atak serwerem. Jeśli korzystasz z serwera SSL, wszelkie dane, które były w pamięci serwera od czasu przed ogłoszeniem podatności, mogły zostać wyciekły. Dotyczy to w szczególności klucza prywatnego SSL serwera, dlatego należy wygenerować nowy i odwołać stary.

Aby uzyskać więcej informacji, zobacz Jak naprawić błąd Heartbleed (CVE-2014-0160) w OpenSSL?

Nie możesz ufać ciągom wersji wewnętrznej. Wersja mówi, 1.0.1ea błąd dotyczy od 1.0.0 do 1.0.0f. Czy to wystarczy, aby ustalić, czy nadal masz podatną na atak wersję openssl? Nie. Wewnętrzna wersja OpenSSL nie zmienia się, nawet po zastosowaniu niektórych aktualizacji. Jedynym sposobem na niezawodną identyfikację wersji jest sprawdzenie wersji menedżera pakietów za pomocą apt-cache policylub innego narzędzia:

➜  ~  apt-cache policy openssl
openssl:
  Installed: 1.0.1f-1
  Candidate: 1.0.1f-1
  Version table:
 *** 1.0.1f-1 0
        500 http://http.debian.net/debian/ testing/main i386 Packages
        100 /var/lib/dpkg/status
➜  ~  dpkg -l openssl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  openssl        1.0.1f-1     i386         Secure Sockets Layer toolkit - cr
➜  ~  

Jak widać, moja wersja openssl jest lepsza, wydaje się, że ma to wpływ na, ponieważ jest to wersja 1.0.1f, teraz jeśli sprawdzę dzienniki zmian:

➜  ~ apt-get changelog openssl
openssl (1.0.1f-1) unstable; urgency=high

  * New upstream version
    - Fix for TLS record tampering bug CVE-2013-4353
    - Drop the snapshot patch
  * update watch file to check for upstream signature and add upstream pgp key.
  * Drop conflicts against openssh since we now on a released version again.

 -- Kurt Roeckx <kurt@roeckx.be>  Mon, 06 Jan 2014 18:50:54 +0100

Tak, nadal jestem pod wrażeniem. W dzienniku zmian nie ma odniesienia do CVE-2014-0160. Ale nie korzystam z żadnej usługi SSL / TSL, więc mogę poczekać. Po prostu nie muszę generować certyfikatów SSL przy użyciu tej wersji OpenSSL. Jeśli to zrobię, muszę tylko postępować zgodnie z radą Gillesa: zdjąć usługi, unieważnić certyfikat, wygenerować nowe.