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 13:11 | Zajímavý projekt

Novinkou v minor aktualizaci webového prohlížeče Vivaldi je podpora vyhledávače Qwant (Wikipedie). Vývojáři Vivaldi zdůrazňují, že se jedná o evropský vyhledávač respektující soukromí uživatelů.

Ladislav Hagara | Komentářů: 2
dnes 01:33 | Nová verze

Po šesti letech od vydání verze 1.0 byla vydána verze 2.0 multiplatformního editoru tagů MusicBrainz Picard (Wikipedie). Přehled novinek, vylepšení a oprav v changelogu.

Ladislav Hagara | Komentářů: 0
včera 16:22 | Nová verze Ladislav Hagara | Komentářů: 11
včera 15:00 | Komunita

Dnes končí podpora Ubuntu 17.10 Artful Aardvark. Uživatelům je doporučen přechod na Ubuntu 18.04 Bionic Beaver s prodlouženou podporou do roku 2023. Podpora standardních verzí Ubuntu je 9 měsíců. Verze 17.10 byla vydána 19. října 2017.

Ladislav Hagara | Komentářů: 11
včera 13:33 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 334 bezpečnostních chyb. V Oracle Java SE je například opraveno 8 bezpečnostních chyb. Všechny jsou vzdáleně zneužitelné bez autentizace. V Oracle MySQL je opraveno 31 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 7 z nich.

Ladislav Hagara | Komentářů: 0
včera 13:11 | Zajímavý software

Nick Clifton zveřejnil na blogu společnosti Red Hat věnujícímu se počítačové bezpečnosti nástroj, pomocí kterého lze ověřit, zda jsou binární spustitelné soubory odolné vůči variantě 1 bezpečnostní chyby Spectre v procesorech.

Ladislav Hagara | Komentářů: 0
včera 03:00 | Nová verze

Po více než roce vývoje od vydání verze 1.12 byla vydána nová verze 1.13 Java edice počítačové hry Minecraft (Wikipedie). Kódový název nejnovější verze je Update Aquatic. Přehled novinek v oficiálním oznámení o vydání. Detailní přehled novinek na Gamepedii a na YouTube.

Ladislav Hagara | Komentářů: 4
18.7. 23:55 | Nová verze

Společnost Epic Games vydala verzi 4.20 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Přehled novinek i s celou řadou obrázků a videi v oznámení na blogu.

Ladislav Hagara | Komentářů: 0
18.7. 15:55 | IT novinky

Evropská komise uložila (pdf) společnosti Google pokutu ve výši 4,34 miliardy eur za porušení antimonopolních předpisů EU. Společnost Google ukládala od roku 2011 výrobcům zařízení Android a provozovatelům mobilních sítí protiprávní omezení, aby upevnila dominantní postavení svých produktů zaměřených na všeobecné vyhledávání na internetu.

Ladislav Hagara | Komentářů: 29
18.7. 13:55 | Zajímavý software

Byl vydán REAPER (Wikipedie) ve verzi 5.93. Jedná se o proprietární digitální pracovní stanici pro práci s audiem (DAW). Novinkou je experimentální linuxový port [reddit].

Ladislav Hagara | Komentářů: 2
Jak čtete delší texty z webových stránek?
 (77%)
 (20%)
 (5%)
 (7%)
 (2%)
 (10%)
Celkem 371 hlasů
 Komentářů: 40, poslední 29.6. 10:21
    Rozcestník

    Jaderné noviny - 13. 2. 2008

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

    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.