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í
×
12.10. 15:44 | Nová verze

Po třech letech od vydání verze 5.0 byla vydána nová major verze 6.0 v Javě napsané aplikace pro komplexní návrh rozmístění nábytku a dalšího vybavení v interiérech Sweet Home 3D. Přináší celou řadu novinek. Zdůraznit lze možnost otevírání oken, dveří nebo skříněk. Zmínit lze také novou figurínu s otočnými klouby.

Ladislav Hagara | Komentářů: 8
12.10. 15:00 | Nová verze

Byla vydána nová verze 2018-10-09 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Přehled novinek v poznámkách k vydání. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Z novinek je nutno upozornit na odstranění programu Wolfram Mathematica.

Ladislav Hagara | Komentářů: 2
11.10. 22:44 | Zajímavý projekt

V rámci projektu PRIM (Podpora rozvíjení informatického myšlení), jehož cílem je "podporovat změnu orientace školského předmětu informatika z uživatelského ovládání ICT směrem k základům informatiky jako oboru", byly na stránkách iMyšlení (informatické myšlení) představeny volně stažitelné učebnice a výukové materiály pro výuku informatiky. Videozáznam z tiskové konference na Facebooku.

Ladislav Hagara | Komentářů: 1
11.10. 13:22 | Nová verze

Nadace Free Software Foundation (FSF) zveřejnila na svých stránkách prohlášení k připojení Microsoftu k Open Invention Network (OIN): Je to krok správným směrem. Problematiku softwarových patentů to ale neřeší. OIN pokrývá pouze část svobodného softwaru. Smlouvu s OIN lze vypovědět s 30 denní lhůtou. FSF vyzývá Microsoft, aby 1) jednoznačně potvrdil, že ukončil všechny patentové spory související s Linuxem v Androidu, 2) s členy OIN

… více »
Ladislav Hagara | Komentářů: 2
10.10. 22:22 | Komunita

Bradley M. Kuhn se v příspěvku na blogu Software Freedom Conservancy zamýšlí nad připojením Microsoftu k Open Invention Network. Žádá Microsoft, aby jako gesto dobré vůle a jako důkaz, že to myslí opravdu vážně, sám commitnul zdrojové kódy proprietárního patentovaného souborového systému exFAT pod licencí GPLv2+ do upstreamu Linuxu.

Ladislav Hagara | Komentářů: 30
10.10. 18:11 | Komunita

Microsoft se připojil k organizaci Open Invention Network, zkráceně OIN, založené v roce 2005 za účelem vytvoření a správy portfolia patentů, jeho sdílení a použití v patentových sporech k ochraně Linuxu a open source softwaru. Portfolio patentů se tím rozšířilo o více než 60 000 patentů.

Ladislav Hagara | Komentářů: 8
10.10. 15:25 | Zajímavý článek

Vědci z Národního ústavu duševního zdraví (NÚDZ) v Klecanech experimentálně zjistili (publikace v BioMed Research International), že používání GPS navigace v chytrých brýlích mění strukturu mozku. U testované skupiny došlo už po třech měsících ke snížení počtu spojení mezi hipokampem a ostatními částmi mozku.

Blaazen | Komentářů: 13
10.10. 08:55 | Komunita

Diskusi vyvolala stránka Flatpak - bezpečnostní noční můra (flatkill.org) popisující bezpečnostní problémy technologie Flatpak [reddit, Hacker News].

Ladislav Hagara | Komentářů: 72
9.10. 23:55 | Nová verze

V Orlandu probíhá konference AstriCon 2018 věnovaná Asterisku (Wikipedie), tj. svobodné softwarové implementaci telefonní ústředny (PBX). Při té příležitosti byla vydána nová verze 16 Asterisku a nová verze 15 webového rozhraní k Asterisku FreePBX. Dění na konferenci lze sledovat na Twitteru.

Ladislav Hagara | Komentářů: 0
9.10. 19:00 | Zajímavý článek

Dle příspěvku Jupyter, Mathematica a budoucnost vědeckých článků na svém blogu používá Paul Romer, držitel Nobelovy ceny za ekonomii, Jupyter a Python.

