/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