Fun with CVE-2015-7575

15.2.2016 13:14 | Přečteno: 1505× | Linux | poslední úprava: 15.2.2016 13:14

Tak jsem se v praci dostal k security patchum na starsich LDAP serverech na Debianu Wheezy a mel o zabavu postarano.
Jeden z aplikovanych baliku byl libgnutls ve verzi 2.12.20-8+deb7u5. Jde o opravu bezpecnostni chyby CVE-2015-7575, ktera v zasade zacne ignorovat TLS extension pro vyber hashe, protoze se pres ni da vynutit MD5. Je dulezite, ze ta chyba se tyka pouze TLSv1.2.
Po restartu slapd se mi v logu zacaly misto uspesne replikace objevovat chyby:

Feb 15 11:41:27 ldap-a slapd[1028]: slap_client_connect: URI=ldap://ldap-b.moje.domena:389 Error, ldap_start_tls failed (-11)
Feb 15 11:41:27 office slapd[1028]: do_syncrepl: rid=001 rc -11 retrying

Fix nebo spis workaround spociva v pridani tls_cipher_suite="SECURE256:+VERS-TLS-ALL:-VERS-TLS1.2" do olcSyncrepl. Byla to celkem prdel, protoze dokumentace rika, ze se ten parametr jmenuje tls_ciphersuite a kdyz tu suitu nemate spravne, slapd pri startu segfaultuje.
Takze mam tri otazky do diskuze:

1. Je to podle vas chyba GNUTLS nebo OpenLDAPu?
2. Funguje to nekomu na Jessiem?
3. Komu se to chce reportovat?

       

Anketa

Komentáře

[Aleš Kapica]

Jessie je kočkopes. Nefunguje tam pořádně ani sysv-rc ani systemd a od toho se odvíjí i hromada dalších věcí. Unstable je v pohodě.

[trekker.dk]

Někdy si říkám, jestli se už všichni vývojáři nezbláznili... Jessie nemá corosync/pacemaker, protože se to nestihlo. DRBD je tam něco, čemu je lepší se při požadavku na vysokou spolehlivost vyhnout (možná je to rukama, ale drdbsetup občas na několik minut vytuhne ve stavu D v kernelu nebo hází chyby, pokud se na stejném stroji manipuluje s dvěma DRBD zařízeními naráz), o porušení zpětné kompatibility jádra s uživatelském prostorem ani nemluvě, init skripty programů nefungují správně a určitě bych si ještě na něco vzpomněl, kdybych se chtěl snažit.

Ale máme systemd. To je důležité.

[Aleš Kapica]

Ano. Proto si pro Pacemaker dělám vlastní deb balík, s kompilací založenou na gitu a místo DRBD již používám distribuované úložiště: pro soubory GlusterFS, který je v distribuci a pro bloková zařízení Sheepdog, který je sice také v distribuci ale v jakési prehistorické verzi. Ovšem na rozdíl od Cephu jeho kompilace a sestavení balíku není žádný monstrproces.

Jinak přesně tytéž problémy jsem měl s DRBD i já - problém je v blbě udělaném agentu pro Pacemaker od Linbitu.

[trekker.dk]

Hm, koukám, že Sheepdog má podporu přímo v Qemu, to jsem nevěděl. Já pokukoval po RBD, to by podporu v Qemu mělo mít taky.

Jinak přesně tytéž problémy jsem měl s DRBD i já - problém je v blbě udělaném agentu pro Pacemaker od Linbitu.

Není, na těch strojích, kde to blbne, ho nepoužívám - nemám dva uzly se stabilním DRBD úložištěm, ale hodně uzlů, kde se úložiště vytvářejí a propojují dle potřeby. Tj. přišlo mi zbytečné generovat konfiguraci, tak se místo toho prostě postupně volá drbdmeta a drbdsetup, kterými se to DRBD dostane do stavu, v jakém má být.

IMO je to bug v kernelu - je to vytuhlé v syscallu a v dmesgu hlášky "task hung for more than 120 seconds". A samozřejmě se to neprojevuje dost deterministicky na to, aby se to dalo dobře ladit.

[Aleš Kapica]

IMO je to bug v kernelu - je to vytuhlé v syscallu a v dmesgu hlášky "task hung for more than 120 seconds". A samozřejmě se to neprojevuje dost deterministicky na to, aby se to dalo dobře ladit.

Tak to nemohu vyloučit. Já měl původně dvě vzájemně nezávislá DRBD pole, v rámci pěti nodového asymetrického clusteru. A binec v tom dělal vždy jen ten agent. V současné době mám jedno DRBD pole (resp. dvě ale jsou v rámci jednoho dvounodového clusteru) a tam musím mít drbd v režimu unamanged, protože jakmile ten resource přepnu do stavu managed, tak mi všechno rozesere.

Přitom to DRBD normálně bez problémů běží v režimu Primary/Secondary. Jakmile se resource přepne do stavu managed, udělá mi z toho Slave/Slave a nazdar pipi. Poshazuje to závislé služby, protože ty pochopitelně čekají na Master a konečná. Nepomůže ani svěcená voda.

Jinak Sheepdog je ve srovnání s Ceph mnohem subtilnější cca 300MB pro kompilaci versus 20GB. Běží jako jeden výchozí proces, přes který se to i řídí, nepotřebuje extra metadata a funguje opravdu pěkně. Mám ho v kombinaci s GlusterFS. Pacemaker se mi stará jen o nahazování virtuálů. Budu o tom hovořit teď na Installfestu.

[Aleš Kapica]

Jinak tím že mám jedno pole, jsem nemyslel, že mám jen jedno, ale že mám jedno které takto zlobí.