Ubuntu 27.04 bude Tenacious T-Rex.
Byla vydána nová verze 2026.4.0 "Never-slop" svobodného softwaru ScummVM (Wikipedie) umožňujícího bezproblémový běh mnoha klasických adventur na zařízeních, pro které nebyly nikdy určeny. Přehled novinek v poznámkách k vydání a na GitHubu. ScummVM oslavil 25 let. Verze 0.0.1 vyšla 8. října 2001.
Kanadský vývojář Anthony Sistilli vytvořil ironický DIY projekt parodující kamerové systémy Flock, s cílem názorně demonstrovat rizika masového sledování jaké provozují tyto komerční ALPR systémy. Z levné IP kamery a vlastního ML softwaru (napsaného s pomocí SI circa za 20 minut, kód se mi bohužel nepodařilo dohledat) běžícího v laptopu sestavil jednoduchý systém, který detekuje výhradně policejní vozidla, zaznamenává jejich SPZ a
… více »Část údajů uživatelů internetového supermarketu Rohlík byla odcizena. Kyberútočníci napadli nástroj zákaznické podpory Rohlíku, odcizili tak jména, e-mailové adresy, v některých případech také telefonní čísla nebo přepisy komunikace mezi klienty a zákaznickou podporou. Rohlík incident nahlásil příslušným orgánům a přijal příslušné opatření, aby zamezil podobným případům v budoucnosti, uvedla firma.
Aplikace eDoklady fungovala v obou volebních dnech stabilně a prakticky bez front. Digitální a informační agentura (DIA) odhaduje, že se digitálním dokladem prokázalo více než 100.000 voličů. Aplikaci si před volbami či během nich aktualizovalo 247.517 uživatelů. Nových registrací bylo 19.431 a do aplikace se přihlásilo 357.879 lidí. Největší nápor přišel bezprostředně po otevření volebních místností mezi 14. a 16. hodinou, kdy si
… více »Začal semestr, začal i podzim a kromě hub rostou jako po dešti i veřejné dílny v Praze. Nedávno strahováci referovali o hackerspacu Bordel, nyní se otevřela dílna Dejvice Lab jen kousek od ČVUT. Na blížící Virtuální Bastlírně tak uslyšíte nejen report z návštěvy dílny HWLab, ale i řadu novinek, událostí a úsměvných momentů, které se za poslední měsíc ve světě techniky, ale i vědy udály. Připojte se tedy již v úterý 13.10. od 20:00 a zapojte se do
… více »Byl vydán LineageOS 24 (Mastodon). LineageOS (Wikipedie) je svobodný operační systém pro chytré telefony, tablety a set-top boxy založený na Androidu. Jedná se o nástupce CyanogenModu. LineageOS 24 je založený na Androidu 17.
Společnost Valve publikovala na svém GitLabu nákresy a schémata zapojení headsetu Steam Frame. Pro nekomerční účely.
Soutěž Pwn2Own Ireland 2026 skončila 9. října. Bezpečnostní výzkumníci získali celkem 1 262 000 dolarů na odměnách. Během soutěže bylo předvedeno zneužití 98 zero-day zranitelností. Testování zahrnovalo různé kategorie zařízení a software. Výzkumníci předváděli prakticky fungující útoky podle pravidel soutěže. Výsledky následně slouží výrobcům při přípravě oprav. Mezi pokořenými jsou: Samsung Galaxy S26, OpenAI Codex, Oracle Autonomous AI Database, Google Pixel 10, u iPhone 17 neuspěli.
Programovací jazyk Python byl vydán v nové verzi 3.15.0. Podrobný přehled novinek v aktualizované dokumentaci.
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