Závažná bezpečnostní chyba v OpenSSL

Byla nalezena závažná bezpečnostní chyba v kryptografické knihovně OpenSSL. Heartbleed Bug se týká verze 1.0.1 a umožňuje útočníkovi získat přistup k paměti připojeného serveru nebo klienta a tím pádem k veškerým zpracovávaným informacím (soukromé klíče, certifikáty, jména, hesla, maily, dokumenty). Verze 1.0.1 vyšla v březnu 2012. Chyba CVE-2014-0160 byla opravena včera vydáním verze 1.0.1g (bezpečnostní upozornění). Jedná se o programátorskou chybu v implementaci rozšíření TLS Heartbeat. Diskuse například na Hacker News nebo Slashdot.

8.4.2014 05:36 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[jc]

Potes koste.

[gsnak]

kurvadrat nelinkujte na betu

[Ladislav Hagara]

Dík, opraveno.
Pro návrat zpět http://slashdot.org/?nobeta=1.

[Lol Phirae]

Co to furt meleš s tou betou?

[pavlix]

Odkaz na beta verzi slashdotu, pokud správně chápu.

[Šangala]

Ještě že jedu na oldstable Debian-u :).

[Andrej]

Tak to je rozhodně obrovská výhra.

[Šangala]

Článek se týká jakékoliv distribuce

[reb]

To samozřejmě ne, některých se naštěstí netýká

[Jendа]

Jaké třeba? Rád bych takovou používal. A na jakém počítači ji mám spouštět?

[pavlix]

...he discussed how UNIX-like systems like Debian...

Nezdůrazňoval jsi náhodou nedávno v diskuzi, že nejsi žádný fanatik?

[H0ax]

slušnej průduch:
"We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."

mimochodem dneska ráno:
yum update
HTTPS Error 503 - Service Unavailable

už to začíná

[Šangala]

Vyjelo mi:

openssl  x86_64 1.0.1e-16.el6_5.7  updates  1.5 M

[Ja]

ChangeLog for: openssl-1.0.1e-16.el6_5.7.i686, openssl-devel-1.0.1e-16.el6_5.7.i686
* Mon Apr  7 14:00:00 2014 Tomáš Mráz < tmraz@redhat.com > 1.0.1e-16.7
- fix CVE-2014-0160 - information disclosure in TLS heartbeat extension

[LukynZ]

<paranoid>Programatorska chyba, nebo dobre zaplacena chyba "programatora"?</paranoid>

[Jendа]

Zas tak moc dobře mi za to nezaplatili.

[Mike]

Takže každý teď může realisticky předpokládat, že NSA má komplet databázi všech privátních SSL klíčů na Internetu

Kdo teď okamžitě neregeneruje veškeré SSL klíče na svých serverech (kde byla OpenSSL 1.0.1) je s prominutím idiot.

[little.owl]

+1

[Sid]

Podla toho clanku nie je uplne iste ze sa kluc zrovna trafil do tych 64KB? V niektorych pripadoch to tak moze byt ale obecne asi nie? Ci sa mylim?

[Jendа]

Prej to je 64 KiB v jedné session, ale útočník se může ptát znovu a znovu, dokud nepřečte celou paměť.

[R]

Celu pamat? Utocnik nemoze ovplyvnit, ktorych 64 KB dostane.

[Jendа]

Aha, OK. Nevím o tom víc než tohle.

[Bystroushaak]

To sice nemůže, ale pořád toho dostává hodně. Opravdu hodně. Včetně například výpisu http komunikace právě připojených klientů.

./hb-test-proxy.py censored.eu
Connecting...
Sending Client Hello...
Waiting for Server Hello...
 ... received message: type = 22, ver = 0302, length = 58
 ... received message: type = 22, ver = 0302, length = 3644
 ... received message: type = 22, ver = 0302, length = 525
 ... received message: type = 22, ver = 0302, length = 4
Sending heartbeat request...
 ... received message: type = 24, ver = 0302, length = 16384
Received heartbeat response:
@SC[���x
        �
         �+��H�Ͻ9
���w3f�
�"�!98����6���
        2��ED��/�A��
                     �I

42


#text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
Referer: https://censored/index.php?page=dashboard
Accept-Encoding: gzip,deflate,sdch
Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: selectedcurrency=usd; usdperiod=Day; hashrate=90000; coincalc[0]=doge; coincalc[1]=fst; coincalc[2]=ltc; coincalc[3]=mec; coincalc[4]=wdc; __utma=43463865.381303622.1388356898.1396383387.1396897075.25; __utmc=43463865; __utmz=43463865.1396897075.25.14.utmcsr=chat.censored|utmccn=(referral)|utmcmd=referral|utmcct=/index.php; _ga=GA1.2.381303622.1388356898; PHPSESSID=0s9fq93njadcqgmfntmdrho6e3

6
 h7
���z
WARNING: server returned more data than it should - server is vulnerable!

[sj]

Ten web s názvem bugu v sobě (první linkovaný) ve skutečnosti nepodává příliš relevantní informace a přijde mi jako klasický scare korporátní web ještě navíc s reklamou (s naším bezpečnostním řešením by se tohle odhalilo).

Mnohem lepší informace jsou na http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

[dustin]

Díky

[R]

Z toho vyplyva, ze to odhalenie klucov, hesiel, dokumentov (a pod.) je nezmysel.

[Mike]

Podle linkovaného webu:

Can attacker access only 64k of the memory?

There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.

A tvrdí že se jim povedlo získat kompletní privátní klíče. Já bych se tím, že vámi odkazovaný člověk nepřišel na to jak, tedy neutěšoval. Navíc ten bug nezávisle objevili nejen ti inženýři z Codenomiconu, ale i člověk z Googlu, a na tom zveřejnění pokud vím kooperovali. Takže bych tomu celkem věřil. A hlavně platí: Better safe than sorry.

[Jardík]

typedef struct ssl3_record_st
    {
        int type;               /* type of record */
        unsigned int length;    /* How many bytes available */
        unsigned int off;       /* read/write offset into 'buf' */
        unsigned char *data;    /* pointer to the record data */
        unsigned char *input;   /* where the decode bytes are */
        unsigned char *comp;    /* only used with decompression - malloc()ed */
        unsigned long epoch;    /* epoch number, needed by DTLS1 */
        unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */
    } SSL3_RECORD;

No a už víme, proč je OpenSSL šmejďárna. Neumí používat správne datové typy.

[chrono]

Predpokladám, že veľkosť tých dát (a teda aj poloha) sa zmestí do unsigned int na akejkoľvek podporovanej platforme.

[Jardík]

Na nějakých platformách málo, na některých hodně. Když vidím unsigned int k použití indexu, místo size_t (nebo pokud je tedy velikost známá, tak některého uint_leastN_t/uint_fastN_t typu), tak je to pro mě znamení "můj kód umí čarovat"; na platformě, kde SIZE_MAX je 65535 (minimální požadavek standardu) a UINT_MAX je 651641451516522826412515251624621655216526, tak dokáží nějakým záhadným způsobem indexovat objekt větší, než který lze alokovat. Nebo naopak, na platformě, kde SIZE_MAX je 614616216246264926123155152152515215825 a UINT_MAX je 65535 (minimum zaručené standardem), tak zase říkají "můj kód je hloupej a tak umí pracovat jen s malými objekty, přestože lze alokovat objekty o několik řádů větší). Pokud by však použili správně třeba nějaký typ uint_least16_t, tak mi to řekne "šetříme místem ve struktuře, protože víme, že tento objekt nikdy nebude větší než UINT_LEAST16_MAX. Ale když zase použijou uint_least32_t, tak mi zase lžou, protože SIZE_MAX a sizeof(size_t) může být menší. Jediné správné řešení v tomto případě je něco jako least_type<size_t, SIZE_MAX, uint_least32_t>

[Jendа]

Jak se správně řeší seekování („dej mi předchozí bajt“), když size_t je jenom kladné?

[kralyk z abclinuxu]

off_t

[kralyk z abclinuxu]

Aha, počkat, ten není standardní. Takže intmax_t (C99).

Jinak skutečně se ten ssl3 record nevejde do 64kB? A dále taky je možné, že velikost intu kontroluje build systém.

[Jose]

seekovani zpetne je preci smejdarna :D

[xm]

Tak například ze serverů Yahoo lze přes heartbleed jednoduše dolovat uživatelská jména a hesla v plaintextu (!!!), viz Tweet: https://twitter.com/markloman/status/453502888447586304

Stále ještě to neopravili!

Otestovat vaše servery lze například tímto jednoduchým Python skriptem: https://gist.githubusercontent.com/takeshixx/10107280/raw/8052d8479ad0c6150464748d639b0f5e877e8c37/hb-test.py

[xm]

Btw. upozorňuji že pod postižené Yahoo servery spadá i třeba Flickr, to jen kdyby si někdo říkal, že jeho se to netýká, protože Yahoo nepoužívá

Upřímně se skoro divím, že nějaký troll ještě nenapsal bota, který by lidem na Yahoo náhodně měnil hesla, mazal fotky z Flickru, atp. Snad to opraví dříve než k něčemu takovému dojde...

[Jardík]

Zlatá knihovna JardikSSL, která nic nepředpokládá a žádné takové bugy neobsahuje. SSL a TSL totiž považuje za nedůvěryhodné a proto každá API funkce knihovny JardikSSL vrací chybový kód JARDIK_SSL_SSL_IS_NOT_SECURE.

[Lol Phirae]

Tak na Yahoo sere pes, nicméně tohle taky potěší ))

Do not sign in on Lastpass .com due to the OpenSSL bug #heartbleed All your passwords could get compromised.

[Andrej]

lastpass.com vyzera byt fixnuty

[Lol Phirae]

Tak teď jistě... Nicméně, to už asi postiženým bude platný jak mrtvýmu zimník.

[Andrej]

ja len ze uz ho zase mozu pouzivat

[martin]

a rychle zmenit vsechna hesla ...

[kralyk z abclinuxu]

Tak na Yahoo sere pes, nicméně tohle taky potěší ))

Do not sign in on Lastpass .com due to the OpenSSL bug #heartbleed All your passwords could get compromised.

Na jejich blogu tvrdí, že tím uník dat uživatelů nastat nemohl.

[Lol Phirae]

Jo, čestný pionýrský...

[Honza Jaroš]

Hezké, fakt to funguje, i na STARTTLS Postfixu. No takže jdu vypláznout těch patnáct stovek pro StartSSL za revokaci tří certifikátů...

[Jardík]

Áááá a tady máme loginy z ábíčka ... a soukromý certifikát ... naštěstí nejsem zm*d a data nezveřejním ani nezneužiju, protože Jardík. Doporučím však záplatu, hodně rychle.

[Andrej]

Server returned error, likely not vulnerable

[rbc]

Postni sem neco pod jinym uctem, jestli nekecas ;)

[Jardík]

Né. Netuším, jak je na tom ábíčko. Zkoušení bugů a exploitů, to není nic pro mě. Navíc mi došlo, že ábíčko jede na javě a kdo ví, jak je to tam se SSL, třeba mají vlastní implementacu, co OpenSSL vůbec nepoužívá (třeba NSS či prostě java-impl).

[Nicky726]

Nyní snad dobře.

[Filip Jirsák]

OpendJDK ani Oracle Java OpenSSL nepoužívá. Dnes je ale webovému serveru Abíčka předřazen Nginx, takže teoreticky tím postižené být může.

[Šangala]

Jen tak mimochodem, když jsem si to před chvílí ověřoval, tak jsem zkusmo zkusil i seznam.cz a poprvé mi to prošlo, opakovaně už ne, ale i v tom prvním mám nějaké dvě cookie k přihlášení a ne moje (někoho s user-agent-em MSIE 8.0 :)).

[Luboš Doležel (Doli)]

Na serveru Abc je ještě starší openssl, které nikdy postižené nebylo.

[little.owl]

Tohle je velmi dobry test linuxovych distribuci a jejich odezvy na zavazna CVE.