Ladislav Hagara | Komentářů: 8
Přispíváte osobně k vývoji svobodného softwaru?
 (40%)
 (40%)
 (23%)
 (21%)
 (10%)
 (36%)
Celkem 196 hlasů
 Komentářů: 6, poslední dnes 02:46
Rozcestník

Jaderné noviny - 13. 2. 2008

3. 4. 2008 | Robert Krátký | Jaderné noviny | 3819×

Aktuální verze jádra: 2.6.25-rc1. Citáty týdne: Greg Kroah-Hartman, Al Viro. Než skončilo začleňování do 2.6.25... Nová větev linux-next a způsob správy patchů. vmsplice(): jak se dělá lokální root exploit.

Obsah

Aktuální verze jádra: 2.6.25-rc1

link Aktuální předverze je (k 13. 2. 2008) 2.6.25-rc1, vydaná 10. února. Je to obrovský patch. Kromě jiných věcí bude mít 2.6.25 realtimové skupinové plánování, preemptivní RCU, podporu LatencyTop, řádku vylepšení souborového systému ext4, podporu pro protokol controller area network, podporu pro bezdrátové adaptéry Atheros, přepracované systémové volání timerfd(), patche page map, bezpečnostní modul SMACK, regulaci využití paměti v kontejnerech, API pro teplotní regulaci přes ACPI a podporu architektury MN10300/AM33. Vizte spoustu podrobností v krátkém changelogu nebo více podrobností, než je možné strávit, v dlouhém changelogu.

Od vydání -rc1 bylo do hlavního git repozitáře začleněno několik desítek dalších patchů.

Aktuální stabilní verze řady 2.6 je 2.6.24.2, vydaná 10. února. Tato aktualizace obsahuje jediný patch, který opravuje bezpečnostní problém s vmsplice(). 2.6.24.1 byla vydána - s o dost delším seznamem oprav - 8. února.

Starší jádra: 2.6.23.16 a 2.6.22.18 obě vyšla 10. února; také obsahují opravu problému s vmsplice(). 2.6.23.15 vyšlo 8. února s několika desítkami oprav. A 2.6.22.17, také s řadou oprav, vyšlo 6. února.

Citáty týdne: Greg Kroah-Hartman, Al Viro

link

Nezapomínejte, že v současné době jedeme ustálenou rychlostí:
   4000 řádků přidáno každý den
   1900 řádků odebráno každý den
   1300 řádků změněno každý den

-- Greg Kroah-Hartman

  ???? řádků zkontrolováno každý den.

-- Al Viro

Než skončilo začleňování do 2.6.25...

link

Časové okno pro začleňování do 2.6.25 se zavřelo 10. února po začlenění úctyhodných 9450 sad změn. Většina změn začleněných do 2.6.25 byla popsána v prvním a druhém souhrnném článku. Tento třetí díl popisuje posledních 1900 patchů.

Změny, kterých si všimnou uživatelé:

  • Nové ovladače pro:
    • sériové porty založené na SC2681/SC2691
    • časové čipy Dallas DS1511
    • realtimová hodinová zařízení AT91sam9
    • multifunkční čipy Compaq ASIC3
    • paměťové řadiče Cell Broadband Engine
    • paměťové řadiče Marvell MV64x60
    • NAND flash rozhraní PA Semi PWRficient
    • NAND flas řadiče Marvell Orion
    • NAND flash řadiče Freescale eLBC
    • klávesnice Sharp Zaurus SL-6000x
    • tlačítka na aplikačním panelu Fujitsu Lifebook
    • PCMCIA karty IPWireless 3G UMTS
    • inteligentní boxy na uložná zařízení
    • senzorové čipy Winbond W83L786NG a W83L786NR
    • 12bitová 8kanálová ADC zařízení Texas Instruments ADS7828
    • karty Sony MemoryStick

  • Přidány byly také aktualizované video ovladače pro čipsety Radeon R500 (2D akcelerace je už podporována) a Intel i915 (suspend a resume [uspání a probuzení] nyní funguje správně).

  • Bylo odstraněno několik dalších zastaralých OSS ovladačů. Starý ovladač mxser byl také odstraněn a nahrazen mxser_new, kterému se teď zase říká jen "mxser."

  • Popisovače souborů vracené funkcí inotify_init() teď podporují I/O založené na signálech (pomocí SIGIO). Přibyla nová oznamovací událost (IN_ATTRIB), která je odeslána, když se změní počet odkazů sledovaného souboru.

  • Bezdrátový subsystém mac80211 (dříve Devicescape) už není označen jako "experimentální."

  • Regulátor používané paměti v kontejnerech byl začleněn, ale od doby, kdy byl popisován v LWN (a JN) se trochu změnil. Nějakou dokumentaci najdete v Documentation/controllers/memory.txt.

  • Přibyla podpora pro regulaci teploty přes ACPI; vizte podrobnosti v Documentation/thermal/sysfs-api.txt. ACPI kód teď také podporuje rozhraní Windows Management Instrumentation a využívá tuto podporu k zprovoznění funkcí u nových notebooků Acer.

  • ACPI nyní nabízí možnost přepsání systémové Differentiated System Description Table (DSDT).

  • Souborový systém XFS podporuje systémové volání fallocate().

  • ATA-over-Ethernet (AoE) nyní správně podporuje zařízení s více síťovými rozhraními (a tedy více cestami k hostiteli).

  • Přidána podpora pro architekturu MN10300 (pouze režim little-endian).

  • Z natahovače ELF byla odstraněna podpora binárek a.out. Čistě a.out systémy však pořád fungují.

  • Diskové I/O statistiky (dostupné v /proc/diskstats a v /sys/block) byly doplněny o další informace o slučování požadavků a čekacích dobách.

  • Architektura S390 nyní implementuje dynamické tabulky stránek - procesy budou používat 2, 3 nebo 4úrovňové tabulky stránek podle velikosti svého adresního prostoru.

  • Byl přidán příznak pro ext4 ("in development" - ve vývoji); připojení souborového systému ext4 bude odteď vyžadovat potvrzení varování "I know this might explode" [vím, že by to mohlo bouchnout].

Změny, kterých si všimnou vývojáři jádra:

  • Mnohé metody nopage() byly nahrazeny novějším API fault(); v blízké budoucnosti není plánováno úplné odstranění nopage(). Vizte článek Metoda fault(), kde je popsán nový způsob zpracování události "page not present" [stránka neexistuje].

  • Tento vývojový cyklus také zaznamenal znovuoživení dlouho zaseklého projektu na odstranění velkého jaderného zámku. Bylo začleněno několik patchů souvisejících s odstraněním BKL (Big Kernel Lock) a další budou určitě následovat.

  • Obecný mechanismus pro počítání zdrojů byl začleněn jako část sady patchů s regulátorem paměti; vizte podrobnosti v <linux/res_counter.h>.

  • reserve_bootmem() má nový parametr flags. Většina volajících ho nastaví na BOOTMEM_DEFAULT; kód kdump však používá BOOTMEM_EXCLUSIVE, aby zajistil, že se paměti nebude moci dotknout nikdo jiný.

  • Většina architektur už má podporu pro cmpxchg64() a cmpxchg_local().

  • Nová sada řetězcových funkcí:

        extern int strict_strtoul(const char *string, unsigned int base, 
                                  unsigned long *result);
        extern int strict_strtol(const char *string, unsigned int base,
                                 long *result);
        extern int strict_strtoull(const char *string, unsigned int base,
                                   unsigned long long *result);
        extern int strict_strtoll(const char *string, unsigned int base,
                                  long long *result);
    

    Tyto funkce převádějí zadané řetězce na různé formy long hodnot, ale pokud daná hodnota string nepředstavuje řádnou celočíselnou hodnotu, vrátí chybu. Používají se ke zpracovávání jaderných parametrů.

