Vojenské zpravodajství (VZ) se v březnu zapojilo do mezinárodní operace proti aktivitám hackerské skupiny APT28, která je spojovaná s ruskou vojenskou zpravodajskou službou GRU a která přes slabě zabezpečené routery prováděla kybernetické útoky na státní a další organizace v ČR i zahraničí. Operaci vedl americký Federální úřad pro vyšetřování (FBI) a jejím cílem bylo odebrat útočníkům přístup k napadeným zařízením a ty následně … více »
Tvůrcem nejpopulárnější kryptoměny bitcoin, který se skrývá za pseudonymem Satoši Nakamoto (Satoshi Nakamoto), je britský kryptograf Adam Back. Na základě vlastní investigativní práce to tvrdí americký deník The New York Times (NYT). Několik indicií podle autorů jasně ukazuje na to, že Back a Nakamoto jsou stejný člověk. Jde mimo jiné o podobný odborný a osobnostní profil či totožné chyby a manýry v psaném projevu.
Google Chrome 147 byl prohlášen za stabilní. Nejnovější stabilní verze 147.0.7727.55 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Vylepšeny byly také nástroje pro vývojáře. Přehled novinek v Chrome DevTools 145 až 147 také na YouTube.
Vývojáři z Laboratoří CZ.NIC vydali nové verze aplikací Datovka (Datovka 4.29.0, Mobilní Datovka 2.6.2). V případě desktopové verze přibyly možnosti projít všechny uložené zprávy, zkontrolovat časy expirací časových razítek a přerazítkovat datové zprávy, které lze v ISDS přerazítkovat. Novinkou je také možnost vytahovat myší ze seznamu ZFO soubory datových zpráv, tento úkon jde udělat i pomocí tlačítek Ctrl+C. Nová verze Mobilní Datovky přináší jen drobné úpravy.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.28.0. Z novinek lze vypíchnout novou třídu machine.CAN.
Michael Meeks, CEO společnosti Collabora, na apríla oznámil, nebyl to ale apríl, že nadace The Document Foundation zastřešující vývoj kancelářského balíku LibreOffice vyloučila ze svých řad všechny zaměstnance a partnery společnosti Collabora, tj. více než třicet lidí, kteří po mnoho let přispívali do LibreOffice. Nadace The Document Foundation po několika dnech publikovala oficiální vyjádření. Přiznává pochybení při zakládání
… více »Protože je už po aprílu, můžou strahováci opět zveřejnit program další Virtuální Bastlírny, aniž by připravená témata působila dojmem, že jde o žert. Vězte tedy, že v úterý 14. dubna (změna!!!) od 20:00 proběhne VB, kde se setkají bastlíři, technici, učitelé i nadšenci do techniky a kde i vy se můžete zapojit do družného hovoru, jako by všichni seděli u pomyslného piva. Co mají bastlíři tento měsíc na srdci? Pravděpodobně by nás musel zasáhnout
… více »Byla vydána verze 26.1 aneb čtvrtletní aktualizace open source počítačového planetária Stellarium (Wikipedie, GitHub). Vyzkoušet lze webovou verzi Stellaria na Stellarium Web.
VOID (Video Object and Interaction Deletion) je nový open-source VLM model pro editaci videa, který dokáže z videí odstraňovat objekty včetně všech jejich fyzikálních interakcí v rámci scény (pády, kolize, stíny...) pomocí quadmaskingu (čtyřhodnotová maska, která člení pixely scény do čtyř kategorií: objekt určený k odstranění, překrývající se oblasti, objektem ovlivněné oblasti a pozadí scény) a dvoufázového inpaintingu. Za projektem stojí výzkumníci ze společnosti Netflix.
Design (GitHub) je 2D CAD pro GNOME. Instalovat lze i z Flathubu. Běží také ve webovém prohlížeči.
Současný vývojový kernel je 4.8-rc6, vydaný 11. září. „Stále jsem se ještě nerozhodl, zda uděláme rc8, ale myslím, že zatím nemusím spěchat. Nic nevypadá úplně zle a bude záležet na tom, jak dopadne rc7.“
Seznam známých regresí v řadě 4.8 měl k 11. září 10 položek.
Stabilní aktualizace: 3.14.79, poslední z řady 3.14.x, byla vydána 11. září.
Stabilní aktualizace 4.7.4 (oznámení chybí) a 4.4.21 byly v době vydání tohoto článku v procesu revidování, nyní by již měly být dostupné.
Jenže se ukázalo, že příslušnou řadu jádra používali pouze po nějakou dobu během vývoje, načež s tím přestali, jakmile se zařízení dostalo na trh. Podívejte se na všechny ty telefony s Androidem, které využívají zastaralé verze stabilních jader 3.4 a 3.10. Už je ani neaktualizují na novější, a tak to vlastně skoro nijak nepomohlo. Přestože v těchto jádrech pořád opravuji bezpečnostní chyby, nikdo to neposílá dál uživatelům. Mám příklad bezpečnostní chyby, kterou jeden vývojář z Google našel v jádře 3.10 (ale ne v upstreamu). Opravil jsem ji a vydal aktualizaci, tu ale nikdo celých šest měsíců nedostal do telefonů Nexus – až jsem po těch šesti měsících našel toho správného člověka/skupinu, kterou bylo třeba v Google postrčit.
Takže kdokoli měl k dispozici šestiměsíční okno, během kterého mohl snadno získat roota na vašem telefonu.
Lidé říkají: „Podívejte, ve svém produktu používáme LTS jádro, takže všechno musí být v pořádku!“ Ale pokud jej neaktualizují, je rozbité a nezabezpečené a vůbec o nic lepší, než kdyby rovnou použili 3.10.0.
Nezbývá mi než dodat:
yell_WTF(nr_wtf_moments);
Hodnotu argumentu funkce ponechám na vaší představivosti.
Leif Lindholm začal pracovat na seriálu o psaní ovladačů UEFI. „Vzhledem k tomu, že jsem vlastně nikdy ovladač UEFI nenapsal na zelené louce a většina ovladačů, se kterými jsem se dostal do styku, byly hlavně ovladače platformy, řekl jsem si, že by nebylo špatné napsat samostatný ovladač celý od počátku. Výsledkem je tento lehce praktický seriál.“
Cílem většiny útoků na jádro je spustit kód dle útočníkova výběru, s právy jádra. Není tedy překvapením, že existuje mnoho technik tvrzení, které jsou zaměřeny na prevenci vložení libovolného kódu do míst, kde by napadené jádro mohlo být přesvědčeno k jeho spuštění. Bohužel návrh jaderného subsystému správy paměti je takový, že řadu technik bránících v přístupu lze obejít. Aktuálně koluje sada patchů, jež má za cíl tuto „díru“ zavřít, přináší však s sebou také zajímavou otázku: je jaderná komunita ochotna obětovat výkon, aby se dosáhlo lepšího zabezpečení?
Útočník, který chce, aby jádro spustilo libovolný kód, čelí problému: kam takový kód vložit, aby ho jádro mohlo spustit? V případě, že je možné jádro přesvědčit, aby spustilo kód, který se nachází v uživatelském prostoru, je mnohem jednodušší tento problém vyřešit, protože vložit kód do paměti uživatelského prostoru zvládne každý. Vzhledem k tomu, že paměť uživatelského prostoru zůstává namapovaná, i když procesor běží v jaderném režimu, vše co je třeba udělat, je přesvědčit jádro, aby skočilo na adresu v uživatelském prostoru. Před lety bylo možné jednoduše namapovat stránku na adrese 0 a najít chybu, která by způsobila, že jádro přeskočí na ukazatel na null. Takové jednoduché útoky se podařilo eliminovat, ale složitější exploity jsou stále běžné.
Je jasné, že nejlepším řeším je ujistit se, že se jádro nikdy nepokusí skočit na adresu v uživatelském prostoru. Pokud se však smíříme s tím, že chyby budou vždycky existovat, má smysl přidat další ochranu, a sice jednoduše zabránit jádru ve vykonávání kódu z paměti uživatelského prostoru. Mechanismy PaX KERNEXEC a UDEREF jsou navrženy tak, aby těmto typům přístupu do uživatelského prostoru zabránily. Nedávno se do hry přidali také výrobci procesorů: Intel nyní má SMAP (Supervisor Mode Access Prevention) a SMEP (Supervisor Mode Execute Protection), zatímco ARM přidal PXN (Privileged Execute-Never). Na systémech, kde jsou tyto mechanismy plně implementovány, by už mělo být pro jádro nemožné spustit kód, který se nachází v paměti uživatelského prostoru.
Až na to, jak stojí v příspěvku Vasileiose P. Kermelise a kol. (PDF), že existuje skulina. Paměť uživatelského prostoru je dostupná skrze stránkovací tabulky procesu a různé mechanismy prevence přístupu pracují tak, že blokují přístup do jádra právě skrze tyto tabulky. Ale jádro zároveň udržuje lineární mapování celého rozsahu fyzické paměti (na 64bitových systémech, u 32bitových systémů je to složitější). Toto mapování má v jádře četná využití, na předních místech seznamu bychom pak našli správu paměti na úrovni stránek. Každé fyzické stránce v systému poskytuje samostatnou adresu. Co je zásadní, jedná se o adresu v jaderném prostoru a na některých systémech (x86 před verzí 3.9, ARM všeobecně) je obsah paměti v tomto rozsahu vykonatelný jádrem.
Jestliže útočník přinutí jádro skočit na přímo mapovanou adresu, nedostane se žádný z mechanismů zabraňujících přístupu k uživatelskému prostoru do hry, a to ani v případě, že cílová adresa odpovídá stránce v uživatelském prostoru. Přímé mapování tedy nabízí pohodlný způsob, jak tyto ochrany obejít. Má to jen jeden háček: útočník musí být schopen určit fyzické stránky obsahující škodlivý kód. Jak vyplývá z příspěvku, soubory pagemap v /proc tyto informace poskytnou – přestože je možné tyto soubory zakázat, distribuce to obvykle nedělají. Takže na většině systémů je všechno připraveno k tomu, aby útočník mohl zneužít chybu, která by způsobila skok na libovolnou adresu, zatímco existující ochranné mechanismy by byly naprosto bezmocné.
(Trošku složitější je to na současných jádrech pro x86, kde již není možné přímo spouštět kód skrze přímé mapování. V takovém případě se útočník musí uchýlit k programování zaměřenému na návratové hodnoty (return-oriented programming) – což pro spoustu útočníků nepředstavuje velkou překážku.)
Řešením, jak bylo popsání v příspěvku a implementováno v sadě patchů exkluzivního vlastnictví stránek (XPFO), kterou zaslal Jürg Haefliger, je odebrat přístup zadními vrátky ke stránkám uživatelského prostoru skrze přímé mapování. Mechanismus je to v principu velmi jednoduchý. Kdykoli dojde k alokaci stránky pro použití v uživatelském prostoru (což jádro už teď označuje pomocí příznaků GFP v požadavku na alokaci), dojde k odstranění přímého mapování této stránky. Takže i když by se útočníkovi podařilo získat přímo mapovanou adresu stránky a přinutit jádro, aby tam skočilo, to vzhledem k nedostatku přístupových oprávnění selže. Když uživatelský prostor stránku uvolní, bude vynulována (aby se zabránilo útokům pomocí nebezpečného kódu, který ve stránce zůstal) a navrácena k přímému mapování.
Jsou samozřejmě situace, kdy jádro musí mít k paměti uživatelského prostoru přístup: funkce copy_to_user() a copy_from_user() jsou jasné příklady. V těchto případech je po dobu průběhu operace přímé mapování obnoveno.
Cenou je přirozeně výkon. Mapování a odmapování stránek v adresním prostoru jádra bude trochu zpomalovat, stejně tak nulování stránek vrácených z uživatelského prostoru. Možná, že ještě důležitější je změna implementace přímého mapování. Obyčejně jádro vytvoří takové mapování s velkými stránkami, což mj. výrazně snižuje tlak na TLB (translation lookaside buffer) procesoru při přístupu k přímému mapování. Ovšem velké stránky nejsou kompatibilní s přidáváním a odstraňováním mapování pro jednotlivé (malé) stránky v daném rozsahu, takže s přechodem na XPFO, musí jít mapování velkých stránek pryč. Dojde také ke zvýšení režie paměti vyplývající z potřeby ukládat více informací na stránce. Jinak řečeno, nastavením XPFO dojde v nejhorších případech ke snížení výkonu až o 3 %, ačkoli většina výsledků benchmarků v příspěvku výše jmenovaných autorů byla mnohem nižší.
Sada patchů vyžaduje nějaké dokončovací práce, než bude možné vážně uvažovat o jejím začlenění do upstreamu. Dá se předpokládat, že až na to dojde, stočí se konverzace k tomu, jak je sada patchů vlastně efektivní při předcházení útokům a zda za snížení výkonu opravdu stojí. Skutečnost, že zpomalení pro sestavená jádra je asi 2,5 %, by mohla představovat překážku v této diskuzi. S tak velkým úbytkem výkonu je těžké se smířit, ale totéž platí i o úspěšných útocích. Která pilulka se ukáže jako jako ta nejhořčejší, se asi ukáže, až práce na sadě patchů postoupí.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Kernel driver API tam samozrejme je, jenom je interni a meni se, coz je OK pokud je driver v mainline.
Pevné ABI není zajímavé pro vývojáře, ale spíš pro uživatele. Vývojářům out of tree driverů komplikují život změny API, kvůli kterým je musejí zaplevelit hromadami ifdefů, nejčastěji podle verzí (což je zase problém u distribučních jader). Vývojáře netrápí změny ABI, to jen znamená, že je potřeba modul přeložit proti danému jádru.
Koho zajímá ABI, to jsou uživatelé third party driverů, a to zejména těch closed source. Proto se snaží při běžných updatech zachovávat kABI enterprise distribuce. Ale taky to není žádný med, někdy se kvůli tomu musejí vymýšlet hodně divoké obezličky a občas to nejde vůbec.
naivní kódVím, že to bude nativní kód, ale překlep pobavil
.
Jinak dost nebezpečný teda, nepředpokládám, že ke všemu budou zdrojáky :-/.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz