/dev/mem (was: SucKIT)

Pavel Kankovsky peak na argo.troja.mff.cuni.cz
Sobota Březen 30 20:47:58 CET 2002


On Thu, 28 Mar 2002, Karel Zak wrote:

>  Snad by bylo v silach jadra hlidat kam v tech souborech (pameti) kdo
>  leze (pise) a nektere casti napr. sys_call_table ohodnotit SIGKILL
>  pro dany program. Nevim do jadra nedelam...

To je -- pri vsi ucte -- dost legracni napad, protoze je to skoro
slozitejsi, nez zabranit zapisu do veskereho kodu a dat jadra, resp.
primo povolit jen pristup k adresam, kde je namapovano to zarizeni,
se kterym chce prislusny program pracovat. Ale hacek je prave v tom,
jestli mohu zabranit, aby bylo mozno zarizeni instruovat k tomu, ze
toto zarizeni samo pristupovalo do hlavni pameti (tj. oklikou mimo
veskere ochranne mechanismy, kterymi muze jadro chranit samo sebe a
jine procesy). Pochopitelne bez toho, abych poprel cely smysl toho, ze
proces ziska primy pristup k pameti zarizeni -- samozrejme muzu mit
syscally read_device_mem a write_device_mem, ale kazdy asi tusi,
jak to bude v typickem pripade rychle.

> > Primy pristup na I/O je v principu stejne nebezpecny, jako primy pristup
> > do pameti jadra (resp. fyzicke pameti). What's the point?
> 
>  Jde o to co je to "nebezpecne", jde pomoci toho nerusene odposlouchavat
>  hesla a poslat tak do kytek svet uzasneho sifrovaciho software? Nebo
>  je ta nebezpecnost v tomto pripade jen v moznost neco znicit?

To zalezi na tom, co ten "zly" hardware, ktery bude pouzit, umi. Nicmeme
v pripade, ze umi precist ci zapsat kazdy jednotlivy bajt RAM, pak lze
volne cist (v prvnim pripade proste budu primo cist, v druhem pripade
musim upravit kod jadra, napr. implementaci nejakeho mene obvykleho
syscallu, aby toto cteni provadel).

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."



Další informace o konferenci Linux