abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 19:22 | Nová verze

Byla vydána verze 11.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností i s náhledy v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
včera 13:00 | Komunita

Do 30. října se lze přihlásit do dalšího kola programu Outreachy (Wikipedie), jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 4. prosince 2018 do 4. března 2019, v participujících organizacích lze vydělat 5 500 USD.

Ladislav Hagara | Komentářů: 72
21.9. 22:22 | Komunita

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 8
21.9. 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
21.9. 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 11
21.9. 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
21.9. 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
20.9. 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 5
20.9. 21:32 | Zajímavý projekt

Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.

Fluttershy, yay! | Komentářů: 1
20.9. 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (21%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 395 hlasů
 Komentářů: 33, poslední 16.9. 11:55
Rozcestník

Jaderné noviny – 28. 6. 2018: Podpora Control-Flow Enforcement v jádře

15.7. | David Kolibáč | Jaderné noviny | 2358×

Stav vydání jádra. Archivy LKML na lore.kernel.org. Citáty týdne: John Stultz a Dan Carpenter. Podpora Control-Flow Enforcement v jádře.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 27. června 2018

Současné vývojové jádro je 4.18-rc2, vydané 17. června. Linus řekl: „Každopádně jsme na začátku řady kandidátů na vydání, ale vypadá to celkem normálně.“ Kromě toho si postěžoval na vývojáře, kteří zasílají novinky po uzavření začleňovacího okna.

Stabilní aktualizace: 4.17.3, 4.16.18, 4.14.52 a 4.9.110 byly vydány 26. června. Upozorňujeme, že 4.16.18 je poslední aktualizací řady 4.16.

Archivy LKML na lore.kernel.org

LKML archives on lore.kernel.org. Jake Edge. 22. června 2018

Na lore.kernel.org je nyní k dispozici nový archiv příspěvků (od roku 1998) z poštovní konference linux-kernel (LKML). Založený je na public-inbox (článek z února), který umožňuje mj. stáhnout celý archiv přes Git: „Na konci každé stránky jsou URL pro Git clone. Podotýkáme, že archiv LKML je vzhledem ke své velikosti rozdělený do více repozitářů, každý z nich velký 1 GB. Vedle klonování na lore.kernel.org se k těmto repozitářům dostanete také na git.kernel.org.“ Úplné oznámení s informacemi o nové instanci Patchwork a pokyny k odkazování na nový archiv je k přečtení na kernel.org.

Citáty týdne

Quotes of the week. Jonathan Corbet. 27. června 2018

Je to boj, vyvážit nekonečný příliv žádostí o revize naivního nebo jinak nedokonalého kódu s jinými důležitými vývojovými prioritami, takže *opravdu rozumím, jak je to frustrující*.

Navíc je extra otravné vypořádávat se s hromadami momentálních vývojářských žádostí, když se sami musíte věnovat údržbě v dlouhodobém časovém horizontu. Ale v opravdu dlouhodobém časovém horizontu nikdo není správcem věčně a nové olympijské plavce si nikdy nevychováme, když budeme pořád čůrat do bazénu.

John Stultz

Čítač Reported-by jednoznačně říká, že jsi rocková hvězda.

Dan Carpenter

Podpora Control-Flow Enforcement v jádře

Kernel support for control-flow enforcement. Jonathan Corbet. 25. června 2018

Útočníci se od doby, kdy přišli o možnost snadno spouštět kód uložený v paměti s možností zápisu, začali více zabývat „programováním zaměřeným na instrukce návratu“ (return-oriented programming, ROP) a souvisejícími technikami ke kompromitování zranitelných systémů. Útoky ROP využívají kódu v programu, na který útočí, a těžko se jim brání softwarovými prostředky. Tudíž se možnostmi, jak se vypořádat s technikami jako ROP na nižší úrovni, zabývají výrobci hardwaru. Jedním z výsledků je Intel Control-Flow Enforcement Technology [PDF] (CET), která pro obranu před těmito útoky přidává dva mechanismy (stínové zásobníky a sledování nepřímého větvení). Skupinu patchů ukazujících, jak tuto technologii použít k obraně linuxových systémů, nedávno zveřejnil Yu-cheng Yu.

Patche přidávající podporu CET byly rozděleny do čtyř samostatných skupin: podpora a dokumentace CPUID, nějaké práce na správě paměti, stínové zásobníky a sledování nepřímého větvení (indirect-branch tracking, IBT). Současné patche podporují pouze 64bitové systémy a CET pouze v případě kódu v uživatelském prostoru. Budoucí revize by měly odstranit obě tato omezení.

Útoky ROP obecně fungují tak, že se na zásobník načte skupina umělých rámců volání, z nichž každý „se vrací“ do pečlivě zvoleného kusu kódu. Zřetězením těchto „gadgetů“ ROP může útočník vyvolat spuštění dostatku užitečného kódu k tomu, aby ovládl systém. V každém větším programu je „gadgetů“ hojnost a možnost „vrátit se“ doprostřed vícebajtové instrukce tak, že dostaneme zcela jinou posloupnost operací, tomu na systémech s architekturou x86 napomáhá ještě víc. Běžící program samozřejmě může zapisovat na zásobník – ten obsahuje kombinaci informací o řízení toku programu (např. návratové adresy) a jiných dat. Je to právě ta kombinace, která činí útoky ROP proveditelnými.

Jeden způsob, jak tyto útoky zmařit, je přesunout návratové adresy do jiného kontextu, kde s nimi nejde dělat neplechu. To je ústřední myšlenka stínových zásobníků. Ve stručnosti: když jsou stínové zásobníky povoleny, volání funkce uloží návratovou adresu jak na obyčejný zásobník, tak na zvláštní stínový zásobník. Když se narazí na instrukci návratu, návratová adresa se vezme z obou zásobníků a porovná – pokud se neshodují, dojde k chybě. O operace přidání na zásobník a odebrání z něj se stará procesor. Jestliže útočník nemůže zasahovat do stínového zásobníku, mělo by se tak účinně zabránit užití instrukce návratu k odklonu od kýženého běhu programu.

Aby se zabránilo takovým zásahům, stínový zásobník vyžaduje zvláštní zacházení. Alokuje se v rozsahu virtuální paměti a základ adresy se uloží do registru specifického pro model (model-specific register, MSR). Stránky stínového zásobníku musejí mít nastavenu nezvyklou kombinaci bitů: pouze pro čtení, ale dirty. Doposud stav dirty používalo téměř výhradně jádro, a to ke sledování stránek, které bylo potřeba zapsat na fyzické úložiště, ale stínové zásobníky se bez něj neobejdou. Tudíž se ve stránkovacích tabulkách musí alokovat nový bit „software dirty“, který nahrazuje dosavadní hardwarový bit dirty.

Ochrana stínového zásobníku pouze pro čtení by měla útočníkům zabránit v přidávání vlastních zvláštních záznamů – pokud tuto ochranu nelze změnit. Co se toho týče, stínové zásobníky se alokují ve zvláštním druhu oblasti virtuální paměti (virtual-memory area, VMA), který je označen nový příznakem VM_SHSTK. Systémová volání jako madvise(), mprotect(), mremap() a munmap() nad VMA stínového zásobníku odmítnou pracovat. Přibyla skupina nových operací arch_prctl(), které se stínovými zásobníky pracovat budou. Popsán je v tomto dokumentačním patchi. Předpokládá se, že tato — neprivilegovaná – volání se použijí při spuštění programu, aby zásobník připravila. Jedno z nich (ARCH_CET_LOCK) jde použít k tomu, aby se zabránilo vypnutí stínových zásobníků (a IBT).

Stínových zásobníků se dotýká jeden zajímavý problém, a sice jak interagují s retpoline používaným k rušení druhé varianty útoků Spectre. Retpoline nahrazuje nepřímé volání funkce (tj. když adresa funkce se určí za běhu programu) posloupností instrukcí, která blízce připomíná útok ROP, takže nebude fungovat současně se stínovými zásobníky. Intel (v kapitole 4.3 tohoto dokumentu [PDF]) tvrdí, že retpoline není na procesorech s podporou CET potřeba. Doufejme, že se nedočkáme žádných překvapení, která by si vynutila volbu pouze jedné z těchto dvou technologií.

„Programování zaměřené na skoky“ (jump-oriented programming) je technika podobná ROP, ale zneužívá nepřímé skoky a volání funkcí. Jedna možnost, jak tyto útoky výrazně omezit, je zabránit skokům do všech oblastí, do kterých se se skoky nepočítalo. IBT toho dosahuje tím, že přidává dvojici nových instrukcí (endbr32 a endbr64), které slouží jako „žádné“ operace, ale udávají možný cíl nepřímého skoku. Starší procesory bez podpory CET je budou interpretovat jako „žádné“ instrukce. S povoleným IBT bude procesor vyžadovat, aby instrukce endbr byla první po nepřímém skoku: pokud se narazí na něco jiného, dojde k chybě.

Stínové zásobníky by se měly programům, které s návratovými adresami na zásobníku nedělají nic divného, jevit v zásadě transparentní. IBT je ale jiné. Je-li povoleno, spuštěný program musel být přeložen tak, aby na správných místech byly vloženy instrukce endbr. IBT nelze povolit, když patřičně přeložený program vyžaduje knihovnu, která tak přeložena nebyla, v takovém případě se program rozbije. Takže zavaděč ELF na systémech s povoleným CET bude muset krom jiného zkontrolovat, zda jsou všechny knihovny kompatibilní s CET, a CET povolit pouze tehdy, když na to budou všechny komponenty připraveny.

Nicméně, to nepokrývá jeden pozoruhodný případ: program může při spuštění vyžadovat pouze knihovny, které jsou s CET kompatibilní, ale později zavolat dlopen(), aby načetl knihovnu, která s CET nepočítá. V takové situaci připadají v úvahu toliko dvě možnosti: buď CET pro tento proces vypnout, nebo operace selže. Pokud byla vyvolána výše popsaná operace ARCH_CET_LOCK, zbyde pouze druhá možnost. Takže ji lze použít jen za cenu značného rizika rozbití programů, když bude IBT povoleno.

To vedlo k dlouhé diskuzi, zda vůbec ARCH_CET_LOCK dává nějaký smysl. Kees Cook zastával pozici, že bez ní útočníci před provedením útoku zaměří veškeré úsilí na to, jak vypnout CET. Andy Lutomirsky odpověděl, že útočník bude mít ve chvíli, kdy dokáže vypnout CET, beztak moc nad systémem a CET vlastně nic nezmůže. Zatím není jasné, co s tím.

Když odhlédneme od sporů nad těmito detaily, zdá se, že (aspoň mimo říši grsecurity) o funkci CET nikdo nemá starosti. Mělo by to systém učinit výrazně odolnějším vůči některým rozšířeným technikám útoků, a to zřejmě bez obětí v podobě výkonu či pohodlí. Je ale možné, že tato technologie přijata nebude, dokud nedokáže pokrýt i jaderný kód, protože právě na něj se mnoho útoků zaměřuje. Takže na podporu CET v Linuxu nedojde v nejbližší době, ale to platí i pro dostupnost procesorů s CET.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

19.7. 00:43 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Jaderné noviny – 28. 6. 2018: Podpora Control-Flow Enforcement v jádře
Já bych tam rovnou dal servisní procesor, který by kontroloval kroku hlavního procesoru :-D.
ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.