V tuto chvíli je začleňování funkcí dokončeno (i když se objevily snahy procpat ještě jednu nebo dvě další věci) a začíná stabilizační období. Budeme-li mít štěstí, bude tento proces o něco rychlejší než v případě 2.6.24.

Nová větev linux-next a způsob správy patchů

link

Vývojový proces jádra probíhá šíleným tempem; v rámci 2 - 3měsíčních vývojových cyklů je začleňováno kolem 10 tisíc sad patchů. Za poslední roky došlo k mnoha změnám, které umožnily tak rychlé zpracovávání tolika patchů a proces byl výrazně optimalizován. Pokračující diskuze na LKML však dává jasně najevo, že skutečně optimální řešení ještě nalezeno nebylo.

Začalo to oznámením stromu linux-next. Tento strom, který bude spravovat Stephen Rothwell, je určen jako shromaždiště patchů, jež mají být začleněny v dalším vývojovém cyklu. Takže protože jsme právě uprostřed cyklu 2.6.25, linux-next bude sbírat patche pro 2.6.26. Cílem je vyřešit tam problémy s integrací patchů a snížit nároky na čas Andrew Mortona.

Okamžitě byla položena následující otázka: jak budeme řešit velké změny API, které vyžadují úpravy ve více subsystémech. Tyto změny jsou vždy problematické, protože často vyžadují, aby vývojáři své stromy přepracovali uprostřed začleňovacího období. Pokusy o dřívější integraci takových změn v samostatném stromu by mohly způsobit další problémy. Nastane mnoho konfliktů mezi patchi připravenými před a po začlenění změny API a někdo bude muset ty kousky zase poskládat dohromady. V současné době to částečně dělá Andrew, ale jde o tak náročný problém, že ani Andrew na něj občas nestačí. Jako příklad byly zmíněny patche s podporou dvousměrného SCSI začleněné do 2.6.25; tato změna vyžadovala koordinované patche v SCSI a blokové vrstvě a nikdy se nepodařilo ji zprovoznit v -mm.

Arjan van de Ven tvrdí, že jediný způsob, jak zařídit, aby s velkými změnami API nebyly problémy, je začlenit je jako první - na začátku začleňovacího období. Zařazený patch by opravil všechny uživatele daného API v rámci stromu, jak je zvykem. Správci všech ostatních stromů by pak mohli začleňovat s použitím aktualizovaného hlavního stromu a při tom opravovat všechen kód, který změna API zasáhla. Tak se to v podstatě udělalo s velkou změnou ovladačového modelu v 2.6.25; dostala se do hlavního stromu jako první a pak se všichni mohli přizpůsobit novým podmínkám.

Greg Kroah-Hartman má obavy, že tento přístup nestačí, zvláště když jsou začleňovány živé stromy. Pokud si změna API v jednom stromu vynutí změny v jiném stromu, začne být koordinace velmi obtížná. Udržování sekundárních změn v primárním stromu hrozí rizikem konfliktů s patchi v běžném stromu daného subsystému. Navíc jsou patche, které zasahují více stromů, čím dál více považovány za nevhodné, protože všem znesnadňují život. Ale opravný patch nebude možné na žádný strom aplikovat, dokud tam nebude samotná změna API. V -mm je tento druh problémů řešen sérií opravných patchů, které spravuje Andrew; Greg si myslí, že strom linux-next bude potřebovat něco podobného.

David Miller navrhl řešit tento problém častým rebasováním [rebasing, změna základu] stromu -next. Rebasování je operace (podporovaná gitem a dalšími nástroji pro správu kódu), která vezme sadu patchů aplikovaných na strom a provede potřebné úkony k tomu, aby bylo možné je aplikovat na jinou verzi stromu. Je to užitečné při správě patchů pro proměnný cíl - což je případ linuxových stromů. David mluvil o tom, že často rebasuje své stromy (síťovací subsystém), aby se zbavil konfliktů s hlavním stromem a při té příležitosti odstranil z vývojové historie zbytečnosti.