Dala by se dat dohromady nejaka tabulka, kdy byla chyba nalezena a reportovana, a kdy jednotlive distribuce uvolnily updaty s opravou?

[Honza Jaroš]

Mno, nevím jestli to má nějakou vypovídací hodnotu, ale to nahoře odkazované upozornění na chybu má datum 7.4.2014 17:27:25 GMT. Skripty pro kontrolu Debianu mi našly nové aktualizace OpenSSL 8.4.2014 ve 3:11 CET (ráno kolem osmé jsem rozinstalovával verzi 1.0.1e-2+deb7u5, během dne se ještě objevila 1.0.1e-2+deb7u6), CentOS6 mi tou dobou ještě nic nového nehlásil. V 8:42 jsem doinstalovával opravu OpenSSL na první počítač s CentOS. Co se týče třetí mnou používané distribuce, tak průběh přípravy u Gentoo je vidět v jejich bugzille, na zrcadlech se to pro amd64 objevilo jako stabilní někdy mezi devátou a desátou ráno.

[little.owl]

S tim CentOS to odpovida. Zajimala by me rychlost odezvy u Red Hat, nebot to je prave situace, kdy by se mel vyplacet placeny support RHELu.

[petr_p]

Je takový problém napsat CVE-2014-0160 do redhatí Bugzilly?

[little.owl]

Je to odpoved i neni, bugzilla je jen jedna cast retezce. CentOS to mel oznameno drive nez jsem to mohl stahnout z mirroru.

[Miroslav Suchy]

Red Hat Enterprise Linux 6 mel vydanou erratu v 2014-04-08 05:04:43 CET.

[little.owl]

Coz je 2014-04-08 03:04:43 GMT a dosti dlouho po tom, co byl udelany rebuild.

CentOS je o dosti pomalejsi.

[petr_p]

Jestli si chceš instalovat netestované patche, tak prosím. Ale v enterprise distribuci někdo musí nový build otestovat na základní funkčnost, na regrese, na kompatibilitu s reverzními závislostmi, na bezproblémovost aktualizace z repozitářů a ověřit všechny podporované platformy. Nakonec se balík rozdistribuuje a až potom se vydává oznámení.

[little.owl]

V urcitych pripadech muze byt mensi riziko nainstalovat docasne rychly fix, nez cekat na QA opravy pro diru jak vrata.

[----]

Zkusil jsem se podívat na datum poslední změny na aktualizačních serverech:

ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/
07-Apr-2014 19:47 openssl-1.0.1e-16.el6_5.7.src.rpm

http://mirror.centos.org/centos/6/updates/x86_64/Packages/
08-Apr-2014 02:49 openssl-1.0.1e-16.el6_5.7.x86_64.rpm

http://public-yum.oracle.com/repo/OracleLinux/OL6/
08-Apr-2014 03:02 openssl-1.0.1e-16.el6_5.7.x86_64.rpm

Můžete se kouknout i na další distribuce a jejich oficiální repozitáře.

[Jardík]

Minimálně v Arch Linuxu a Debianu to bylo rychle.

[pta]

Slackware opraveny balicek v 2014-04-08 08:05:22 -0700 (PDT) ;)
Zajimava je reakce vyvojare z OpenBSD, ktery navrhuje upravit OpenSSH aby nepouzivalo OpenSSL.

[stativ]

V Archu to bylo necelé tři hodiny po zveřejnění opravy

[stativ]

Zato archlinux.org byl zranitelný asi až do včerejšího večera.

[pavlix]

Kovářova kobyla.

[Johny Mnemonic]

Bezici instance jednoho naseho testovaciho serveru dokazala ciste nahodou logovat pokusy o Heartbleed utok. Nekdo to poprve zkousel uz 24. dubna - jelikoz se jedna o neverejne testovani, utok musel byt veden automaticky proti velkemu rozsahu adres (server ma prideleny 2 IP, utoky bylo mozne pozorovat na obou z nich).

Detaily zde: http://www.seacat.mobi/blog/heartbleed

[xm]

24. dubna? Wow, netušil jsem že na Ábíčko chodí i cestovatelé v čase Každopádně botnet který bude 24. dubna zkoušet heartbleed toho snad (doufejme) už moc děravého nenajde... i když možná jsem naivní optimista

Nebo to bylo už 24. dubna minulého roku?

Každopádně pokud NSA nemá díky heartbleed už dlouhou dobu soukromé klíče celého Internetu, tak jsou to lamy

[Šangala]

Kdyby jsi se podíval na ten výpis logů, věděl bys, že se jen tady upsal

[xm]

Vždyť já vím, četl jsem to Ale sranda musí být

[fish]

Jak z toho logu vyplyva, ze to byl pokus o heartbleed a ne obycejny portscan?

[Johny Mnemonic]

Ano, jiste - je to 24 brezna

Samozrejme, ze nevim, co bylo obsahem toho pristupu -- nicmene tento error se zacal objevovat prave od 24 brezna, ackoliv tato instance bezi jiz minimalne od unora. Muze to byt samozrejme nahoda, nahoda je, ze to tuhle vec vubec loguje.

[Sid]

Na to ze to vobec neviete podlozit tak by som ocakaval, ze namiesto bold fontu a textu "Well, we actually find out that SeaCat server logs these attempts to its log file, see bellow." zdoraznite aj moznost cislo 2, ze sa moze jednat o nahodu.

[Johny Mnemonic]

No, muzu to autorovi blogu predat, ale neco me rika, ze vim, co mi na to rekne.

[x]

OpenSSL bug on purpose by incompetence

[Spike]

Ve stable Debianu je nějaký nový build OpenSSL (OpenSSL 1.0.1e-2+deb7u6), ale v Changelogu o něm není zmínka. Co to?

[fish]

u6 byla revize, ktera zajistila restart dotcenych sluzeb (v mem pripade to i tak zapomnelo na apache), protoze prechozi update pouze opravil openssl, ale restart musel spravce delat rucne. Nekde jsem zahledl, ze tuhle revizi vydal security team nezavisle na spravci balicku, proto se pravdepodobne neobjevila vsude kde by normalne mela.

