Hlavní navigace

Ve správci balíčků APT je zranitelnost umožnující spustit libovolný kód

22. 1. 2019

Sdílet

Debian logo Autor: Debian

Bezpečnostní výzkumník Max Justicz dnes publikoval detaily zranitelnosti správce balíčků APT. Ten je používán v Debianu, Ubuntu a v dalších odvozených distribucích. Zranitelnost spočívá v nedostatečně ošetřeném vstupu ze sítě při zpracování HTTP přesměrování během stahování balíčků. Zranitelnost dostala označení CVE-2019-3462 a vysokou míru naléhavosti.

V tuto chvíli jsou již k dispozici opravené verze pro DebianUbuntu. Pokud se bojíte zneužití zranitelnosti během aktualizace, je možné na staré verzi vypnout podporu HTTP přesměrování, čímž se zranitelnost zablokuje za cenu nepodpory některých zrcadel, která přesměrování používají:

$ sudo apt update -o Acquire::http::AllowRedirect=false
$ sudo apt upgrade -o Acquire::http::AllowRedirect=false

Max Justicz ve své analýze také nabádá správce distribucí, aby jako výchozí protokol pro přenos balíčků použili HTTPS. Sice to není nezbytné z hlediska integrity balíčků, zabránilo by to ale zneužití takovéto zranitelnosti útočníkem na cestě; samotná zrcadla by samozřejmě zranitelnost mohla zneužít úplně stejně.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 23. 1. 2019 7:24

    ChoŤ toPiČe (neregistrovaný)

    Není těch děr v Linuxu nějak hodně ? Tohle musí být pro studenty dost demotivující.

  • 23. 1. 2019 9:28

    Vanek (neregistrovaný)

    Bohuzel to uz je udel opensource. Tech der je radove vice nez u proprietarniho kodu. 90% der a chyb je odhaleno pouze nahlednutim do zdrojaku pripadne nejakym analyzatorem kodu. To uz se dostavame k filozoficke otazce jestli neodhalena dira je dirou kdyz o ni nikdo nevi ? Z tohto pohledu je pak proprietarni software mnohem bezpecnejsi. Vyhodou opensource v pripade der je pouze to, ze si to muzes pomerne rychle opravit i sam a nemusis cekat na dodavatele. 99% uzivatelu to stejne nedela a ceka na opraveny balicek z distribuce a tedy tahle vyhoda je efektivne stracena a je to na chlup stejny jako u proprietaru.

  • 23. 1. 2019 10:54

    Vanek (neregistrovaný)

    Napriklad Free Software Bulletin, tak 2 roky do zadu mel clanek presne na toto tema i s nejakymi navrhy jak zlepsit tenhle paradoxni stav (rolling distra a pod.)

  • 23. 1. 2019 11:05

    Lewell (neregistrovaný)

    Něco na tom bude, protože díry podobného typu jako u APT jsou látaný poměrně horkou jehlou řešící důsledek a ne příčinu. Viz nedávné patche řešící spekulativní vykonávání u procesorů kde byl tradeoff propad výkonu. Nějaký ucelený patch přichází obvykle mnohem později. U proprietarního sw, až u odhalení bugu došlo "doma" či "hodnými hackery" tak to můžou nějaký čas držet pod pokličkou a připravit ucelené řešení problému.

  • 23. 1. 2019 11:50

    Přezdívka: * (neregistrovaný)

    Co je to "hodny hacker"? To je jako napsat "dabelsky dabel", hacker je vzdy "hodny" ...

    U OSS se dira take drzi pod poklickou, akorat je vetsi riziko ze na ni prisel jeste nekdo jiny a zneuziva ji, ale to plati i u proprietarniho SW. Chyba se muze vzdy zverejnit az po tom co se nachystaji nebo dokonce zacnou distribuovat opravne patche.

  • 23. 1. 2019 12:00

    PetebLazar (neregistrovaný)

    Proti tomu by se dalo argumentovat, že 90% chyb (číslo je vymyšlené) proprietárního kódu není včas/nikdy rozpoznáno tvůrci a nedočká se opravy/zveřejnění (což ovšem neznamená, že je někdo jiný již neodhalil). Zranitelnosti rozšířených systémů asi budou vcelku cennou komoditou (pro zneužití), takže se s nimi mimo útoky asi moc plýtvat ve prospěch tvůrců/uživatelů nebude.

    Otázkou je, zda nelze výkon či rychlost/rozsah vývoje obětovat ve prospěch kontrol či kvality/testů atd. Co říkají statistiky ohledně zastoupení jednotlivých typů zranitelností?

  • 24. 1. 2019 12:56

    madloki (neregistrovaný)

    U proprietarniho software se chyby mnohem hure detekuji, ma mene (platicich) uzivatel, a prakticky nikdy to nelze predem na zaklade analyzy kodu. Koncovi uzivatele software obvykle netestuji, nemluve o tom, ze nemaji zdrojak, licence zakazuje disassembling, licence zakazuje hovorit o produktu negativne, poskytnout jej treti strane atp. K oprave takovych chyb, pokud k ni vubec kdy dojde, pak firma pristoupi obvykle tak, ze obvykle pouze skryje projev, ktery umoznil detekci chyby. Je to rychle, levne, neovlivnuje to funkci a dava to pripadne cas adekvatne zareagovat. Pripadne vypusti novou verzi s jinymi vlastnostmi, a nahodna detekce stejne chyby je opet ve hvezdach.

    Adekvatni reakci vyrobce by byla hloubkova analyza a oprava kodu + testovani, ale to je u proprietarniho software velmi drahe, jediny, kdo to muze udelat, je vendor sam, ale ten k tomu soucasne ma i nejvetsi odpor. Casto proto, ze software pochazi z nejake akvizice, autor, ktery by mohl chybu analyzovat a opravit nejsnaze, je uz davno mimo dosah prodejce (a zaplatit nekomu, kdo uz u mne nepracuje, tj najmout ho, je opet drahe), a v podstatate o tom, ze chyba (jeji pricina) v produktu stale zustala nikdo nevi.

    Kdo draze zaplatil za zakoupenou licenci (uzivatel), nestoji o to stourat se (a autorska prava mu to ani neumoznuji) v produktu, ke kteremu nema zdrojaky, naopak stoji o to, aby ho mohl pouzivat az do amortizace, takze bude mit spis tendenci chybu tutlat a nezverejnovat. Prejit na jine reseni jineho vyrobce znamena poprit a znehodnotit investici, to je v bussiness velmi nezadouci stav. Manazersky jde take o selhani, protoze spatny vyber = neci zodpovednost = manager v prusvihu. Cili lide ve vedeni firmy uzivatele rovnez nemaji zajem problem zverejnovat.

    Vynutit si neco na vyrobci je zpravidla nemozne, kazda sw licence obsahuje oddil o zreknuti se zodpovednosti za skody.

    Nejaka komunita, ktera by vyvijela tlak a nutila vyrobce tak fakticky neexistuje, a kdo si to nekoupil, obvykle sanci ani motivaci zjistit, ze v necem, k cemu nema pristup, je chyba, rovnez nema.

    U opensource to uz jako autor pisete s vedomim, ze zverejnujete zdrojak, ze Vas v pripade uspechu budou uzivatele kontaktovat (a bude jim jedno, ze to uz davno vyvijet nechcete), a taky nestojite o to, aby si z Vas komunita delala prdel, jaky jste programatorsky jelito, nebo Vas nekdo pouzil jako sample do ucebnic a prezentaci na tema, jak se to delat nema. Obvykle pracujete v tymu a predpokladate, ze jak tym, tak pozdeji nekdo dalsi se v tom bude vrtat, procez zdrojaky patricne komentujete. Komunita pak ma k dispozici nastroje, kterymi muze zdrojak prohnat. Kdokoliv chce, to muze vzit, pouzit, podivat se do historie, zkontrolovat. Nejen v pripade zranitelnosti, ale i v pripade neoptimalni funkce nebo chyby bez bezpecnostnich dopadu.

    U komercniho a proprietarniho software se casteji nez v opensource voli pristup "feature, not bug"

    Detekce chyb u opensource je vcasnejsi, castejsi, popis je detailnejsi, presnejsi, a ihned k dispozici je jak oznameni, tak i oprava. Je to nutne za cenu prilisne "medializace" kazde prkotiny, ale zase to indikuje, ze software je pouzivany, stale ve vyvoji nebo alespon v maintenance, a uzivatel tak ma sanci ovlivnit vyvoj i opravy.

    Diky medializaci ma samozrejme i utocnik drive povedomi o problemu, coz vede k tomu, ze je potreba bud opensource nepouzivat vubec, nebo jej pouzivat se vsim vsudy - to jest i vcetne aktivniho monitoringu zprav z komunity, sledovani oznameni zranitelnosti a pravidelneho provadeni update systemu.

    Diky nastrojum typu apticron to vcelku neni problem automatizovat.

    Tahle konkretni zranitelnost neni o nejakem MITM nebo nepouzivani https, ta je o obejiti overovani pgp signatury software. Pokud do tohoto dokazete vnest trust cizimu|modifi­kovanemu zdroji, je pruser, jinak je cely "utok" o nicem.

    Je to stejny problem jako pouzivat https pro overeni zdroje, aniz byste duverovali a proverovali CA a jeho zpusobu vystavovani certifikatu (letsencrypt). Pokud toto nedelate, jde jen o bezpecnost prenosu dat pred zcizenim behem samotneho prenosu, kde to, ze nekdo vidi, jake baliky instaluju (nebo neinstaluju) do systemu je o neco mensi problem. Ne ze by to nebylo spatne, ale neni to problem fatalni.

    Fatalnim problemem je,pokud je mozne podvrhnout trust (pgp klic), nebo nejak zablokovat validaci signatury stazeneho deb balicku.

  • 25. 1. 2019 7:47

    eres (neregistrovaný)

    Děkuji Vám za detailně napsaný názor, ke kterému se připojuji a plně s ním souhlasím.

  • 24. 1. 2019 13:07

    VOV (neregistrovaný)

    To je ale vyjimečná hloupost tvrdit, že opensource má více děr, protože jde nahlédnout do kodu. Takže když by tam nahlédnout nešlo, takže by jako mělo méně chyb jako je to u uzavřeného sw. Co oči nevidí srdce nebolí, takže když se nemůžu podívat do kódu, tak to znamená, že je bezpečný? WTF OMG!!!!

  • 26. 1. 2019 8:57

    Kalo kar

    Přesně, nevidím zlo, neslyšým zlo, zlo tedy nexistuje.