Dotaz: Ochrana citlivých informací v paměti

[xYz]

Ahoj, nemohl by mi někdo postnout linky k přečtění, které se zaobírají architekturou/stylem programování v případě práce s citlivými informacemi? Např. jak pracovat s hesly či jak zobrazovat citlivé informace? Zajímá mě technika ochrany proti obyčejnému memory dumpu.

Díky.

Odpovědi

[rADOn]

Proti prohlizeni cizi pameti te chrani operacni system. Co presne te trapi?

[xYz]

Řešíme principiální problém log-in dialogem, kde uživatel do TextBoxu zapíše heslo, které je sice zobrazené jako hvězdičky, ale někde v paměti je to uložené jako obyčejný string/char buffer.

[Jendа]

Tak ono to ani jinak nejde a dělají to tak všichni (viz strings /proc/kcore nebo /dev/mem).

[rADOn]

No to je principialni problem jak svina Ze jsou data v pameti je zakladni vlastnost Von Neumannovsky architektury. Jestli si chces zahrat bezpecnostni divadylko, muzes to heslo za behu kryptovat nejakou proudovou sifrou. Vypada to desne tvrdacky kdyz mas misto hesla hromadu rozsypanyho caje. Trochu to kazi fakt, ze aby to fungovalo musis mit klice v pameti kde je utocnik vidi stejne snadno jako samotny heslo. A to je zakladni problem, muzes vymymslet libovnej pocet vyfikundaci ktery vypadaji jako bezpecnost, ale pokud je utocnik privilegovanej a muze cist pamet, muze jakykoliv tvuj algoritmus proste zopakovat. Jediny ucinny reseni je specializovanej hardware - v PC to nejspis bude TPM modul. Nektery notebooky je maji, ale to uz je vyssi divci. Bez urazky - jestli se musis takhle ptat tak TPM modul nenaprogramujes ani kdyby te osvitil duch svatej

Nejlepsi obrana pro tebe bude ta nejjednodussi, proste nenechat utocnika dostat privilegovanej pristup. Bytelnej kernel, zapatchovany aplikace, takovy ty veci. Zakladni zabezpeceni. Jestli nemas moc co delat tak muzes kouknout na selinux, apparmor, NX bity. A heslo samozrejme po zadani rozemlit na sracky nejakym hezkym hashem.

[xYz]

Ne, řeším pouze to, aby při obyčejném memory dumpu nebyly ty hesla hezky vyskládaný vedle sebe v ASCII pro každého k přečtení. V dotNet na to mají hezkej class zvaný SecureString a defaultní LoginDialogy ho používají. Takže sháním nějaký whitepaper pro programátory, jak se chovat k citlivým informacím obecně.

[Jendа]

Ne, řeším pouze to, aby při obyčejném memory dumpu nebyly ty hesla hezky vyskládaný vedle sebe v ASCII pro každého k přečtení. V dotNet na to mají hezkej class zvaný SecureString a defaultní LoginDialogy ho používají.

Není to security by obscurity? Stačí, aby majitel dumpu zopakoval algoritmus pro získání hesla a má to. Leda, že by se ta data držela např. v cache procesoru a ne v paměti, ale to nevím, jestli jde.

[Bilbo]

Teoreticky lze drzet mensi mnozstvi dat v cache procesoru (nekde jsem videl clanek co se zabyval moznosti drzet tam klic k sifrovanemu disku), ovsem v praxi se diky organizaci cache tim ze se cast ucpe sifrovacim klicem dost snizi vykon. Takze spise nepouzitelne.

Navic tim chrani jen pred utokem zvenci (cteni pameti pres firewire, pokropeni dusikem a vyundani, ....) ale uz ne pred ctenim zevnitr (napr. pomoci ruznych volani operacniho systemu) protoze pak procesor proste precte a vrati to co je v cache.

SecureString je tak trochu security through obscurity (utocnik musi jeste v pameti o kus vedle najit desifrovaci klic), ale zase ma vlastnost, ze pote co neni potreba (tedy tesne pred dealokaci) se obsah prepise narozdil od obyc stringu nulama. A to uz muze v praxi pomoct, pokud se heslo po zadani nejak rychle zpracuje, a nekam posle (pripadne se s nim neco desifruje) a pak lokalne smaze tak se tim snizi cas kdy ho lze vytahnout z pameti memory dumpem treba jen na par milisekund.

Takze tip: pred dealokaci citlivych dat (heslo, ...) je prepsat nulama.

Na druhou stranu, pokud se nekdo dostane k systemu tak, aby mohl provest memory dump, tak obvykle ma dostatecny pristup k tomu, aby mohl nasadit i keylogger

[Bilbo]

Otazkou je ale kdo je utocnik.

Uzivatel sam? Ten ale heslo zna.

Nekdo jiny kdo pouziva tentyz pocitac? (Cili pocitac sdileny ruznymi lidmi?) Tady je potreba ten pocitac zabezpecit, jakmile nekdo z lidi tam ziska roota tak muze nainstalovat keylogger, tim ziska heslo a nejakym snaham ochranit cosi nekde v pameti se zvysoka smeje.