[trekker.dk]

Jo, díky moc. 300 serverů, které mi najednou nejdou aktualizovat automaticky kvůli pitomému dialogu.

[little.owl]

Interaktivni update deb?

[hermelin]

Stejny problem - zrestartoval vsechny sluzby az na apache. Jinak s automatickymi updaty to funguje uplne bez problemu - mam cron-apt a normalne bez problemu automaticka instalace update a restart sluzeb (az na apache).

[Bystroushaak]

Tak už je o tom i XKCD: http://xkcd.com/1353/

[smazáno]

ale celkem slaby teda :)

[Andrej]

+100 za odkaz na Hauerovu basnicku z Blade Runnera

[pta]

Ah, dalsi fanda. Z Promethea asi nikdy zadne hlaska nezlidovi. Mozna tak demence vyzkumniku ;)

[tlamik]

Technický dotaz, rekompiloval jsem openssl s parametrem -DOPENSSL_NO_HEARTBEATS, což se sice povedlo, nicméně i po restartu apache je server vulnerable. Všiml jsem si, že ta kompilace udělá binárku, man pages, ale žádnou knihovnu (teda kromě libcrypto.a a libssl.a). A takže apache dál vesele používá neaktualizovanou /usr/lib64/libssl.so.1.0.1c :(
Co dělám blbě ?

[Lol Phirae]

Děláš blbě to, že nepoužíváš balíčky vytvořený někým, kdo má tušení, co dělá.

[tlamik]

No takové chytráky mám nejradši. Co třeba když pro mou kombinaci openssl a distra balíček není ?

[Lol Phirae]

Co to? V tvém distru nemají zazáplatované openssl? No, tak to přestaň používat.

[little.owl]

Co mate za distribuci?

[tlamik]

CentOS 5 s aktualizacemi z axivo repa (čili mám openssl-1.0.1e)

[Lol Phirae]

K tomu se nedá nic, než zopakovat "tak to přestaň používat."

[pavlix]

Nebo se naučit upravovat balíky, pokud je vážný důvod takový systém používat nebo je potřeba překlenout čas než se připraví nové řešení.

[Lol Phirae]

Ostatně k RPM tady kdysi vyšel docela slušný seriál, pokud se nepletu.

[little.owl]

Ano, zde. Dobre misto jak zacit.

[tlamik]

Pokusím se obrazně shrnout užitečnost odpovědí na mou otázku na jednoduchém příkladu:

Ptám se kolik mám dát soli do těsta na pizzu ?

Odpovědi na sebe nenechávají dlouho čekat. První je nic nevař a jdi do pizzerie, další je proč si děláš těsto, kup si hotové těsto a pizzu si ozdob, další je proč si neobjednáš pizzu domů, další si jen postesknou, že pizza je hrozně nezdravé jídlo a vůbec by se neměla jíst. Vegani dodají, že nejzdravější je syrová zelenina.

Já se neptám na to co mi radíte za distro používat, neptám se co si myslíte o distribucích co nezáplatují openssl. Já se ptám co dělám blbě při kompilaci openssl. BTW: rekompilaci openssl radí všem, kteří z nějakého důvodu nemohou aktualizovat z repozitářů, čili nevidím v tom žádný problém, mělo by to jít. Samozřejmě nemám zdrojový balíček a nevím s jakými parametry to bylo kompilováno (něco sice vyčtu ze samotné binárky openssl, ale asi to nestačí). Všude píšou, že je třeba překompilovat s vypnutým heartbeatem a restartovat všechny služby využívající ssl a to se mi nepodařilo.

[Lol Phirae]

Zkompilovals to akorát jako statickou knihovnu. Pokud ti to není jasné, tak se prostě řiď předchozí radou, nic nekompiluj a upgraduj na podporovanou verzi distribuce. Protože to stejně nejseš schopen udržovat v bezpečném stavu, a evidentně toho není schopen ani ten maník, co vytvořil to zjevně mrtvé alternativní repo.

[little.owl]

Jaktoze nemate zdrojovy balicky? Apache muze byt zkompilovan tak, ze openssl je staticky linkovana. Jak rekompilovat balicky u CentOS najdete zde.

[little.owl]

OK, minuta hledani a nejaky specificky navod mate zde.

[tlamik]

Zdrojové balíčky z AXIVA jsem prostě nenašel. Proto jsem to zkoušel zkompilovat ve stávající verzi s vypnutým heartbeatem.

[pavlix]

Pokud AXIVA distribuuje i GPL software, tak to zavání porušením licence. Nicméně ať je to tak nebo ne, používat binární balíky open source softwaru od někoho, kdo neposkytuje zdrojové kódy... kdo chce kam...

[tlamik]

Řekněme, že jsem nenašel na netu žádný jiný návod jak aktualizovat openssl, php atp na novější verzi. A dost možná ani žádný jiný není, pokud nemůžu hned upgradovat.

[Lol Phirae]

Takže si to shrňme - máš dávno nepodporovaný systém, do kterého jsi narval jakési obskurní "aktualizované" balíčky z mrtvého repozitáře provozovaného bůhvíkým, který navíc ani neposkytuje zdrojáky, kompilovat neumíš, s RPM taky neumíš, a myslíš si, že je výborný nápad tam tu děravou mrtvolu nechat, jůůůů? No, tady je asi jakýkoliv další komentář zbytečný.

[little.owl]

CentOS 5 je stale podporovany.

[Lol Phirae]

Asi ne tím obskurním repositářem, který tam tazatel má. Jinak totiž nevím, co tady řeší:

https://www.axivo.com/threads/openssl-patch.255/#post-1042

[tlamik]

https://www.axivo.com/threads/centos-5-with-openssl-1-0-1.236/#post-1043

[Lol Phirae]

Ano, gratuluji. "Aktualizoval" jsi na výtečný repozitář, který se na podporu distribuce vysral dřív, než její výrobce. Geniální tah. Tebe bych chtěl mít za admina.

[little.owl]

Zkuste je pozadat o zdrojovy balicek (SRPMS) k verzi co mate, to by vam mohlo hodne ulehcit zivot.

[tlamik]

Snažím se :) Každopádně děkuji, vaše příspěvky byly releventní.