Ukázalo se však, že tohle časté rebasování není oblíbené u vývojářů, kteří pracují pod Davidem [downstream]. Rebasování stromu nutí všechny přispěvatele provést totéž a pak řešit všechny začleňovací konflikty, které vzniknou. Kvůli tomu je o mnoho těžší připravovat stromy, které mohou být začleněny na vyšší úrovni [upstream].

Tou dobou se do debaty zapojil Linus a dal najevo, že rebasování také nemá rád. Souhlasil s vývojáři, že je těžké připravovat patche oproti neustále rebasovanému stromu. Také to způsobuje zmatky v historii, protože jsou při tom potichu měněny patche jiných vývojářů. Jakmile je něčí patch rebasován, už to není stejný kód, který dotyčný poslal. Takže Linus napsal:

Máme tedy opravdu důvod, proč se snažíme nepřepisovat historii. Přepisování historie potichu mění otestovaný kód na naprosto netestovaný, aniž by bylo jakkoliv patrné, že je netestovaný.

Přibližně v tu chvíli Andrew Morton komentoval, že git zjevně moc neodpovídá tomu, jak vývojáři jádra pracují. Řešení lze částečně hledat v nástrojích, které jsou více orientovány na správy front patchů - například quilt. Možná se brzy opět projeví zájem o přidání funkcí podobných těm, které nabízí quilt, do gitu (něco na způsob projektu stacked git).

Linus také nemá moc radost z toho, že k integraci patchů dochází pouze v rámci hlavního stromu:

Nejsem moc nadšený z toho, když si myslíte, že všechno začleňování musí projít mým stromem a musí být vidět během té dvoutýdenní doby pro začleňování. Popravdě si myslím, že byste mohli - a měli - zkusit řešit změny API mezi sebou. A pokud nemůžete, tak to je také problém.

Navrhl, aby byl pro velkou změny API vytvořen samostatný git strom, který by neobsahoval nic jiného. Správci subsystémů, kterých by se změna dotkla, by tento strom mohli začlenit a pak pokračovat ve vývoji oproti výsledku. Nakonec by měly být všechny části bez potíží zařazeny do hlavního stromu.

Tento přístup přináší několik zajímavých otázek. Strom se změnou API by museli všichni odsouhlasit a musel by být dostatečně stabilní - hodně změn na této úrovni by způsobilo na nižších úrovních problémy. Také by všichni museli věřit tomu, že se tato změna API nakonec opravdu dostane do hlavního jádra; kdyby si to Linus rozmyslel, všem by zůstal strom, ze kterého už by nešlo aplikovat změny na hlavní jádro. Nahrazení stávajícího způsobu pohybu patchů ("strom stromů") by mohlo zapříčinit potíže s koordinací. A existují obavy, že hlavní strom sestavený z tohoto procesu by v různých mezifázích nemuselo být možné zkompilovat, což by velmi ztížilo používání nástrojů jako "git bisect". Přesto by se mohlo jednat o součást dlouhodobého řešení.

Linus rovněž využil příležitosti, aby si postěžoval na velké změny API obecně:

Souhlasím s tím, že musíme opravovat špatně navržená rozhraní. Ale naprosto odmítám názor, že by to mělo být bráno jako pokračující věc. Změny API by neměly být považovány za neustálou nepříjemnost. A pokud to tak je (zjevně ano), tak by si lidé, kteří to mají na svědomí, neměli pokládat otázku "jak to synchronizovat", ale spíše se podívat hlouběji a ptát se "co děláme špatně".

Kromě toho uvedl, že cena za velké změny API je tak vysoká, že bychom měli spíš častěji zůstat u starých, i když nejsou tak dobrá, jak by mohla být. Někteří nesouhlasili a tvrdili, že se Linux musí vyvíjet, pokud má zůstat naživu a něco znamenat.

Tempo změn asi v blízké budoucnosti nepoleví. Mohlo by se však změnit to, jak velké jsou to změny. Ted T'so navrhl, že by se více změn mohlo provádět pomocí vytváření zcela nových rozhraní místo změn starých. Pak by bylo staré rozhraní na začátku začleňovacího období označeno jako "zastaralé" [deprecated]. Vývojáři by pak měli celý vývojový cyklus na to, aby se změnám přizpůsobili a zastaralé rozhraní by bylo před vydáním finální verze odstraněno.

