Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
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.
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
???? řádků zkontrolováno každý den.
-- Al Viro
Č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é:
Změny, kterých si všimnou vývojáři jádra:
Nová sada řetězcových funkcí:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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.
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.
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.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
3.4.2008 16:57
Prcek | skóre: 43
| Jindřichův Hradec / Brno
3.4.2008 15:26