[tlamik]

Tys asi vůbec nic nepochopil. Snažím tu děravou mrtvolu jak tomu říkáš ty, oživit nebo záplatovat. Nicméně CentOS 5 není žádný nepodporovaný systém, proč by měl být ? Viděls ho vůbec někdy ? Nebo jen teoretizuješ ? AXIVO není mrtvý repozitář, atd... Prostě tady kecáš kraviny a víš o tom howno. Určitě si netroufnu říct, že jsem mistr v kompilacích nebo v používání RPM, ale občas něco zkompiluju a občas použiju i RPMko. A tvoje hloupé rady, že mám použít snad yum update a jsem spasen si strč někam. Řeším situaci se kterou si nevím rady (ty evidentně taky ne) a hledám podněty co dál. Aktualizace OS v dohledné době nepřipadá v úvahu. Čili to není taková sranda jako udělat update doma na nějakém sranda samba linuxu pro jednoho uživatele

[Lol Phirae]

Už jsem ti psal výš, proč tak kurwa rveš balíčky z repositáře, které na tvůj CentOS 5 evidentně serou jak na placatej šutr?

https://www.axivo.com/threads/openssl-patch.255/#post-1042

[chachar87]

V dobe kdy tam rval ten balicek na CentOS 5 evidentne nesrali. Jak poznas bez kristalove koule, ze nejaky repozitar se v budoucnu vysere na dosud podporovany OS?

[Lol Phirae]

No, já tam hlavně nebudu vůbec balíčky z nějakého takového repozitáře cpát, protože fakt netuším, proč bych takovou pitomost vůbec dělal. Takže tento "problém" v budoucnu nebudu muset řešit.

[chachar87]

rekl bych ze on uz taky ne :D Nicmene ted ten problem ma a potrebuje ho vyresit. Jak pise neni to "samba server linux", kde neni problem update na CentOS 6.

Chapu vase(little.owl, pavlix, ty) rozhorceni, ale reseni typu vrat se v case a zmen sve rozhodnuti neni evidentne mozne.

[pavlix]

Nejsem rozhořčen tím, že někdo udělal chybu, ale tím, že se tváří jako bůh, když chce pomoct s řešením následků.

[pavlix]

Nehledě na to, že jak já, tak little.owl jsme každý do diskuze napsali nějakou radu, jak situaci řešit.

[chachar87]

No prvotni dotaz mi pripada jako ze se pta nekdo kdo vi ze nekde dela chybu ale nevi kde (Buh by to nepriznal).

Zostril sve reakce po odpovedich typu: nemel jsi to tam vubec davat.

[little.owl]

Nemam pocit, ze bych se do nej navazel.

[chachar87]

Nemam pocit, ze bych to tvrdil.

Popravde i kdyz tvoreni balicku nerozumim, tak tvoje odpovedi mi prijdou nejvic nabizejici reseni.

[pavlix]

Já si myslím, že nejlepší řešení získáš, když odpovědi zkombinuješ, tzn. když použiješ informace o tvorbě balíčků, balíček z aktuálnějšího systému a původní balíček z CentOS. Pokud tedy někdo nemá balíček pro CentOS 5 už připravený.

[tlamik]

A jak teda nainstaluješ SW, který vyžaduje novější vezi openssl než která je k dispozici v tvém distru ? Moc se těším na odpověď. I když vlastně netěším, určitě to budou pořád stejné kecy a nic užitečného.

[pavlix]

Mezi lidmi, co se v linuxu považují za něco více než začátečníky, je zvykem volit distribuci mimo jiné i podle účelu použití. Do toho účelu patří i to, jaké aplikace se chystáš provozovat. Rovněž je docela dobrým zvykem netrvat na dřívějších rozhodutích, pokud se v novém světle ukazují jako nevhodná. Vzhledem k tomu, že řešíš problém, který je pouhým důsledkem tvých předchozích rozhodnutí, nevidím na prohlášení Lol Phirae, že by se tomu problému vyhnul, nic špatného.

[tlamik]

Myslím, že se motáme pořád dokola, kromě Lol Phirae, který nic neporadil a je po bitvě generálem (vždycky všechno ví dopředu a nikdy neudělá špatné rozhodnutí). Já jsem tu aktualizaci nedělal včera nebo před týdnem, dělal jsem jí v době, kdy byla daná verze openssl považována za bezpečnou. Přejít na CentOS 6 nebylo možné a nějak pokoutně kompilovat apache, openssl a bůhvícoještě mi nepřipadalo rozumné. Proto jsem se poohlížel, jestli nějaký dobrák neudělal RPMka s novější verzí. Udělal. AXIVO. A podle vás je nerozumné používat jiné repozitáře (EPEL, ELREPO atd.)? Pořád nějak nechápu v čem jsem udělal špatné rozhodnutí ? Už mě to tu nebaví pořád dookola popisovat. Stejně se dočkám akorát urážek a ponížení, že jsem blbej, nic neumím, udělal jsem špatné rozhodnutí atp...

[pavlix]

Já jsem tu aktualizaci nedělal včera nebo před týdnem, dělal jsem jí v době, kdy byla daná verze openssl považována za bezpečnou.

Já taky netvrdím, že byly následky od začátku zřejmé.

Přejít na CentOS 6 nebylo možné

Tohle nepodložené plácání do větru si dovolím ignorovat.

A podle vás je nerozumné používat jiné repozitáře

Záleží na co a záleží které.

EPEL

EPEL je fedoří projekt, který rozšiřuje množinu dostupných balíků a neaktualizuje již dostupné balíky. Považuju za rozumné ho použít, pokud chci získat nějaké další jinak nedostupné balíky. Věřím, že nedostupnost SRPM u něj nenastane.

ELREPO

Neznám, stejně jako neznám AXIVA, a pravděpodobně bych ho nepoužil.

Pořád nějak nechápu v čem jsem udělal špatné rozhodnutí?