Tomuto přístupu se však mnozí vývojáři brání, protože je ze zkušenosti známo, že odstraňování zastaralých rozhraní je těžší, než se zdá. Přesto jde však o relativně bezbolestný způsob provádění změn. Současný přechod (v oblasti správy paměti) z VMA operace nopage() na fault() je příkladem toho, jak by to mohlo fungovat. Nick Piggin pomalu mění uživatele v rámci stromu, přičemž konečným cílem je úplné odstranění nopage(). Prozatím však v jádře obě rozhraní koexistují a nic kvůli tomu nepřestalo fungovat.

Stejně jako jádro samotné, i vývojový proces se neustále mění a (snad) zlepšuje. Spolu s rostoucí vývojářskou komunitou a rychlostí změn se bude muset přizpůsobovat i proces. Jaké změny z této diskuze vzejdou, to teprve uvidíme, i když stojí za zmínku obavy Andrew Mortona: že největší problém, tj. regrese a chyby, zůstane nedotčen.

vmsplice(): jak se dělá lokální root exploit

link

V době psaní tohoto textu se distributoři snažili rychle vydat aktualizace jader, které by opravovaly lokální zranitelnost umožňující získat práva roota v systémovém volání vmsplice(). Na rozdíl od mnoha jiných nedávných zranitelností, které vyžadovaly ke zneužití speciální situace (například přítomnost určitého hardwaru), bylo tentokrát možné chybu zneužít velmi snadno a kód, který to dělal, je na netu dostupný. Jonathan Corbet se podivoval nad tím, jak se taková díra mohla dostat do kódu jádra, takže se rozhodl zjistit, co se vlastně stalo. Zabralo to o mnoho déle, než původně čekal.

Systémové volání splice() je mechanismus napomáhající instalatéřině toku dat v rámci jádra. Může být použit pro spojení dvou popisovačů souborů; jádro pak bude číst data z jednoho a zapisovat je do druhého tím nejefektivnějším způsobem. Bylo by tedy možné napsat jednoduchý program pro kopírování souborů, který by otevřel zdrojový a cílový soubor a spojil (splicenul, "splajsnul") je dohromady. Varianta vmsplice() propojí popisovač souboru (který musí být roura) s oblastí uživatelské paměti; a v tomto systémovém volání se objevil problém.

Prvním krokem k pochopení této zranitelnosti je to, že se ve skutečnosti jedná o tři samostatné chyby. Když se poprvé rozkřikla zpráva o problému, mělo se za to, že se týká pouze jader 2.6.23 a 2.6.24. Změny v kódu vmsplice() způsobily opominutí dvou důležitých kontrol oprávnění. Konkrétně šlo o to, že když aplikace požadovala, aby vmsplice() přesunula obsah roury do určité oblasti paměti, jádro nezkontrolovalo, jestli ta aplikace měla pro zápis do dané paměti právo. Takže exploit mohl prostě zapsat kousek kódu do roury a pak jádro požádat, aby ho nakopírovalo do části jaderné paměti. Můžete si to představit jako rychlý a snadný způsob instalace rootkitu.

Pokud namísto toho aplikace splicuje rozsah paměti do roury, musí jádro nejprve načíst jednu nebo více struktur iovec, které daný rozsah paměti popisují. Změny v 2.6.23 ve vmsplice() zapomněly na kontrolu, jestli jsou příslušné struktury iovec v čitelné části paměti. To vypadá spíše jako zranitelnost, kvůli které by šly získat informace - ale, jak za chvíli uvidíme, někdy je těžké to určit.

Tyto dva problémy (CVE-2008-0009 a CVE-2008-0010) byly zalepeny v aktualizacích 2.6.23.15 a 2.6.24.1, které vyšly 8. února.

