Hlavní navigace

Byla nalezena bezpečnostní chyba v linuxovém jádře

Sdílet

Petr Němec 13. 5. 2014

Bezpečnostní chyba CVE-2014–0196 umožňuje neprávem získat práva roota. Nutno podotknout, že zranitelnosti lze využít pouze s lokálním účtem. Chyba sahá až do roku 2009, kdy bylo vydáno linuxové jádro 2.6.31-rc3 a je zneužitelná i na všech následujících verzích.

V současné době je již připravena oprava a např. pro distribuce Ubuntu byla oprava již vydána.

(Zdroj: arstechnica)

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 13. 5. 2014 20:21

    alfi .

    A teď ještě aktualizovat všechny linuxové krabičky, routery, modemy apod., které vznikly za posledních 5 let a často mají různé "neškodné" default účty bez roota jako guest/guest, user/user apod. Výrobci na to (po pár letech) kašlou, uživatelé ještě víc. Vítejte v děravém světě plném botů a zombie, kde zabezpečení před nevítaným návštěvníkem je v podstatě sci-fi..

  • 13. 5. 2014 22:15

    Milan Keršláger

    Chápu. Kdyby to byly Windows, tak se to nemůže stát! (to byl sarkasmus).
    Zatímco v OpenSource jsou chyby, o kterých nejen víme (nebo se můžeme dozvědět od kohokoliv) a můžeme je i opravit (sic!), tak v komerčním software je spousta chyb, o kterých vědí jen "ti správní hoši" a dozvědět (natož opravit) je prostě nemůžete...
    BTW: Každý router je implicitně chráněn heslem a přístup je obvykle přes jakési WWW rozhraní. K obecně volnému zneužití této chyby byste musel na tom WiFi routeru jednak povolit přístup z Internetu (který je implicitně na těchto routerech zakázán), najít chybu v obslužném software (to webové rozhraní), úspěšně skrze něj nahrát do toho routeru podvržený kód a ten ještě dále úspěšně spustit. Je tedy docela obtížné takovou chybu zneužít...

  • 14. 5. 2014 11:13

    alfi .

    windows nezmiňuju cíleně, tam je škoda mluvit (jsem zvědavý, jak rychle vyřeší těch 80-90% bankomatů na nepodporaném systému).

    linuxové krabičky mají mít zaheslováno a nejlépe úplně schovaný shell, bohužel tomu ne vždycky tak je. nedávno jsem narazil na dvě takové, kde se kdokoliv z LAN (=zkuste to provozovat někde v restauraci nebo penzionu) může procházet po filesystému z nějakého guest účtu, který najde na googlu podle jména krabičky. aneb podobnýma chybama dostane i roota a může si tam dělat, co se mu zlíbí..

    jednoúčelové krabičky na linuxu jsou fajn, chybí tomu ale dlouhodobější podpora výrobců a alespoň občas aktualizace jako na serveru/desktopu, pro běžné franty ideálně plně automatické. jinak si zaděláváme na slušný botnet, o kterém ten franta vůbec ani netuší.

  • 14. 5. 2014 11:20

    Filip Jirsák

    jsem zvědavý, jak rychle vyřeší těch 80-90% bankomatů na nepodporaném systému
    Zaplatí si podporu? Řekl bych, že to jde dost rychle.

    Na druhou stranu, pochybuju o tom, že se ty Windows XP v bankomatech vůbec aktualizují, a také o tom, že je nějaká bezpečnostní díra v Internet Exploreru nebo ve zpracování JPEG souborů nebo v něčem podobném trápí.

  • 13. 5. 2014 23:01

    Filip Jirsák

    Pokud v nějaké té linuxové krabičce měl útočník lokální účet, má roota už dávno, i bez téhle chyby. Zabezpečení proti útoku z lokálního účtu je úplně jiná kategorie, než zabezpečení proti vzdálenému útoku. Proto taky tam, kde to není bezpodmínečně nutné, žádné lokální účty pro cizí uživatele nejsou. A pokud už někde musí být, je snaha uživatele maximálně omezit a pokud možno mu vůbec nedovolit spouštět vlastní kód.

  • 14. 5. 2014 8:59

    Bretislav Wajtr (neregistrovaný) ---.interlan.cz

    Hm, tedy jsem "serverovy samouk", ale docetl jsem se, ze je dobre server pro pristup pres SSH zabezpecit tak, ze:

    0. Pravidelne aktualizovat server
    1. Zakazat SSH prihlaseni pro roota
    2. Vytvorit na serveru dalsi ucet a na ten se prihlasovat (== lokalni ucet)
    3. Obecne zakazat SSH prihlaseni heslem a na ten lokalni ucet se prihlasovat certifikatem
    4. Z lokalniho uctu provadet rootove operace pres sudo

    Odporuje nejak zmineny postup vasi vete "Proto taky tam, kde to není bezpodmínečně nutné, žádné lokální účty pro cizí uživatele nejsou."?

  • 14. 5. 2014 9:59

    Filip Jirsák

    Pokud tam ten lokální účet máte jen vy, ničemu to nevadí. I když mně osobně připadají kroky 1, 2 a 4 zbytečné (ale je to oblíbené téma pro flamewar).

    Pokud na tom serveru mají lokální účty jen uživatelé, kterým můžete důvěřovat (i v tom, že neumožní pod svým účtem spouštět cizí kód – třeba spouštěním shell skriptů přes PHP), nemusíte získání roota z lokálních účtů tolik řešit (samozřejmě nějaké základní zabezpečení by tam mělo být, ne že povolíte každému su na roota i bez znalosti rootovského hesla). Jakmile tam je někdo „cizí“, komu takhle důvěřovat nemůžete, musíte řešit zabezpečení i z lokálních účtů. Typicky např. webhosting, který umožňuje spouštět skripty přes cron nebo přenos souborů přes SFTP – tam už musíte počítat s tím, že se nějaký zákazník ze svého účtu bude pokoušet prolomit k datům jiných zákazníků nebo k získání roota. Takže mu třeba přes cron nedovolíte spouštět libovolné skripty na serveru, ale jen PHP (kde budete mít spouštění skriptů ošetřeno), nepovolíte mu plné SSH, ale jen SCP/SFTP atd.

  • 14. 5. 2014 10:17

    bwajtr

    Chapu, diky moc za odpoved....

    Flamewar zacit nechci, ale mate pravdu, ze na toto tema toho bylo "napsano hodne", abych tak rekl ;)... pro nas obcasne spravce je o to tezsi se v tom nejak vyznat...

  • 14. 5. 2014 18:09

    Milan Keršláger

    Ad 0: po aktualizaci potřebujete ještě restart postižených služeb (nebo reboot), avšak pozor na aktualizaci dynamických knihoven - pak je postiženo vše, co trvale běží používá původní knihovnu
    Ad 1: ssh protokol kamufluje zadávání hesla přidáním vaty do komunikace (při přihlašování), takže pokud uděláte skrze ssh login na běžný účet a pak su/sudo, kamuflace funguje jen na toho obyčejného uživatele a heslo roota je bez kamuflážové ochrany, takže výsledkem je snížení bezpečnosti (např. kvůli odhadu délky hesla roota, rytmusu zadání hesla a tím zúžení slovníkové metody útoku apod).
    Ad 2: pro práci v desktopu je skutečně nutné pracovat s obyčejným účtem, avšak pro správu serveru je to víceméně zbytečné (viz bod 1), avšak pro maximum probíhajících akcí na serveru by měl být speciální obyčejný účet používán (správa databází, cron skripty, spuštění démoni atd).
    Ad 3: VÝBORNĚ! To je první skutečné bezpečnostní opatření.
    Ad 4: není nutné, viz bod 2

    PS: Kterej chytrák tady nastavil, že spam v příspěvku se pozná podle slova B*I*N*G*O?