Pokud chceš, můžeme tomu prostě říkat rozhodnutí se špatnými důsledky. Z technického pohledu je to úplně stejné, ale třeba se díky tomu budeš cítit lépe.

Stejně se dočkám akorát urážek a ponížení, že jsem blbej, nic neumím, udělal jsem špatné rozhodnutí atp...

Urážky od Lol Phirae mi přijdou nezajímavé. Nicméně urážky od tebe jakožto tazatele je něco, na co jsem vcelku alergický stejně jako mnoho dalších lidí, kteří se musejí běžně vypořádat s nadávkami od těch, kterým nějakým způsobem pomáhají. Je to opravdu denní chleba, tak doufám, že ti to pomůže moje reakce pochopit.

jsem blbej

Něco se ti nepovedlo a chováš se jako bůh, kterému ostatní nesahají po kotníky. Je to opravdu směšné.

nic neumím

Minimálně netušíš spoustu základních věcí ohledně údržby distribuce a balíčků. Nejsi jediný, kdo se takové věci zjevně učí na produkčním systému, ale to ještě neznamená, že tě za to budou obdivovat ;).

udělal jsem špatné rozhodnutí atp...

Ano, to je můj názor. Nicméně pro účely diskuze nemám problém to nazývat rozhodnutím se špatnými důsledky, jak už jsem psal výše.

[tlamik]

Ve kterém příspěvku se tvářím jako Bůh ? Ve kterém příspěvku urážím někoho, kdo se mi snaží pomoct ?

[pavlix]

Podle mě už od komentáře číslo 83.

Chápu to tak, že tvé výpady vůči Lol Phirae se nepočítají, protože on se pomoct nesnažil? Já si myslím, že jeho návrh nechat to na lidech, co to s balíčky umí byl velmi relevantní alternativou k tomu, co psal little.owl nebo já. I to je jistá forma pomoci ;). Myslím si, že výpady ohledně jeho neznalosti by byly fér leda od někoho, kdo ví, která bije. Musím říct, že chápu přesně, jak ke svým závěrům došel a až na některé faktické detaily nejsme výjimečně ve sporu.

Člověk, kterému by se skutečně hodila pomoc s technickým problémem by si měl v první řadě hledět toho, aby dodal relevantní informace včetně přesného popisu postupu, který vyzkoušel a důvodů, proč tak udělal, a neřešit jak urazit ty, kteří mu v diskuzi nepřijdou užiteční.

Pokud nemáš žádné další výhrady k tomu, co jsem tu napsal, budu se těšit na popis tvého úspěšného postupu k řešení. Pokud máš pocit, že provoz aktuálního openssl na centos 5 má nějaký smysl, tak bych uvažoval i o blogpostu. Můj osobní pohled je, že to smysl nemá, ale v tomto ohledu zjevně nejsme ve shodě, třeba tím pár lidí potěšíš ;).

[tlamik]

little.owl se do mě ani jednou nenavezl, že jsem debil, že používám starou distribuci nebo že neumím kompilovat atp. Zeptal se mě na pár věcí, které mu z mých příspěvků nebyly jasné a odpověděl stručně a jasně bez invektiv a podle toho jsem se k němu také s úctou choval.
Takový Lol Phirae k tomu přistoupil upe jinak a já jsem zvyklý jednak s každým tak, jak on jedná se mnou. Čili jestli to vypadalo, že nadávám někomu, kdo se mi snaží pomoct, tak to je špatně, jen jsem si nechtěl nechat nadávat člověkem, který je buď "divný" nebo dělá unáhlené závěry nebo tak něco, od něj bych si ani radit nenechal, stačilo mi pár příspěvků (možná jen dnes neměl svůj den, možná jsem ho neměl já).
Čili smysluplných rad a nakopnutí jsem se nebránil, ale hlouposti typu vrať se do minulosti a neinstaluj něco mi příjdou jako ztráta času a nijak řešení situace nepomáhají, ba co víc, ani do budoucna se z toho člověk nemůže poučit, protože já třeba před rokem nevěděl, že v openssl 1.0.1 je heartbeat bug, stejně jako nevím jaký bug je tam ve verzi g, který objeví za tři měsíce. Prostě jsem potřeboval jedničkové openssl na CentOS 5, toť vše. A i když jsem admin, tak o některých věcech prostě nerozhoduji, čili vybírat si většinou nemůžu a musím instalovat co je třeba na OS jaký je atp....

Nakonec se mi povedlo zkompilovat poslední verzi 1.0.1g v CentOS 5 jako rpm balíčky včetně libraries. Díky (myslím little.owl) za nakopnutí, zbytek byl jen hloupý flame.

[Lol Phirae]

Prostě jsem potřeboval jedničkové openssl na CentOS 5, toť vše... zbytek byl jen hloupý flame.

Ano, máš pravdu, jsi prostě nepoučitelný...

[pavlix]

Tohle už znám nazpaměť třeba z poradny abclinuxu. Tazatel se cítí dotčený, tak se začne chovat jako pitomec. Přesto mu někdo v diskuzi pomůže. Tazatel toho dotyčného pak zneužije jako argument proti tomu, kdo ho něčím popudil. Pokud tě můžu o něco poprosit, nedělej to. Pochybuju, že se tím little.owl nebo komukoli jinému nějak zavděčíš.

možná jen dnes neměl svůj den, možná jsem ho neměl já

Tož na tom úplně nesejde. Mnoho lidí prostě trpí utkvělou představou, že když do diskuze položí dotaz, tak mají snad nějaký nárok na to, aby jim v reakci chodily jen odpovědi, které se jim budou líbit. Nejenže tahle diskuze není vůbec v poradně, ale ani v místní nebo jiné poradně se člověk nevyhne reakcím, které se s jeho představami jaksi míjejí.

Původně položenému dotazu chyběla mnohá důležitá fakta jako třeba zdůvodnění nasazení či ponechání CentOS 5, použití potenciálně pochybných repozitářů, detailní informace o neúspěšném pokusu o řešení včetně zdůvodnění jeho kroků. Když to vezmu kolem a kolem, tak ten dotaz byl vlastně dost blbě položený. Třeba Stack Exchange má na tohle docela pěkný systém, kde se dotazy hodnotí, komentují a průběžně doplňují, stejně tak jako odpovědi, v běžné diskuzi ale takové nástroje nemáš.

Nehledě na to, že patří k základním znalostem správy jakýchkoli linuxových systémů, že software se do produkčních systémů neinstaluje pomocí make install a především proč to tak je. To je ovšem i hlavním sdělením little.owl, pokud nepočítám odkazy na návody, které ovšem není problém najít internetovým vyhledávačem.

ani do budoucna se z toho člověk nemůže poučit

Nesmysl. Rozumný člověk po takovéto zkušenosti bude přemýšlet o tom, na co může při své práci spoléhat a na co nikoliv. Je z toho jasně vidět v čem spočívá jedna z hlavních výhod open source a jak se dá vcelku spolehlivě zabít. To, o čem teoretizují lidé v dizkuzích tady člověk pocítí na vlastní kůži.

Nakonec se mi povedlo zkompilovat poslední verzi 1.0.1g v CentOS 5 jako rpm balíčky včetně libraries. Díky (myslím little.owl) za nakopnutí

Jestli ti to opravdu přijde tak přínosné mít novou verzi openssl na CentOS 5, chystáš se zdrojový balík nebo konkrétní postup jeho vytvoření někde publikovat?

zbytek byl jen hloupý flame.

I na ten flame musejí být alespoň dva ;).

[Bystroushaak]

+1

[Lol Phirae]

No, na produkční mašině teda určitě ne tak, že něco tak absolutně kritického, jako je openssl, nahradím v celém systému balíčkem z bůhvíjakého repozitáře, který evidentně nemá žádnou pevně stanovenou dobu podpory. Takže holt se smířím s tím, že ten SW tam nebude, nebo systém upgradnu, nebo pokud budu už hodně zoufalý, tak to holt s novějším openssl slinkuju staticky a udělám si z toho vlastní balíček.

[Grunt]

Jen tak pro zajímavost: Podařilo se problém vyřešit?

[Grunt]

A ještě jedna zajímavost: Jde o stránky H-COMPu?

[pavlix]

Aneb když se z bezradného začátečníka vyklube agresivní pitomec.

[pavlix]

Pokud někdo své systémy spravuje zvláště amatérským způsobem, tak by si pak měl nést následky sám.

[little.owl]

Muzete vylistovat jake balicky z AXIVA pouzivate?

Prijde mi, ze openssl tam nemaji ....

[tlamik]

dají se stáhnout třeba takto:
yum --enablerepo=axivo install openssl -y --downloadonly --downloaddir=/tmp
-rw-r--r-- 1 root root 1524911 Jan 30 12:16 openssl-0.9.8e-27.el5_10.1.i686.rpm
-rw-r--r-- 1 root root 1525512 Jan 30 12:16 openssl-0.9.8e-27.el5_10.1.x86_64.rpm
-rw-r--r-- 1 root root 650301 Apr 26 2013 openssl-1.0.1e-1.el5.x86_64.rpm
-rw-r--r-- 1 root root 1308320 Apr 26 2013 openssl-devel-1.0.1e-1.el5.x86_64.rpm
-rw-r--r-- 1 root root 3618362 Apr 26 2013 openssl-libs-1.0.1e-1.el5.x86_64.rpm

[little.owl]

OK, Lol ma asi pravdu, vase repository uz nejspise nepodporuje CentOS 5 a pritom jeji puvodni balicky pouzivaji novejsi verzi openssl. Drzte se orientacne zmineneho postupu v odkazech nahore pro CentOS 6, s tim, ze budete muset ohackovat spec file pro CentOS 5.

[pavlix]

Mám podezření, že jsi spíš shrnul užitečnost všech svých dosavadních příspěvků. Pokud bys skutečně prováděl rekompilaci balíku obsahujícího knihovnu openssl tak jak se má, tak by ti jen těžko mohl vzniknout balík, který tu knihovnu neobsahuje. Jedním z posledních kroků buildu RPM balíku je kontrola seznamu souborů. Pokud by i přesto nastaly potíže, bez podrobného popisu toho, co jsi udělal, ti nikdo nemůže pomoct.

[tlamik]

Nevím nejsem neomylný, ale troufám si říct, že jsem nikde nepsal o rekompilaci žádného balíčku, píšu o rekompilaci openssl (myšleno ./configure; make; make install)

[Lol Phirae]

Ano. Takhle to nikdo příčetný nedělá, proč, to by ses dozvěděl, kdyby sis přečetl aspoň úvod do toho seriálu o RPM linkovaného výše. Proboha, vykašli se na to a nech balíčkování na lidech, co tomu rozumějí.

[pavlix]

Rekompilace openssl v distribuci je obecně používaný termín pro opětovnou kompilaci stejným postupem jako byla provedena původní kompilace pro danou distribuci. To, co jsi provedl, žádná rekompilace není, nýbrž je to nová kompilace způsobem, který je vhodný pouze pro experimentální vývojářské buildy. Odkazuješ se tedy na doporučení, kterého ses ve skutečnosti vůbec nedržel.

[tlamik]

Jak už jsem psal, jelikož jsem nenašel SRPM od axiva, tak jsem zkusil zkompilovat přímo openssl (a ne že by to nešlo) v té samé verzi, kterou mám z axiva.

[pavlix]

Vzhledem k tomu, že se jedná o aktuální verze, tak by asi nebyl problém najít SRPM pro nějakou aktuálnější distribuci a SRPM pro genuine openssl z CentOS 5 a pokusit se je zkombinovat do funkčního SRPM aktuálního OpenSSL pro CentOS 5. Ale stále jsem toho názoru, že je to řešení problému, který vznikl dřívějším špatným rozhodnutím.

[Jendа]

Pokusím se obrazně shrnout užitečnost odpovědí na mou otázku na jednoduchém příkladu:

Ptám se, jak nakreslit 7 navzájem kolmých červených čar ve tvaru kotěte zeleným a průhledným inkoustem. Odpovědi na sebe nenechávají dlouho čekat. První je, že si máš vzít červený inkoust. Další, proč kreslit průhlednou čáru, když pak nebude vidět. Další, že nemůže být tolik čar na sebe navzájem kolmých. Absolventi matfyzu dodají něco o velikosti ortogonální báze lineárního prostoru.

Já se neptám na to co mi radíte kreslit, neptám se, jakou barvu inkoustu byste mi na kreslení červených čar doporučili. Já se ptám, co dělám blbě při kreslení červených čar zeleným inkoustem.

[kralyk z abclinuxu]

Absolventi matfyzu dodají něco o velikosti ortogonální báze lineárního prostoru.

Touché. Jinak to video je geniální...

[Jendа]

Touché.

Psáno během vymýšlení úkolu z lingebry

[pavlix]

Víš co se mi na tom videu nelíbí?

[Jendа]

• Že jsou v něm vypálené titulky?
• Že to přesně takhle zažíváš?

[pavlix]

Druhá odpověď je správně. Teda ne že bych to zažil někdy v poslední době, ale některá jednání z dřívějška mi to velmi silně připomíná. Včetně té manipulace, skrytých urážek, předpokladu správnosti u zjevných nesmyslů na základě jejich původce...

[trekker.dk]

To protože jsi určitě byl příliš konzervativní a nepřicházel s neotřelými progresivními řešeními.

[Bystroushaak]

Imho se nechal moc omezit. Kdyby opravdu chtěl, mohl to celé nakreslit průhledným inkoustem, nebo z toho udělat jen 2D pohled do dimenzí či prostorů, kde na sebe kolmé budou, či si vzít na pomoc věci jako gravitační čočky. Barvy se daly vyřešit použitím speciálního papíru, či dalších vrstev, které změní chemické vlastnosti inkoustu. Ale chápu, že v tom pointa nebyla.

[pavlix]

No takové chytráky mám nejradši.

Zvlášť když mají zrovna pravdu, že :).

Co třeba když pro mou kombinaci openssl a distra balíček není?

Taky se těším na jméno distribuce, která nechala openssl nezáplatované.

[pavel]

Třeba CentOS 5, protože:

CentOS 5: Unaffected (Shipped with older version prior to vulnerability)

[pavlix]

V kontextu diskuze je asi vcelku zřejmé, že jsem měl namysli nezáplatované openssl trpící tou bezpečnostní chybou.

[pavlix]

TN.CZ

[Lol Phirae]

OpenSSL využívají Windows od společnosti Microsoft

Hle, zase jsem se dozvěděl něco nového... N@ha nikdy nezklame!

[egg]

ČTĚTE TAKÉ: Zakáží lékaři počítače? Wi-fi signál zabíjel a Evropou se šíří panika

WTF did I just read?...

[Lol Phirae]

NTV!

[xm]

Náhodou to za přečtení stojí, dobře sem se pobavil Něco jako zprávy rádia Jerevan Aneb Prásk vysvětluje hoax

[pavlix]

Ale jo. Vždyť je to dokonalé rádio jerevan!

[kralyk z abclinuxu]

Hle, zase jsem se dozvěděl něco nového... N@ha nikdy nezklame!

No, alespoň nezkomolili tu informaci o ~2/3 postižených serverů. To na novinkách tuto informaci promptně přetransmutovali na "dvě třetiny uživatelů internetu" [1].

[Bystroushaak]

Nefunguje ten útok oboustranně? Tedy když ho použije server, tak dostane kus paměti klienta?

[Lol Phirae]

https://github.com/Lekensteyn/pacemaker

[trekker.dk]

No shodou okolností teď na Windows vyšla nějaká důležitá aktualizace a mám takový pocit, že se týkala šifrování. Že by si v Redmondu něco vypůjčili?

[Lol Phirae]

Žádnou novou důležitou aktualizaci nevidím.

[trekker.dk]

Mně se kvůli tomu včera resetoval stroj - automaticky, pochopitelně zrovna když se mi to moc nehodilo.

[David]

Ahoj, zeptam se blbe, ale je mozne nejak otestovat sve klice, jestli jsou bezpecne, jeste nez budu generovat nove?

[pavlix]

To je opravdu blbý dotaz, vzhledem k tomu, že se objevená chyba vůbec netýká kvality klíčů.

[vev]

Aha, takže čtení soukromého klíče nijak bezpečnost nenarušuje ... Jinak k předchozímu dotazu: těžko zjistit, které certifikáty byly kompromitované.

[Jendа]

se objevená chyba vůbec netýká kvality klíčů → takže čtení soukromého klíče nijak bezpečnost nenarušuje

Nevidím tuto implikaci.

[pavlix]

Aha, takže čtení soukromého klíče nijak bezpečnost nenarušuje

Máš velmi neotřelé myšlenkové pochody.

[David]

V tom případě jsem to pochopil špatně. A to tak, že jsem pomocí "vadného" OpenSSL generoval tím pádem zranitelné klíče. Za hloupý dotaz se omlouvám:)

[pavlix]

Taková chyba byla před lety v OpenSSL v Debianu a týkala se mimojiné SSH klíčů.

[David]

jj, prave to jsem si vybavil.. v te dobe jsem musen klice pregenerovat a byl to docela vopruz :)

[Jendа]

Můžeš, v mé patičce je odkaz.

[Honza Jaroš]

Hezký

[pavlix]

Dooost dobrý.

[trekker.dk]

Tak to jsem přesně čekal.

Jestli někdo jako privátní klíč používáte kus vyhlášky 50/1978 zakódovaný do base64, tak si vygenerujte nový.

[Jardík]

Jardík likes <3

[Grunt]

Moje klíče prej bezpečné nejsou

[egg]

Nevadí, vygeneruj nové a nezapomeň si je taky hned zkontrolovat.

[Šangala]

Se mi nepodařilo takové vytvořit a dělám na tom už od včerejška… :(

[Lol Phirae]

Выдержай пионер!

[Šangala]

Я читал книгу «Судьба человека».

[w4rr10r]

Ale jistě, Jenda to má v patičce.