10. února Niki Denev poukázal na to, že se jádro zdá zranitelné i po aplikování opravy. Ve skutečnosti byla zranitelnost způsobena jiným problémem - a to mnohem vážnějším, protože byly zranitelné všechny verze až po 2.6.17. V tuto chvíli je i nadále zranitelné velké procento počítačů s Linuxem. Problém byl opraven v jádrech 2.6.22.18, 2.6.23.16 a 2.6.24.2, jež vyšly také 10. Od té doby už snad byly všechny tyto chyby vychytány - i když ještě musí zareagovat mnoho distributorů.

Problém byl opět v implementaci kódu paměť-do-roury. Funkce get_iovec_page_array() má za úkol najít sadu ukazatelů struct page odpovídající poli struktur iovec předávaných volající aplikací. Dané ukazatele jsou uloženy v tomto poli:

    struct page *pages[PIPE_BUFFERS];

Kde PIPE_BUFFERS je 16. Aby se zabránilo přetečení tohoto pole, provádí get_iovec_page_array() následující kontrolu:

    npages = (off + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
    if (npages > PIPE_BUFFERS - buffers)
        npages = PIPE_BUFFERS - buffers;

off je offset v rámci první stránky paměti, která má být přenesena, len je délka předaná aplikací a buffers je aktuální index v poli pages.

Když se teď na chvíli podíváme na kód exploitu, všimneme si, že připravuje několik oblastí paměti pomocí mmap(); jak se ukázalo, některé z nich nejsou kvůli funkci exploitu potřeba. Ke konci dělá kód toto (mírně upraveno):

    iov.iov_base = map_addr;
    iov.iov_len  = ULONG_MAX;
    vmsplice(pi[1], &iov, 1, 0);

Adresa map_addr ukazuje na jednu z oblastí vytvořených pomocí mmap(), která je, a to je podstatné, výrazně delší než PIPE_BUFFERS stránek. A délka je předána jako největší možná hodnota unsigned long.

Vraťme se teď k fs/splice.c, kde je implementace vmsplice(). Víme, že před opravou jádro nekontrolovalo, jestli může volající proces přečíst oblast paměti, na kterou ukazuje struktura iovec. Opět - vypadá to jako zranitelnost, která pouze prozradí informaci - proces by mohl způsobit, že by byl kterýkoliv bit paměti jádra zapsán do roury, ze které by mohl být přečten. Ale kód exploitu předává platný ukazatel - jen ta délka je zjevně absurdní.

Při pohledu na kód, který počítá npages, vidíme něco zajímavého:

    npages = (off + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
    if (npages > PIPE_BUFFERS - buffers)
        npages = PIPE_BUFFERS - buffers;

Protože len bude v době běhu exploitu ULONG_MAX, přidání způsobí přetečení celého čísla - takže bude npages vypočítáno jako nula. Což by nemělo způsobit žádné zkoumání stránek. Až na to, že dochází k nešťastné interakci s jinou částí jádra.

Jakmile je vypočteno npages, vypadá následující řádek kódu takto:

    error = get_user_pages(current, current->mm,
		       	   (unsigned long) base, npages, 0, 0,
		       	   &pages[buffers], NULL);

get_user_pages() je hlavní funkce pro správu paměti, která se používá k připíchnutí sady uživatelských stránek do paměti a nalezení jejich ukazatelů struct page. Zatímco proměnná npages, která je předávána jako parametr, je bezznaménková hodnota, prototyp get_user_pages() ji deklaruje jako obyčejnou int nazvanou len. A, aby byla zkáza dokonána, tato funkce zpracovává stránky v cyklu do {} while();, který je zakončen takto:

	len--;
    } while (len && start < vma->vm_end);

Takže když je funkci get_user_pages() předán nulový parametr len, projde se cyklem jednou, len se sníží na zápornou hodnotu a pak bude přidávat stránky pomocí výpadků [faulting in pages] tak dlouho, dokud nenarazí na adresu, která nemá platné mapování. Pak se zastaví a ukončí. Ale tou dobou už může být do pole pages uloženo mnohem více stránek, než pro kolik volající kód alokoval místo.

Praktickým výsledkem je v tomto případě to, že get_user_pages() pomocí výpadků přidá celou oblast mapovanou kódem exploitu (a také pro ni uloží ukazatele struct page). Ta oblast má (záměrně) více stránek než PIPE_BUFFERS - vlastně má třikrát tolik, takže je do 16ukazatelového pole vloženo 48 ukazatelů. A z nemožnosti ověřit [read-verify] zdrojové pole se tak stane přetečení zásobníku [buffer overflow]. Jakmile k tomu dojde, je už pro dostatečně 1337 hackera poměrně snadné zařídit, aby jádro skočilo na kód dle jeho výběru. Game over. (Aktualizace: jak podotkl čtenář LKML, je to celé ještě komplikovanější, protože jde o hodně nezvyklé přetečení zásobníku.)

Aplikovaná oprava pouze kontroluje adresní rozsah, který se aplikace pokouší splicenout do roury. A protože je nepravděpodobné, že by byl rozsah délky ULONG_MAX platný, je zranitelnost odstraněna - stejně jako potenciální problémy s vyzrazením informací.

Tato zranitelnost je jasný příklad, jak může zdánlivě read-only zranitelnost přerůst v mnohem vážnější záležitost. Také ukazuje, co se může stát, když si do jádra najde cestu nedbale napsaný kód - je-li po get_user_pages() žádáno nula stránek, tak by jich také mělo být nula zpracováno. Jonathan Corbet pracuje na patchi, který by to trochu pročistil. A mezitím by všichni měli nasadit jádro, kde už byl problém odstraněn.

       

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ář

3.4.2008 09:03 zde | skóre: 9 | blog: Linuch | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny - 13. 2. 2008
Natahovač ELF. Kewl. :) Správně, do každé mučírny jednoho skřítka ke každému skřipci.
Táto, ty de byl? V práci, já debil.
3.4.2008 09:16 Robert Krátký | skóre: 94 | blog: Robertův bloček
Rozbalit Rozbalit vše Re: Jaderné noviny - 13. 2. 2008
Také se mi ten překlad nelíbí, ale lepší mě nenapadá. Rád si nechám poradit.
3.4.2008 09:31 zp
Rozbalit Rozbalit vše Re: Jaderné noviny - 13. 2. 2008
Zavaděč?
hwsoft avatar 3.4.2008 15:26 hwsoft | skóre: 19
Rozbalit Rozbalit vše Re: Jaderné noviny - 13. 2. 2008
to me se libi. Rad si sveho elfa natahnu :-D
4.4.2008 12:55 nhy | skóre: 14
Rozbalit Rozbalit vše Re: Jaderné noviny - 13. 2. 2008
Rad si svoju elfku natiahnem :-)
Prcek avatar 3.4.2008 16:57 Prcek | skóre: 43 | Jindřichův Hradec / Brno
Rozbalit Rozbalit vše Re: Jaderné noviny - 13. 2. 2008
linux-next b ude sbírat patche pro 2.6.26
Člověk je takový, jak vypadá... A já vypadám jako pravá, nefalšovaná děvka!!!
3.4.2008 09:53 kavol | skóre: 28
Rozbalit Rozbalit vše Re: Jaderné noviny - 13. 2. 2008
podpora MemoryStick? žeby, konečně?
3.4.2008 20:53 Jan Kundrát (jkt) | skóre: 27 | blog: jkt | Praha - Bohnice
Rozbalit Rozbalit vše Re: Jaderné noviny - 13. 2. 2008
"Ale kód exploitu předává platný ukazatel - pouze délku, což je zjevně absurdní." ma zrejme byt "Kod exploitu sice predava platny ukazatel, avsak absurdni delku.", alespon mi to tak dava vesti smysl. Ale link na relevantni kus anglickeho originalu nevidim, takze si nejsem jisty.
3.4.2008 21:13 Robert Krátký | skóre: 94 | blog: Robertův bloček
Rozbalit Rozbalit vše Re: Jaderné noviny - 13. 2. 2008
Dík, je to tak (odkaz na orig. je na konci pod nadpisem "Odkazy a zdroje").

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.