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.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Řešení dotazu:
Jakym zpusobem zajistite, ze vas virtual provider nezkopiruje, nespusti nekde bokem, neprihlasi se do systemu a neukrade data?Nijak.
To jako opravdu? Ani sifrovani by nepomohlo? Nechce se mi verit, ze lidi tohle neresi :-OTo je asi jako říct, že se ti nechce věřit, že lidi za polárním kruhem neřeší, aby byl v zimě co čtyřiadvacet hodin bílý den. Proti některým útokům se dá dejme tomu jakžtakž bránit nebo je aspoň detekovat. Ale v případě, že má někdo v rukou celou tvojí infrastrukturu, je to jako bojovat s vlkem (klasickou) plácačkou na mouchy. Jediná slušná ochrana je mít infrastrukturu „pod zámkem“, tedy fyzický server, fyzicky chráněný.
Tak ještě jednou - neříkám že data na VPS je možné 100% zabezpečit. Ale říkám že je možné jejich získání natolik ztížit že námaha potřebná na překonání těch překážek bude nepřiměřeně velká vzhledem k ceně těch dat.Tak mi nezbývá než ti ještě jednou připomenout, že tvé srovnání je úplně zbytečné, protože v tvých úvahách úplně chybí cena a složitost samotného zabezpečení.
Takže řešit jak zadat to heslo je tady poměrně irelevantní.To, že něco neumíš, ještě neznamená, že je to irelevantní.
Ale trvám na tom že pro pár php skriptů a soukromých mailů je běžné šifrování VPSky dostatečná ochrana bez ohledu na to že existuje tucet způsobů jak ji prolomit.Myslím, že šifrování je v tom případě zbytečně silná ochrana. Pokud mají správci dotyčné VPSky jako koníčka procházet disky zákazníků a hledat tam zajímavé e-maily, nebudu se bránit šifrováním, ale odchodem k jinému poskytovateli.
Zajímavé, aeskeyfind jsem neznal. Předpokládal jsem že v dumpu fyzické paměti bude potřeba hledat key podle znalosti toho kam by si ho kernel měl uložit, ale netušil jsem že AES klíč v tom blobu lze najít hrubou silou. Díky za rozšíření obzorů :) Z readme aeskeyfind:
The program uses the following algorithm: 1. Iterate through each byte of the memory image. Treat the following block of 176 or 240 bytes as an AES key schedule. 2. For each word in the potential key schedule, calculate the Hamming distance from that word to the key schedule word that should have been generated from the surrounding words. 3. If the total number of bits violating the constraints on a correct AES key schedule is sufficiently small, output the key.
Jako ochranu před tímto druhem útoku by asi stačilo ten AES key schedule rozstrkat různě po paměti, aby nebylo všechno po hromadě. Zajímalo by mě jestli to tak novější jádra dělají když je tenhle útok známý?
Mimochodem co je 'foriana'? Nic relevantního s tímhle jménem nemůžu najít...
Jako ochranu před tímto druhem útoku by asi stačilo ten AES key schedule rozstrkat různě po paměti, aby nebylo všechno po hromadě.K tomu pak právě lze použít ta Foriana, na složení zpátky :).
Mimochodem co je 'foriana'?Druhý odkaz z Googlu, ale možná mě bublinkují.
Druhý odkaz z Googlu, ale možná mě bublinkují.
Já mám tenhle odkaz až na druhé stránce výsledků. Možná v tom hraje roli i regionální cílení - od vás je SK celkem za rohem, ode mě celkem ne, tak mi Google SK odkazy nedává. Kdo ví. Ale dík za link.
Jako ochranu před tímto druhem útoku by asi stačilo ten AES key schedule rozstrkat různě po paměti, aby nebylo všechno po hromadě. Zajímalo by mě jestli to tak novější jádra dělají když je tenhle útok známý?Jsou přístupy kdy dešifrovací klíč v paměti není vůbec - klíč je držen pouze v cache procesoru, odkud je o něco těžší ho získat. Viz. http://frozencache.blogspot.com/. Ale to může pomoci jen u některých útoků na fyzické počítače (např. u podchlazení a vyndání RAM z běžícího stroje tam pak ten klíč jaksi nikde není) a je to za cenu značné ztráty výkonu (cache obsahuje klíč a nelze ji využít na to k čemu byla původně určena). Je to omezeně použitelné asi jen v okrajových případech (např. při uspávání notebooku přemístím klíče do cache). U útoků kdy útočník může i zapisovat do paměti to pak nepomůže vůbec (dát někam do paměti kód který to z cache vykopíruje zpět do paměti na místo kde se rychle spustí je vcelku jednoduché) U VPS kde udělat snapshot paměti (včetně cache/registrů procesoru) je vcelku triviální (někdy jsou i nástroje na stěhování "živých" virtuálů na jiné fyzické stroje a udělat z toho nástroj na kopírování stroje do sandboxu, kde je následně zapauzován a hacknut je jednoduché)
Mimochodem co je 'foriana'? Nic relevantního s tímhle jménem nemůžu najít...http://hysteria.sk/~niekt0/foriana/
a je to za cenu značné ztráty výkonu (cache obsahuje klíč a nelze ji využít na to k čemu byla původně určena)Šlo to nějak ohackovat přes AES-NI, kde na udržení stavu šifry stačily nějaké debug registry a cache tak nebylo potřeba zamykat. Na kolikátém místě jsi měl ten odkaz? Pokud níže než na druhém, tak toho o mě Google ví nějak moc.
Na kolikátém místě jsi měl ten odkaz? Pokud níže než na druhém, tak toho o mě Google ví nějak moc.Na třetím ...
Jsou přístupy kdy dešifrovací klíč v paměti není vůbec - klíč je držen pouze v cache procesoru, odkud je o něco těžší ho získat. Viz. http://frozencache.blogspot.com/.Zdá se mi to, nebo tím už jsi úplně mimo kontext VPS?
takze google videl jen to, ze prostredi je cz - aspon doufamPanopticlick znáš? :)
Tím lze docílit že se provozovatel nedostane do běžícího serveru.Erm... nemá náhodou run-time k dispozici celý obraz RAM? Vzhledem k tomuto faktu mi přijde celý zbytek příspěvku tak nějak prázdný.
Nechapu proc tu dvacet lidi resi takovou trivialitu a tvrdi ze to nejde.Třeba protože před pár měsíci dostali za úkol otestovat, jak složité jer prolomit se do takové zašifrované VPS, a trvalo jim to pár minut? ;)
Samozrejme ze to neni zadnej problem.Pán je těžké king :D.
Staci disk toho VPS sifrovat - napr. pouzit LIKS.Zřejmě LUKS? Jak zákazníci zadávají heslo? Jak se zákazníci brání odposlechu toho zadávaného hesla? Jenom kecy.
Tiskni Sdílej: