Portál AbcLinuxu, 10. května 2025 20:50
Byly vydány nové verze kryptografické knihovny OpenSSL. Ve verzích 0.9.8za, 1.0.0m a 1.0.1h je opraveno hned 7 bezpečnostních chyb. Zranitelnost CVE-2014-0224 lze zneužít k MITM útokům. Masashi Kikuchi, bezpečnostní expert z Lepidum, jenž zranitelnost objevil, zveřejnil na blogu analýzu problému.
Tiskni
Sdílej:
a nic se nezlepsuje.Zlepsuje, ale jeste je brzy soudit.
jak se třeba bude auditovat za pár let další opensource-prasárna - systemdsystemd neimplementuje tolik složitých síťových protokolů.
Jak vlastně tyhle komponenty systemd vypadají? Je možné, aby běžely pod jiným uživatelem s omezenými právy a ideálně ještě omezené něčím jako AppArmor? Dříve taky bývalo zvykem podobné služby pouštět v chrootu. A co ty cgroups, budou tam aspoň k užitku v tomto směru?
Audit je samozřejmě správná věc, ale je dobré ten systém navrhovat tak, že s chybami počítáme – jedna děravá komponenta by neměla ohrozit zbytek systému.
je dobré ten systém navrhovat tak, že s chybami počítáme – jedna děravá komponenta by neměla ohrozit zbytek systému.Když jsem upozorňoval, že se jedná o klíčové komponenty, nedělal jsem to jen tak z legrace. Bezpečnost klíčových komponent jako je konfigurátor systémového času nebo DNS cache/resolver má typicky na bezpečnost zbytku systému vliv a házení obecnými poučkami na tom jen těžko něco změní.
Tyhle komponenty jsou kritické, ale spíš ve smyslu DoSu než ve smyslu narušení bezpečnosti (resp. měly by být).
Posunutý čas může nadělat nepořádek, některé služby kvůli tomu třeba nenaběhnou, ale rozhodně by to nemělo způsobit, že někdo získá vyšší oprávnění než která má mít, že počítač odešle data, která odeslat neměl atd. Navíc by to mohlo fungovat tak, že NTP démon smí nastavovat čas jen v nějakém intervalu (v jakém se běžně rozcházejí HW hodiny) a pro větší posuny by byla potřeba dodatečná autorizace.
DNS by opět nemělo být něco, na čem stojí bezpečnost – podvrženým DNS záznamům je dobré předcházet pomocí DNSSEC, ale stále se s nimi musí počítat a nelze brát DNS jako nějaký jediný zdroj pravdy – už jen proto, že síťový provoz jde přesměrovat i na úrovni IP adres, není potřeba podvrhovat DNS odpovědi.
Co se týče distribuce veřejných klíčů (nebo otisků) přes DNS, tak to by opět měl být jen kontrolní mechanismus, ne jediný zdroj, na který by se dalo spoléhat. Taková situace by se rovnala SSL certifikátům, kde je jedna celosvětová kořenová autorita + podřízené autority TLD registrátorů + podřízené autority registrátorů druhé úrovně, kteří ti podepíší certifikát. Kde navíc dochází k nebezpečné koncentraci moci (jeden subjekt si může jednak vydat certifikát na tvé jméno a jednak může nasměrovat tvůj síťový provoz k sobě a dělat MITM).
Jsou to služby jako každá jiná a stejně tak můžeš přistupovat k jejich ochraně dostupnými prostředky. Nevidím jediný důvod proč by služba distribuovana ve zdrojovém balíku systemd…
Tohle jsem chtěl slyšet. Pak tedy až tolik nechápu ti útoky na systemd – neměl by to být takový monolitický moloch, jako spíš množina komponent verzovaných ve společném stromu. Akorát je tedy důležité, abych si mohl výchozí implementaci (např. NTP, DNS) nahradit vlastním démonem (tzn. dobře definované rozhraní resp. specifikované, co má ta služba poskytovat).
V systemd je i Kerberos? Nebo bude?
Tohle se mi právě taky moc nelíbí. Uvítal bych, kdyby to bylo víc projektů, klidně vyvíjených tím samým týmem, ale distribuovaných samostatně. Když někdo nepotřebuje DNS(SEC) nebo NTP nebo Kerberos, tak by přece měl mít možnost používat systém i bez toho, resp. init systém by na tom neměl záviset.
Např. když budu mít nějaké malé jednoúčelové zařízení, kde nepotřebuji DNS (buď použiji DNS server na síti nebo si klidně nastavím pár IP adres natvrdo) a ani mě nezajímá aktuální čas, bylo by fajn, abych mohl používat stejnou distribuci a stejný init systém, jako na jiných počítačích – a nemusel tam tyhle služby provozovat ani je mít nainstalované.
Jak jsem psal výše:
Pak tedy až tolik nechápu ti útoky na systemd – neměl by to být takový monolitický moloch, jako spíš množina komponent verzovaných ve společném stromu. Akorát je tedy důležité, abych si mohl výchozí implementaci (např. NTP, DNS) nahradit vlastním démonem (tzn. dobře definované rozhraní resp. specifikované, co má ta služba poskytovat).
Nevadí mi, že lidi kolem systemd dělají i kdeco dalšího, ale neměla by na tom být závislost, mělo by to jít vypnout, nahradit alternativní implementací nebo neinstalovat vůbec.
Nene, nebo o tom nevim. Ale jenom jsem chtel rict, ze systemovy cas neni neskodnou zalezitosti. Ty sice rikas ve svem prispevku 'melo by se to a to' (napr. nedovolit skocit s hodinama vic jako o XY), jenze jak v tom zabranim programu, ktery holt jednou to pravo sahat na hodiny ma? Ochranou v jadre? Jakoze, ne ze by ten samy problem nebyl i se soucasnymi implementacemi NTP, jak jsou.
Tu se v diskuzi tvrdi, ze tim, ze se tyhle veci dostavaji do systemd, nejak budou min bezpecne, ale neprijde mi, ze by si nekdo delal moc hlavu se stavem i soucasnych reseni...
Ta moznost pooddelovani komponent mi zni tak nejak... Preci od toho jsou kontejnery, proste pustim citlivou vec oddelenou od ostatnich. Ale ten systemd v tom kontejneru bude taky :) Tam bych pak ocenil moznost z nej 99% veci vyhazet/nespoustet.
(je to jenom random kousek myslenek, ja vlastne porad nevim, co si o systemd myslet jinyho, nez ze je to proste zmena a nejlepsi je prizpusobit se, kdyz uz tu jednou je)
Tyhle komponenty jsou kritické, ale spíš ve smyslu DoSu než ve smyslu narušení bezpečnosti (resp. měly by být).Nesprávná konfigurace systémového času má vliv na mnoho kryptografických nástrojů a protokolů (třeba zrovna Kerberos, jak píše snajpa). Nesprávná konfigurace DNS představuje pokud vím velmi aktuální DNS spoofing a navíc může představovat downgrade útok na DNSSEC. Napadený validující resolver pak nabízí fatální downgrade útok. Bagatelizovat toto na úroveň denial of service je nebezpečný omyl.
DNS by opět nemělo být něco, na čem stojí bezpečnost – podvrženým DNS záznamům je dobré předcházet pomocí DNSSEC, ale stále se s nimi musí počítat a nelze brát DNS jako nějaký jediný zdroj pravdyPokud se na klientské straně prosadí DANE/TLSA, tak na tohle můžeš hezky rychle zapomenout.
už jen proto, že síťový provoz jde přesměrovat i na úrovni IP adres, není potřeba podvrhovat DNS odpovědi.Vážně si myslíš, že účelem DNSSEC je jen chránit odpovědi na A/AAAA/CNAME dotazy?
Taková situace by se rovnala SSL certifikátům, kde je jedna celosvětová kořenová autorita + podřízené autority TLD registrátorů + podřízené autority registrátorů druhé úrovně, kteří ti podepíší certifikát.V kontextu TLS dělá DNSSEC to, že svazuje (ideálně vlastní) certifikační autoritu s daným DNS podstromem a umožňuje definovat hierarchii takových autorit na úrovni DNS. V jakém uzlu toho DNS stromu trust ukotvíš je věc provozního rozhodnutí, přičemž existuje globální trust anchor, která umožňuje se bez větší námahy bránit konvenčním útokům. Situace v DNSSEC je tedy velmi odlišná od situace s ad hoc certifikačními autoritami, což slouží jako důvod k nasazení DNSSEC i jako důvod k jeho kritice. Tvrzení, že je situace stejná je nebezpečný nesmysl.
Kde navíc dochází k nebezpečné koncentraci moci (jeden subjekt si může jednak vydat certifikát na tvé jméno a jednak může nasměrovat tvůj síťový provoz k sobě a dělat MITM).Ano, veřejná DNSSEC hierarchie je shodná s DNS hierarchií a lze na ni proto vést společný útok. Na druhou stranu veřejné certifikační autority rovněž vycházejí z informací o vlastnictví domény, které se získávají od těch stejných subjektů, a k tomu ještě jsou
Pak tedy až tolik nechápu ti útoky na systemdVyznat se v kritice systemd je snad těžší než se vyznat v systemd samotném.
Bagatelizovat toto na úroveň denial of service je nebezpečný omyl.
Já bych spíš řekl, že nebezpečný omyl je se bezmezně spoléhat na DNSSEC.
DNS není nic nezbytného, natož pak DNSSEC, jde to i bez něj, můžeš používat klidně jen IP adresy, nebo si držet seznamy strojů a IP adres v nějakých textových souborech (ostatně tak se to dřív dělalo), a počítače a Internet taky fungovaly. O tom ta bezpečnost prostě není. Navíc DNS tu nemusí být navěky, tahle globální hierarchie má i své nevýhody, třeba se časem rozšíří něco víc P2P…
Pokud se na klientské straně prosadí DANE/TLSA, tak na tohle můžeš hezky rychle zapomenout.
Musím? Nemusím. To že nějaká technologie existuje, ještě neznamená, že jí budu bezmezně důvěřovat. DANE/TLSA je lepší než nic – např. když se budu připojovat na neznámý nedůležitý SSH server a budu fakt líný kontrolovat otisk – pak je lepší kontrola přes DNSSEC, než to jen odbouchnout. Ale pokud to bude něco kritičtějšího, tak se na tenhle kanál fakt spoléhat nedá. Radši si nechám od několika subjektů (lidí, služeb) potvrdit otisk klíče daného serveru – pošlou mi ho podepsanou GPG zprávou (samozřejmě by se to dalo/mělo zautomatizovat) a tahle síť důvěry je mnohem lepší a flexibilnější řešení, než nějaká centrální hierarchie typu DNS nebo klasické CA, kde lze informaci podepsat jen jedním subjektem, nelze napojit víc podpisů a spočítat nějakou celkovou důvěryhodnost.
Vážně si myslíš, že účelem DNSSEC je jen chránit odpovědi na A/AAAA/CNAME dotazy?
Proč tak útočně? Stačí si přečíst hned další větu.
V kontextu TLS dělá DNSSEC to, že svazuje (ideálně vlastní) certifikační autoritu s daným DNS podstromem a umožňuje definovat hierarchii takových autorit na úrovni DNS. V jakém uzlu toho DNS stromu trust ukotvíš je věc provozního rozhodnutí, přičemž existuje globální trust anchor, která umožňuje se bez větší námahy bránit konvenčním útokům.
Tohle je taková teoretická možnost. Ale je to značně nepružné – překlad DNS se dělá na systémové úrovni, kdežto seznam důvěryhodných CA si můžeš spravovat i na úrovni uživatele nebo jedné aplikace.
V případě útoku by běžně stačilo zatlačit na jeden subjekt (na libovolné úrovni té hierarchie) a na jednom místě si zmanipuluješ jak A/AAAA záznamy, aby sis nasměroval provoz na svoje MITM servery, tak i otisky klíčů, aby oběť věřila těm tvým. Pro klasické CA se vyvinuly různé obranné mechanismy (např. kontrola změny CA oproti dřívějšku nebo kontrola certifikátu z různých částí Internetu). Pokud by DNSSEC měl být náhradou, bylo by potřeba tohle dovyvinout, znovu vynalézt kolo a dostat se po letech zhruba tam, kde jsme teď s CA.
Situace v DNSSEC je tedy velmi odlišná od situace s ad hoc certifikačními autoritami, což slouží jako důvod k nasazení DNSSEC i jako důvod k jeho kritice. Tvrzení, že je situace stejná je nebezpečný nesmysl.
Nebezpečný nesmysl je brát DNSSEC jako náhradu klasických CA nebo pavučiny důvěry. Tohle DNSSEC nemůže nabídnout a pokud do něj někdo takové naděje vkládá, bude velmi zklamaný.
U X.509 můžeš v certifikátu CA omezit domény, pro které smí tato CA vydávat certifikáty – viz Name Constraints:
indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names.
můžeš pomocí nich tedy realizovat i ten scénář, který popisuješ výše – jedna kořenová globální CA + CA pro jednotlivé TLD + CA pro další úrovně. Globální autorita by podepsala certifikát CZ.NICu, CZ.NIC by podepsal certifikát tobě (na základě vlastnictví nějaké .cz domény) a ty by sis vydával svoje certifikáty nebo pod sebou vytvořil další CA pro subdomény/zóny. Každá CA by byla omezená (viz Name Constraints výše) tak, aby mohla vydávat certifikáty jen pro svoji část stromu.1
Pokud by DNSSEC chtělo být náhradou za klasické CA, je to úplně zbytečné a nesmyslné znovu vynalézání kola (téhož jde dosáhnout v rámci již existujících standardů – X.509 – viz výše a nebylo by potřeba chrlit standardy nové). To by ale bylo velmi hloupé. Já ho proto jako náhradu neberu – beru ho jako doplněk, jako další kanál, kterým můžu ověřovat otisky a o něco zvýšit bezpečnost. Pak je to užitečná technologie.
Na druhou stranu veřejné certifikační autority rovněž vycházejí z informací o vlastnictví domény, které se získávají od těch stejných subjektů, a k tomu ještě jsou
Nikoli. CA vycházejí ze svých certifikačních politik a do nich si můžou napsat, co chtějí – technologie je v tom nijak neomezuje. Nějaká CA ti tedy může vydat certifikát třeba jen na základě toho, že jsi zachytil e-mail odeslaný na adresu webmaster@example.com, zatímco jiná CA po tobě bude chtít telefonickou kontrolu nebo kontrolu nějakých dokladů (např. zda jsi občanem, za kterého se vydáváš, nebo firmou založenou v určitém státě) nebo po tobě můžou chtít osobní návštěvu, nebo se naopak přijedou podívat za tebou jestli a jak existuješ – to už je na nich. Je to i formalizované do různých úrovní ověření: DV (domain validation), OV (organization validation), EV (extended validation). Uživatel má k dispozici řadu informací, jak o CA, tak o subjektech, kterým byl vydán serverový certifikát, a podle toho se zařídí – něčemu by měl věřit více, něčemu méně, to už je na něm a na jeho potřebách.
[1] ještě doplnění: kdo by nechtěl věřit té „židozednářské“ globální CA, ten by si prostě vytvořil vlastní nezávislou CA a vlastní hierarchii/strukturu – což by bylo zvlášť zajímavé při uvedení RFC 4158 do praxe – to by totiž mělo přinést Certificate Graph místo klasického Certificate Chain a budovat i jiné struktury než jen stromy – podobně jako pavučina důvěry u GPG
Tyhle komponenty jsou kritické, ale spíš ve smyslu DoSu než ve smyslu narušení bezpečnosti (resp. měly by být).Jak už psal snajpa, mnohé bezpečnostní mechanismy zahrnují rozhodování podle aktuálního systémového času. Třeba zrovna Kerberos a PKI. To stejné platí pro ověřené informace z DNS. Nezáleží na tom, které technologie se tobě líbí nebo nelíbí, ale které se reálně používají. Mezi ty lze řadit minimálně Kerberos, PKI a v případech, kdy se server vůči klientovi neautentizue i DNS (bez DNSSEC). Vzhledem k současnému rozšíření zde hraje DNSSEC druhořadou roli. Nemluvím tady o tom, jak si Franta nebo Pavel myslí, že by se věci měly dělat, ale o reálných hrozbách, kterým systemd a jiný software čelí. Taky by bylo fajn, kdybys napříště alespoň trochu četl, na co odpovídáš, aby většina tvého dlouhého příspěvku nebyla mimo kontext. Ale chápu, že je těžké srovnávat dvě technologie z nichž jedna je široce používaná a druhá nikoliv.
Tvůj příspěvek jsem četl celkem důkladně a k ocitovaným pasážím jsem napsal svoje poznámky. Ty jsi bohužel v tomto komentáři nic zajímavého ani k věci nenapsal.
Nesprávná konfigurace systémového času má vliv na mnoho kryptografických nástrojů a protokolů (třeba zrovna Kerberos, jak píše snajpa).Tam jsou i jine aspekty. Zmen nastaveni systemovych hodin, a spusti se treba vytvareni snapshotu a zalohovani, zpomali to server, zpusobi ukladani dat se spatnymi timestampy. Hadam, ze u serveru pripojeneho treba k burzovnim systemum to muze mit neprijemne dusledky.
Proto jsem psal:
Navíc by to mohlo fungovat tak, že NTP démon smí nastavovat čas jen v nějakém intervalu (v jakém se běžně rozcházejí HW hodiny) a pro větší posuny by byla potřeba dodatečná autorizace.
Chyba je už v tom, že nějakému jinému serveru (byť tvému vlastnímu) dáš moc, aby ti výrazně přeřídil hodiny. NTP démon by prostě měl mít právo jen dolaďovat odchylky, ne zásadně posouvat čas.
Jak vlastně tyhle komponenty systemd vypadají?Tak navzdory tvrzeni skarohlidu tyto veci vetsinou nejsou nacpane do PID1 a jsou zabezpeceny standardnim zpusobem.
Je možné, aby běžely pod jiným uživatelem s omezenými právy a ideálně ještě omezené něčím jako AppArmor?U Fedory/RHEL7 jsou omezeny SELinuxem, coz je silnejsi model nez standardni DAC.
Tak teď ještě aby bylo možné nějak bezbolestně vyměnit implementaci démona (DNS, NTP atd.) za jinou (neříkám, že ta výchozí je špatná, ale tahle možnost musí zůstat zachována) a pokud možno mít nemuset některé části ani instalovat… a stane se ze mně ještě fanoušek systemd
naivní je opensource modla jako taková.S tím souhlasím a preferuju, když lidé k open source dojdou pragmatickou cestou.
Zato ve vodách linuxu se vesele míchají čím dál tím větší sračky pod vedením Šiléného Kloboučníka a jednoduché přehledné věci se nahrazují všeobjímajícím molochem s ještě s menší šancí na celkovou auditovatelnost...atd atd...Pokud máš nějaký geniální nápad jak z toho ven, tak sem s ním ;).
Pokud máš nějaký geniální nápad jak z toho ven, tak sem s ním ;).Hus, ticho!
IMHO jinak nez vzdelanim vyvojaru to nepujdeVzdělávat můžeš jen vývojáře, kteří mají ke vzdělávání motivaci, ne ty, kteří si myslí, že už jsou nejlepší na světě ;).
Musi pochopit, ze pridavani komplexity do kodu, ktery dela +- podobnou praci, co jednodussi kod pred tim, je spis prohra pro vsechny, nez pokrok.Bohužel je to pro některé výhra, vzhledem k tomu, že se tím jakožto správci kódu stávají nepostradatelnými. Podle mě je jedinou cestou prostě přijmout prohru a zajistit, aby bylo na trhu dostatek expertů, kteří tomu kódu rozumějí. Ignorovat třeba zrovna systemd je z hlediska dalšího vývoje linuxového ekosystému sebevražda.
Musi take pochopit, ze je lepsi si zprelamat ruce a naplivat do nich, nez delat odflaknutou praci.To je naivní představa. Vývojáři jsou za odfláknutou práci velmi dobře placeni a často je po nich i přímo nebo nepřímo vyžadována. Třeba já jsem si nejvíc nasral do bot, když jsem protlačil do upstreamu automatické testy, valgrind checky a další věci v době, kdy jsem měl odevzdávat kód, který v těch testech selhával. Mojí motivací pro ty testy bylo abych odevzdal kód, který bude pokud možno zcela v pořádku. Skutečným výsledkem byl konflikt kvůli odevzdání kódu se zpožděním. Kvalita software z rukou vývojáře (tedy než dojde na testování ať už komunitou nebo najatými testery) je tak podle mě v první řadě záležitostí morálky a odvahy toho kterého vývojáře. Samozřejmě dlouhodobý pobyt v tržním prostředí dle Franty nebo asijských trhovců člověka deformuje a jeho vnitřní zásady do jisté míry otupuje.
Opensource je predevsim hromada lidi, ne kod samotny - chyby opensource kodu vychazi z chyb techhle lidi.Hodně lidí v poslední době v diskuzích upozorňuje na to, že je open source kromě toho i hromadou firem. Ty firmy jsou sice složené z lidí, ale mají určitou strukturu, značně odlišnou od různých dobrovolných seskupení a jednotlivců.
Chcete nápad a pokud vám jej někdo napíše, tak útočíte.Za to se omlouvám, je vcelku běžné, že diskuzi na Abclinuxu nevěnuju 100% svého vědomí a uteče mi kontext. Mám zájem o přátelskou diskuzi a dal bych pokud možno přednost tykání alespoň v rámci té diskuze. Skutečně jsem nadhodil dotaz na geniální nápad. Osobně si ale nemyslím, že působením prostřednictvím zaměstnanců na vedení jedné komerční firmy je tím geniálním nápadem. Komunita přijala systemd velmi vřele a mnohé jeho části jsou (po bližším prozkoumání) technicky vyspělejší než vše ostatní, co je na open source trhu k dostání. Komunita podle všeho projekt přijala velmi vřele, na to o jak zásadní změnu se jedná. Lze říci, že se jedná o fenomenální úspěch, ať si o tom kdo myslíme cokoliv.
nebýt RedHatu, je systemd pouze jedním z mnoha neškodných obskurních experimentů, které si sem tam pár nadšenců vyzkouší, aby se pak vrátili k normálu...Docela by mě zajímalo, co bylo podle tebe tím klíčovým okamžikem nebo aktem, kdy tato konkrétní společnost způsobila, že se z neškodných obskurních experimentů stal mainstream. Já osobně do toho takhle daleko nevidím a dá se říct, že jsem přišel k hotovému.
Komunita přijala systemd velmi vřele a mnohé jeho části jsou (po bližším prozkoumání) technicky vyspělejší než vše ostatní, co je na open source trhu k dostání. Komunita podle všeho projekt přijala velmi vřele, na to o jak zásadní změnu se jedná. Lze říci, že se jedná o fenomenální úspěch, ať si o tom kdo myslíme cokoliv.+1
Jde o to, že nebýt RedHatu, je systemd pouze jedním z mnoha neškodných obskurních experimentů, které si sem tam pár nadšenců vyzkouší, aby se pak vrátili k normálu...To je nesmysl. systemd se prosadil predevsim pro to, ze pro podobnem reseni je poptavka a prostor a pokud by to neobsadil Lennart a Red Hat, udelal by to nekdo jiny. Naslapnuto na to mel Canonical a Usptart, ale podelali to.
vysvětlí jim, že ultrašílené neunixové bastly jako je např. systemd jsou cestou do peklaUnix je fajn koncept, ale neni to dogma neznamena ze se nebude dale vyvijet. Bastly byly casto predevsim init scripty.
A final message to the people who keep complaining
You can yell all you want, yet Arch Linux will slowly move towards systemd. Initscripts will probably keep working for a long time, but they will eventually disappear. It doesn’t help if you insult us for it. It doesn’t help if you state a thousand times that you leave Arch over “the systemd issue”. We don’t care. You can either embrace systemd and enjoy all its advantages, provide an alternative or use another distribution. We don’t care. We make Arch for ourselves, and for the ones that like it like we do. Whether we have a million users or one hundred users – we will keep making it the distro we like. Deal with it.
A na LibreSSL se kidá hnůj, byť alespoň jejich myšlenka má správný směr.Já osobně nemám s LiberSSL žádný problém a hnůj kydám leda tak na různé Nostradamy, kteří se tváří, jak teď OpenBSD převezme kontrolu a zachrání svět. Na OpenBSD se dívám podobně jako na křesťanství, bůh (projekt, vývojáři) mi nevadí, ale ti věrozvěstové mi kolikrát hrozně lezou na nervy. Ne nadarmo se říká show me the code
Smula, ale OpenBSD zachranovat svet nebude. Jen mu zase pro jednou ukaze jak je neschopny a jaky je ve skutecnosti bordel v IT.Jojo, OpenBSD zase jednou světu ukáže, a svět si toho jako obvykle zapomene všimnout ;).
To je problem svetaA přesně to jsem si myslel.
"Oracles support is... worse than anything. We just stopped calling. It's better to live with the bugs than waste man hours on that cunt licking whore Oracle calls support. I'd rather traverse the 7 layers of hell in a thong than ever talk to Oracle support about anything ever again.
Oracle is Satan. They will fuck you in the most evil way imaginable. Whatever alternative you think will get you away from them, half way through the migration project oracle will buy the alternative company out. If torturing puppies were profitable, Oracle would have a puppy torturing product as a SASS. In fact, if torturing puppies just made the product slight less helpful to you, they'd probably do it as well..."
Treba kvuli BSD vecem v Apple kernelu pf firewallu z OpenBSD v Mac OS X Cisco iOS Juniper OS Opera Mini (domaci ukol o rozsahu nasazeni OpenBSDa proste tak by se dalo pokracovat do nekonecna. Je dobre, ze si vybiraji kvalitu, sice licence nebo treba i NDA neumoznuje ukazovat i jeste dokonce zajimavejsi pripady, ale o to tady stejne nejde. Uprednostnim kvalitu o ktere svet nevi, nez radoby kvalitu co se co dva dny rozsype, ale mele o ni kazdy a kdekdo tvrdi, ze tomu rozumi) M:tier a jeho nasazeni OpenBSD ve velkych spolecnostech NetApp a EMC a jejich podpora FreeBSD Google zamestnavajici a nabirajici posledni 2 roky cim dal vice BSD vyvojaru, ci implementujici veci z ruznych BSD do Androidu misto veci z Linuxu ci menici licence na vice BSD friendly Netflix zintenzivnujici nabor BSD adminu a vyvojaru Sony a BSD v Playstation 4 NetBSD CPE routery PDF CradlePoint, ktery u vyssich modelu presel uz pred nejakou dobou z Linuxu na NetBSD a dodavaji nejvice pro Verizon a AT&T dalsi Japonci portujici NetBSD na Tilera CPU [PDF] (zajimave i kvuli vyuziti rump virtualizace) Minix3 implementuji libc a userland z NetBSD medicinska firma pouzivajici pouze OpenBSD v infrastrukture
tak by se dalo pokracovat do nekonecna.Bude to jen zanedbatelny zlomek soucasneho nasazeni Linuxu.
Je dobre, ze si vybiraji kvalitu,A to presvedceni, ze se jedna o vyjmecne kvalitni system, berete stale kde?
Já nevím, na co si všichni ti obdivovatelé BSD stěžují. Vždyť jediné, co Lennart dělá je, že po vzoru BSD sjednocuje základní systém (i když kromě kernelu, libc apod) do jednoho (jednotně spravovaného) stromu se zdrojovými kódy. Jako by toho tam oni neměli naplácaného mnohem víc.To nebylo ani vtipne. Nevsim jsem si ze by u Free/Net/OpenBSD dochazelo k migraci systemovych sluzeb do jedne mega-aplikace, odepsani jejich alternativ vytvorenim noveho nekompatibilniho api, opousteni textovych logu ve prospech binarnich, zahazovani shell scriptu a zavedeni noveho formatu konfiguracnich souboru, vynucovani zmen v userlandu nekompatibilitou ve sprave prihlaseni nebo zasilani zprav a podobne.
Nejak mi prijde, ze driv se v Linux komunite vubec nepochybovalo jak genialni jsou principy unixovych systemu, ze kvuli tomu navrhu prezily 40 let navzdory konkurencnim OS ktere razily opacny pristup (komplexita, automatizace), jak je dobre se drzet standardu a prenositelnosti mezi platformami. Kam se podela ? Zase uz zustava jen diktat penez a tupe vetsiny ?
Ne, kozy si delaji ti, kteri si mysli, ze tenhle bordel muze napravit nekdo jiny nez LibreSSL.Já si myslím, že to nemůže napravit ani LibreSSL. Což sice striktně logicky vzato tvému tvrzení odpovídá také, ale nejspíš jsi to tak nemyslel.
Konecne se zacalo delat review.Je to dost děsivé. Vrhlo se na to relativně pár dobrovolníků a za nějaký měsíc tu máme snad deset kritických chyb (myslím tím všechny SSL knihovny dohromady). Myslím, že přesně takový review, akorát bez zveřejňování výsledků, už udělal někdo před pár lety v nějaké té NSA, Gammě nebo VUPENu.
Je to dost děsivé. Vrhlo se na to relativně pár dobrovolníků a za nějaký měsíc tu máme snad deset kritických chyb (myslím tím všechny SSL knihovny dohromady). Myslím, že přesně takový review, akorát bez zveřejňování výsledků, už udělal někdo před pár lety v nějaké té NSA, Gammě nebo VUPENu.
Mě přijde děsivé něco jiného. O MD5 se už 18let (10let už zcela 100%) ví, že je zranitelná. Dodnes ji lidé používají a dodnes jsou schopni se hádat o tom, že na jejich použití je to ok. SHA1 to má nahnuté už taky pár let. Jako by to nikoho nezajímalo. RC4, už si ani nepamatuju, kdy jsem tom četl poprvé.
A "všem" je to úplně putna. Do nových projektů se hezky dá MD5, protože v té 15let staré knížce (o PHP) je snad na každé druhé stránce. Této funkce je nezbavíme ještě hezky dlouho.
Potom visí na abclinuxu anketa o tom, zda lidé "po Snowdenovi" změnili své chování. Jako upřímně řečeno co Snowden vlastně řekl? Že NSA odposlouchává? No to fakt je novinka (projekt Echelon se už hodně dávno dostal do subkultury a do kdejakého filmu). Jo jako já mám pocit, že "všichni" (v anketě 93%) najednou prostě spadli z Marsu, nikdy na Zemi nebyli a najednou musejí měnit své chování. (Sorry za ostřejší tón, ale tohle mě prostě chladným nenechává.)
Takže všechny tyhlety explity ... ano, je hezké, že se ten software opravuje a audituje, ale k čemu to je, když ti admini použijí protokol / šifru / velikost klíče / podpisový algoritmus apod, u kterých je (roky) nalezené oslabení.
Mě přijde děsivé něco jiného. O MD5 se už 18let (10let už zcela 100%) ví, že je zranitelná. Dodnes ji lidé používají a dodnes jsou schopni se hádat o tom, že na jejich použití je to ok.MD5 je jenom hashovací schéma. Zranitelné může být jen její použití závislé na předpokladu některé vlastnosti, která už nelze v praxi aplikovat. Nevidím důvod překotně nahrazovat MD5 tam, kde se na žádné takové porušené vlastnosti nezávisí.
Nevidím důvod překotně nahrazovat MD5...viz
Do nových projektů se hezky dá MD5, protože v té 15let staré knížce...což můžu potvrdit, bohužel i dnes existuje software. který v aktuálních verzích podporuje jen MD5 nebo ji má jako výchozí volbu -- ne jako jeden z mnoha hashovacích algoritmů (pro lidi, kteří mají databázi plnou starých hashů nebo jiná historická data), ale jako jediný/výchozí algoritmus.
Jak by to vyresil MAC?Vůbec nijak, pokud by to nebyl MAC mezi jednotlivými moduly mikrokernelu. Ale little.owl je troll
A jak vubec MAC jako takovy vyresi design chyby celeho IPv6, ktery je sam o sobe hruzaPříklady toho, v čem je hrůza? Teda jo, je stejná hrůza jako IPv4 - takhle jsi to myslel?
ale to je cele, vysledek je porad nebezpecnyJakkoli zpackaný protokol nemůže způsobit, že při jeho parsování přeteče buffer.
Nikde netvrdim, ze MAC je resenim exploitu v [monolitickem] kernelu; tvrdim ze chybejici MAC v OpenBSD je vyraznym nedostatkem v bezpecnosti systemu, spolu s pomalym cyklem security updatu.Jak by to vyresil MAC?Vůbec nijak, pokud by to nebyl MAC mezi jednotlivými moduly mikrokernelu.
Ale little.owl je trollJiste..
Jiste.Ještě řekni, že nejsi ;).
Tonouci se stebla chyta? IPv6 DoS specificky pro OpenBSD z roku 2007 (tehdy siroce rozsirene adresni schema) jako security bug? Ale no tak, OpenBSD bug potvrdilo, ale DoS neni security problem. Je to bug, otravny a klidne i neprijemny, ale security?Jen DoS, ano?
...
2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain.
2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
2007-03-05: OpenBSD team notified of PoC availability.
2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.
...
Jenze current OpenBSD je neco jako hyper LTS jinych OS, takze to nejak nevadi.Dalsi vtip, ze? Rolling distro s pomalymi updaty.
Ale rict "rolling distro s pomalymi update" dokonale odhalilo neznalost procesu.Ale prd. Opet u prekrucovani nazvoslovi. Ono je to jeste horsi, current je ve sve podstate i vetev, kde se provadi vyvoj, takze je to cas od casu rozbite.
Chtelo by to zmenit profil. Uzivatel s nickem little.owl je uz proflaknuta znacka ;)
njn, kto nic nerobi, nic nepokazi...…a keď mu za tie chyby ešte niekto zaplatí. No dobre, je to moja konštrukcia, moja domienka, ale začína sa mi to zdať podozrivé. Buď je dotyčný riadny amatér, alebo zažíval ťažké obdobie (ktoré mu bránilo plne sa sústrediť), alebo to nie sú chyby. A keďže medzi prvou a poslednou chybou uplynulo 14 rokov, tak to bolo sakra dlhé ťažké obdobie :P Mimochodom, nekontroloval po ňom kód tiež ten istý človek?
ale upřímně.. koho to zajímá?Mě.
Ten kdo potřebuje zpracovávat důvěrná data (a teď nemluvím o firemní korespondenci), ten si je toho vědom a dle toho se zařídí.Nevšiml jsem si. Ono to možná může souviset s tím, že vlastně není moc možností, jak se zařídit. Nějaké nápady?
Nějaké nápady?Zatim mi prijde jako nejjistejsi tahle rada Bruce Schneier, the air gap:
3) Assume that while your computer can be compromised, it would take work and risk on the part of the NSA – so it probably isn't.Proste mit pocitac, ktery nikdy nebyl a nebude pripojen k jakekoliv siti a na nem citliva data. Pro pripojeni k netu pouzit jiny pocitac a pocitat s tim, ze ten bezpecny neni.
If you have something really important, use an air gap. Since I started working with the Snowden documents, I bought a new computer that has never been connected to the internet. If I want to transfer a file, I encrypt the file on the secure computer and walk it over to my internet computer, using a USB stick. To decrypt something, I reverse the process. This might not be bulletproof, but it's pretty good.
A na tom oddelenom PC by mal byt doveryhodny SW.Premyslim nad mojim prazdrym listem duveryhodnych OS. Pointa je v tom, ze at je tam cokoliv, bez pripojeni k netu je to velmi obtizne kompromitovat - v pripade fyzickeho pristupu jste asi v haji tak jako tak.
Premyslim nad mojim prazdrym listem duveryhodnych OS.Doporučuji SqueakNOS - je dostatečně exotický, a přitom se v něm dá pořád lidsky programovat.
Since I started working with the Snowden documents, I bought a new computer that has never been connected to the internet.Tohle nechápu -- vždyť ty dokumenty už NSA má (že jo) a stejně je chtějí zveřejnit (takže by nevadilo, kdyby si je někdo přečetl o trochu dřív).
Tohle nechápu -- vždyť ty dokumenty už NSA má (že jo) a stejně je chtějí zveřejnit (takže by nevadilo, kdyby si je někdo přečetl o trochu dřív).Oni vubec nevedili co Snowden ma a co uvolnil, The Guardian si nechal udelat review a zverejnil jen nektere casti. Nechteli nekoho ohrozit - mohla by to byt zaminka proti nim legalne zasahnout. Kdyz to bylo uvolnovano postupne, a nebylo jasne, co se praskne priste, slo velmi tezko chranit sve zajmy a pripravit duveryhodnou lez. Proste, vedet co vsechno uniklo by bylo uzitecne a podle vseho to dodnes nevi a ne vse bylo zverejneno/uvolneno.
bought a new computer that has never been connected to the internetAsi mi neco unika... proc kvuli tomu kupovat novy PC ? preinstalovat OS budes muset stejne, leda ze bys veril tomu OS co tam da vyrobce cili woknum... Navic bych mnohem vic veril starsim PC ze nebudou mit HW backdoor. V tech novejsich je nejspis backdooru (HW i SW) pet na kazdy prst
Ten kdo potřebuje zpracovávat důvěrná data (a teď nemluvím o firemní korespondenci), ten si je toho vědom a dle toho se zařídí.
Chroustat Vernamovu šifru na nějakém jednočipu… Jakkoli to může znít bláznivě, je to asi nejbezpečnější cesta. A mít k tomu připojený jednoduchý LCD displej a vlastnoručně vyrobenou klávesnici. Případně i mechaniku na děrné štítky/pásky. Pak už to jen dobře odstínit, napájet z baterií a mělo by to být v pohodě.
a/nebo mít nějaký meta-jazyk, ve kterém bys popsal formát/protokol/algoritmus, a pak z toho vygeneroval bezpečný zdroják v různých jazycích
Mě napadlo něco jako behaviorální testy, kde se nadefinuje co to má dělat a pak se to fuzzuje a krmí daty a sleduje se, jestli to náhodou nedělá co nemá. Což předpokládám dělá ten Coq.No, ono by možná dost pomohly i praktické věci jako třeba unit testy obsahující všechny možné špinavosti, pořádná statická analýza a podobně...
Nerozhoduje, ale ma velky vliv. Staci se podivat, co stoji za vetsinou CVE a pak najednou zjistite, ze plno z nich by se dalo eliminovat pouzitim neceho jineho.Setkavam se s kodem od jinak velmi chytrych lidi, kteri vyvinou algoritmus v Matlabu, pak to napisi v C/C++, neco obludneho a my to mame integrovat na cilovou platformu. I prase by z toho nekdy poblilo a bez detailni znalosti algoritmu to nejde snadno prepsat. Ale jadro je ten algoritmus, programovaci jazyk je jen nastroj, pozlacena lopata, nastroje by mely byt designovany tak, aby sly snadno pouzivat, i temito lidmi, bez zbytecnych chyb.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.