Je nutne uvazit i vice ci mene sofistikovane utoky typu ze tam nekdo nastrci aplikaci co se tvari jako prihlasovaci formular, ale ve skutecnosti heslo uklada/posila kamsi ....

Nekdo "zvenci"? Jakmile se mui povede ziskat nejaky pristup k systemu tak viz predchozi pripad ...

Pochopitelne, ze pokud se heslo hned po zadani bud zahashuje nebo rovnou znici (napr. pokud je pouzito k autorizaci na vzdalenem serveru a lokalne neni potreba) tak to nektere typy utoku znesnadni, pripadne znemozni. Ale absolutni ochranu to nezaruci.

[xYz]

Jasně, neřeším _všechny_ ochrany světa, ale jenom guidline pro programátory, jak se principiálně chovat k citlivým informacím. Při analýze jednoho memory dumpu jsme objevili heslo pěkně vysázené po sobě, takže teď sháním, jak tohle pořešit + něco navíc k problematice.

[Jendа]

Zajímá mě technika ochrany proti obyčejnému memory dumpu.

Pokud má útočník roota, nepomůže ani svěcená voda.

Pokud má útočník fyzický přístup k počítači, pomůže zalití epoxidem a deadman switch.

Pokud jde o normální systém, pracuj s hesly jako s ostatními daty.

jak zobrazovat citlivé informace

Určitě bych se nejdřív uživatele zeptal Opravdu chcete zobrazit…?, aby mohl dát Ne, pokud mu zrovna někdo kouká přes rameno.

[pht]

aby mohl dát Ne, pokud mu zrovna někdo kouká přes rameno.

LOL... ono je spíš zvykem, že když pracujete s citlivými daty tak si ohlídáte kdo stojí za Vámi, případně ve stejné místnosti.

[pavlix]

LOL... ono je spíš zvykem, že když pracujete s citlivými daty tak si ohlídáte kdo stojí za Vámi, případně ve stejné místnosti.

Spousta systémů neumožňuje oddělit práci s daty různé úrovně citlivosti/utajení. Typickým příkladem je konfigurace wifi, kde se nastavuje společně jméno sítě s dalšími údaji a heslo (je jedno jestli je to desktop, nebo webové rozhraní nějaké krabičky).

Typicky je heslo citlivějším údajem než ty ostatní a typicky je uživatel cháněn proti jeho neúmyslnému zobrazení. Ale oproti třeba přihlšovacímu heslu do systému, bývá zvykem umožnit uživateli i zobrazení toho hesla.

[Bilbo]

Pár užitečných tipů je třeba tady:

https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard

[FooBar]

Link co padl vyse je skvelej, ja jen dodam jednu pomerne zasadni poucku -- citlivy data vzdy mlockni do pameti (a verifikuj ze se to povedlo), v opacnym pripade ti hrozi, ze se vyswapujou na disk a tam budou hezky perzistentne k dispozici.

[Jendа]

Počítač pracující s citlivými daty by podle mě měl mít zašifrovaný disk a tedy i swap. Samozřejmě záleží na konkrétním případu a citlivosti dat, to ale tazatel neuvádí.

[FooBar]

To by sice mozna mel, ale dotaz padl jednoznacne na vlastnosti vyvoje software.

[Bilbo]

Tak kdyby tazatel aspon nastinil co se snazi naprogramovat, tak bychom mohli dat lepsi rady, nicmene krome toho, ze se to naprogramuje spravne je nutne resit i zabezpeceni toho hardwaru a systemu kde ten software pobezi - napr. sifrovany swap, sifrovany disk, intrusion sensor, minimum bezicich sluzeb (mensi sance na nejaky remote root exploit), restriktivni konfigurace, atd ...

Absolutni ochrana proti memory dumpu asi neexistuje - jakmile se utocnik dostane fyzicky k masine, tak je celkem dost technik (vice ci mene slozitych) jak ziskat data z pameti (firewire, specialni karta strcena do volneho slotu, napojeni se na sbernici, aplikace tekuteho dusiku na pameti a jejich precteni v jinem stroji, atd ...)

Vhodnym programovanim lze ale minimalizovat dobu po kterou jsou citliva data v pameti a tedy i okno, behem ktereho je lze nekterou z techto technik ziskat.

A pokud jsou v masine nejake senzory (cidlo, kamera ....), co vcas detekuji pokus o cteni pameti nejakym hardwarovym zpusobem (napr. pres tekuty dusik a vydloubnuti pameti) tak to jde resit specialnim modulem v kernelu co behem par vterin prepise celou RAMku nesmyslama: http://hysteria.sk/~niekt0/alzheimer/

[xYz]

Hledám guideline pro programátory jak řešit situaci, kdy úmyslný/neúmyslný memory dump zobrazí uživatelské heslo pěkně v ASCII vysázené v paměti. Pouze tento specifický problém, žádné čumění přes rameno či strkání karet do počítače.

[JS]

Tohle by me taky zajimalo, hlavne v jazycich, co si spravuji pamet sami (Java, C#).

[xYz]

V případě zadávání hesla má .Net class SecureString.

[JS]

Diky!