Během tradiční ceremonie k oslavě Dne vzniku samostatného československého státu (28. října) byl vyznamenán medailí Za zásluhy (o stát v oblasti hospodářské) vývojář 3D tiskáren Josef Průša. Letos byly uděleny pouze dvě medaile Za zásluhy o stát v oblasti hospodářské, druhou dostal informatik a manažer Ondřej Felix, který se zabývá digitalizací státní správy.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 15.0. Postaven je na Firefoxu ESR 140.
Bylo oznámeno (cs) vydání Fedora Linuxu 43. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách Fedora Magazinu: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Silverblue a Fedora Atomic Desktops.
Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.
PSF (Python Software Foundation) po mnoha měsících práce získala grant ve výši 1,5 milionu dolarů od americké vládní NSF (National Science Foundation) v rámci programu "Bezpečnost, ochrana a soukromí open source ekosystémů" na zvýšení bezpečnosti Pythonu a PyPI. PSF ale nesouhlasí s předloženou podmínkou grantu, že během trvání finanční podpory nebude žádným způsobem podporovat diverzitu, rovnost a inkluzi (DEI). PSF má diverzitu přímo ve svém poslání (Mission) a proto grant odmítla.
Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Od 3. listopadu 2025 budou muset nová rozšíření Firefoxu specifikovat, zda shromažďují nebo sdílejí osobní údaje. Po všech rozšířeních to bude vyžadováno někdy v první polovině roku 2026. Tyto informace se zobrazí uživateli, když začne instalovat rozšíření, spolu s veškerými oprávněními, která rozšíření požaduje.
Jste nuceni pracovat s Linuxem? Chybí vám pohodlí, které vám poskytoval Microsoft, když vás špehoval a sledoval všechno, co děláte? Nebojte se. Recall for Linux vám vrátí všechny skvělé funkce Windows Recall, které vám chyběly.
Společnost Fre(i)e Software oznámila, že má budget na práci na Debianu pro tablety s cílem jeho vyžívání pro vzdělávací účely. Jako uživatelské prostředí bude použito Lomiri.
Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Současný vývojový kernel nese označení 4.5-rc5, vydán byl 20. února. Podle Linuse je vše v pořádku a v klidu, jen s čištěním VM THP jsou stále problémy na s390.
Stabilní aktualizace: 4.3.6 (poslední v řadě 4.3.x) a 3.10.97 byly vydány 19. února. Verze 4.4.3, 3.14.62 a 3.10.98 byly v době psaní překladu tohoto vydání jaderných novin v procesu revidování a nyní jsou k dispozici.
No ne, máme spelling.txt! Myslím, že můžeme prohlásit jádro za hotové a dělat něco jiného...
Což vlastně nebude vůbec vadit, protože za 22 let nebude 32bitový systém nikde běžně k vidění. Stačí se podívat na platformy x86, Pentium Pro je už dneska sběratelským předmětem. Všechna ta dnešní uzamčená, sotva udržovaná vestavěná zařízení a telefony budou po připojení k čemukoli přinejlepším jakýmsi digitálním ekvivalentem nebezpečného odpadu.
Za starých dobrých časů (alespoň z jednoho úhlu pohledu) měli útočníci jednoduchý život. Stačilo jim najít zranitelnost způsobenou přetečením vyrovnávací paměti a vsunout (code injection) do zranitelného procesu kód dle svého gusta. V průběhu času se vývojáři kernelu snažili zajistit, aby data, která mohou být zapsaná aplikací, nemohla být stejnou aplikací vykonána. Tento krok učinil „vstřikování“ kódu ve většině situací neproveditelným. Útočníci tedy reagovali technikami, jako je return-oriented programming (ROP), ale ROP jsou většinou docela náročné na provedení. Na některých systémech mohou útočníci využít jednodušší sigreturn-oriented programming (SROP). Naštěstí již kolují patche, které by měly odvrátit tento typ útoků.
Jestliže nemohou být data na zásobníku přímo spuštěna, nemůže dojít ke zneužití přetečení vyrovnávací paměti a vložení kódu přímo do aplikace. Tyto zranitelnosti ovšem mohou být zneužity ke změně čítače programu přepsáním aktuální adresy vracené funkcí. Jestliže se útočníkovi podaří identifikovat kód, který se nachází uvnitř adresního prostoru příslušného procesu, jenž vykonává zadaný úkol, může zneužít přetečení vyrovnávací paměti k navrácení se k tomuto kódu a nabytí kontroly.
Naneštěstí pro útočníky postrádá většina programů vhodné místo pro vstup skrze přepsanou návratovou adresu. I tak je pravděpodobné, že daný program požadovanou funkcionalitu obsahuje, jen je rozsekaná na malé kousky a rozptýlená po celém adresním prostoru. Základní myšlenkou ROP je najít tyto kousky v místech, kde je následuje instrukce pro návrat (return). Útočník, který má kontrolu nad zásobníkem, může nejen skočit k první z těchto pasáží, ale také umístit návratovou adresu na zásobník, takže když tento kousek vykoná svou instrukci návratu, přechází kontrola na další místo vybrané útočníkem – další část užitečného kódu. Seřazením těchto kousků může útočník uvnitř cílového procesu vytvořit zcela nový program.
Existují různé nástroje, které mohou s tvorbou ROP útoků pomoci. Skenery mohou projet spustitelný obraz a identifikovat předměty zájmu. „ROP kompilátory“ mohou poté vytvořit program k dosažení útočníkova cíle. Nezbytné nástroje ovšem nemusí být dostupné a techniky jako randomizace adresního prostoru (address-space layout randomization, ASLR) ROP útoky stěžují. ROP útoky tudíž bývají vskutku delikátní záležitostí; často jde o konkrétní útoky na konkrétní systémy (někdy dokonce pouze konkrétní běžící proces). Útočníci jsou lidé zaneprázdnění, stejně jako my ostatní, takže je nemůžeme vinit, když se snaží najít jednodušší způsoby, jak ovládnout systém.
Seznamme se se sigreturn(), linuxovým systémovým voláním, které ovšem nikdo nevolá přímo. Když dojde k doručení signálu procesu, přejde se k obsluze daného signálu; jakmile ta skončí, vrátí se vykonávání programu k místu, kde došlo k přerušení. Signály jsou typem softwarového přerušení – se všemi takovými přerušeními musí být nějak naloženo. Dříve než může jádro doručit signál, musí si zaznamenat kontext vykonávání programu, a to včetně hodnot, které se ukládají ve všech registrech procesoru.
Bylo by možné uložit tuto informaci přímo v jádře, ale to by mohlo umožnit útočníkovi (jiného ražení) přinutit jádro alokovat libovolné množství paměti. Takže místo toho ukládá jádro tuto informaci na zásobník procesu, který je příjemcem signálu. Před vyvoláním obsluhy signálu přidá jádro některou variantu struktury sigcontext (v závislosti na architektuře) na zásobník procesu. Tato struktura obsahuje informace z registrů, o využívání čísel s plovoucí desetinnou tečkou aj. Jakmile obsluha dokončí svůj úkol, zavolá sigreturn(), který vrátí všechny informace ze struktury na zásobníku.
Útočníci, kteří využívají techniky ROP, se musí snažit najít programy, které uloží požadované hodnoty do konkrétních registrů procesoru. Ovšem pokud mají možnost zavolat sigreturn(), mají to jednodušší, protože toto systémové volání nastavuje hodnoty všech registrů přímo ze zásobníku. Jak už to tak bývá, nemá jádro žádný způsob, jak rozpoznat, zda konkrétní sigreturn() pochází z legitimní obsluhy signálu či nikoli; celý systém byl navržen tak, aby jádro tuto informaci nemuselo sledovat. Takže jak poznamenali Erik Bosman a Herbert Bos v tomto článku (PDF), vypadá to, že volání sigreturn() by mohlo být útočníkům nápomocné.
Existuje však jedna překážka, kterou musí útočníci překonat nejprve: musí najít kus kódu volající sigreturn(), což dělá jen několik málo aplikací. Jednou z metod by bylo najít obecnější část programu pro vyvolávání systémových volání a pak zařídit, aby došlo k tolika voláním, aby to odpovídalo sigreturn(). V mnoha případech je to ale zbytečné. Vývojáři po mnoho let příhodně umisťovali sigreturn() tam, kde jej útočníci mohou snadno najít – na pevnou adresu, která není v režii ASLR. Tato adresa se nachází v oblasti „virtuálního dynamického sdíleného objektu“ (vDSO), na stránce namapované jádrem ve známém umístění v každém procesu, a to kvůli optimalizaci některých systémových volání. Na jiných systémech se sigreturn() nachází v knihovně jazyka C. K jeho zneužití je nejprve třeba najít způsob, jak přijít k informacím o ASLR.
Bosman a Bos předvedli, že se dá sigreturn() použít pro napadení procesů, které jsou zranitelné skrze přetečení paměti. Často stačí pouze kus kódu se sigreturn() a útok se podaří. V některých případech se dá exploit napsat nezávisle na systému, takže se dá použít znovu bez dalšího úsilí. Nová jádra činí taková napadení složitější (například oblast vDSO se již nedá použít), ale ještě zdaleka nejsou nemožné. Navíc spousta zajímavých cílů stále používá starší verze jádra.
Scott Bauer nedávno zveřejnil sadu patchů, která by měla skoncovat s útoky SROP. Jakmile je problém znám, je řešení jasné celkem rychle: jádro potřebuje způsob, jak si ověřit, že struktura sigcontext na zásobníku je ta, kterou tam samo dalo. To by zajistilo, že sigreturn() bude možné volat pouze na konci skutečného doručení signálu.
Scottův patch funguje tak, že generuje náhodné „cookie“ hodnoty pro každý proces. Tato hodnota je uložena na zásobníku jako součást každého procesu doručení signálu, hned vedle struktury sigcontext. Před uložením dojde ke XORování s adresou umístění zásobníku, kde dojde k uložení, takže je o mnoho složitější z ní zpětně číst. Budoucí plány volají po rozdělení této hodnoty, čímž se zcela znemožní obnovení „cookie“ hodnoty. I tak by ale měla být hodnota „cookie“ dostatečně bezpečná; útočník, kterému by se podařilo tuto hodnotu přečíst přímo ze zásobníku, má již tak či tak systém pod kontrolou.
Implementace sigreturn() již vyžaduje pouze ověřit, že „cookie“ existuje v předpokládaném umístění. Pokud tam je, potom je volání legitimní a může k němu dojít. V opačném případě operace skončí a vrátí SIGSEGV volajícímu procesu, čímž dojde k jeho ukončení, pakliže proces není nějak ošetřen.
Patch má stále nějaké praktické problémy. Nebude kupříkladu pracovat správně v situaci, kdy je aktivní bod obnovy v uživatelském prostoru (obnovený proces bude mít novou a náhodnou hodnotu cookie, staré cookie mohou být stále na zásobníku). Tyto problémy je možné obejít, ale může si to vynutit přidání přepínače sysctl pro vypnutí ochrany v situacích, kde nefunguje. Také nijak nepřispívá k ochraně před ROP útoky obecně, pouze zabraňuje jednomu z relativně snadno zneužitelných scénářů těchto útoků. Ale je na dosah, takže jeho získání je asi dobrý nápad. Ostatně, proč útočníkům zjednodušovat život?
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz