movemoor op woensdag 05 oktober 2005 13:08:
> Nog beter is om helemaal geen admin rechten te
> gebruiken
Dat is verstandig, maar toch iets anders. Geen admin rechten
betekent, bij een goed geconfigureerd systeem, en ervan
uitgaande dat de privilege escalation mogelijkheden niet
voor het oprapen liggen, dat je
systeem niet
aangetast kan worden door foute code die jij als gebruiker
start. Het biedt echter geen enkele bescherming voor jouw
eigen files (inclusief die op netwerk shares etc).
Dergelijke code kan ook namens jou emailen, jouw keyboard
sniffen en jouw HKCU...Run registry key of rc scripts
wijzigen etc.
Dus ook als je
geen admin rechten hebt, is het een
goed plan om potentieel "lekke" of anderszins risicovolle
applicaties geen full control over jouw eigen bestanden te
geven, maar die onder een
ander account, natuurlijk
met minimale rechten, te draaien. Dit idee is niet nieuw.
Bijv. in de Duitse c't 2003 nummer 21 wordt voorgesteld om
IE onder een ander account te draaien, en onder Unix/Linux
e.d. is het gangbaar om services onder een speciaal, less
privileged, account te laten werken.
M.b.t. de steeds terugkerende "kernel" discussie: Internet
Explorer en Explorer zijn helemaal geen "kernel" componenten
maar een shell, die gewoon draait met de privileges van het
account waar je mee inlogt; in zoverre zijn ze goed
vergelijkbaar met andere browsers en shells. Hoewel ik
privilege escalation exploits via IE (bijv. in een
schermdriver) niet 100% uitsluit kan ik me niet herinneren
er ooit over gelezen te hebben. Ligt ook niet voor de hand
zolang verreweg de meeste gebruikers met admin rechten werken.
Het probleem zit in het feit dat het het hele "alles is een
webpage" concept zo diep in deze shell en user interface
geworteld zit, en dat (Internet) Explorer uit veel losse
componenten bestaat die via uiteenlopende routes kunnen
worden opgestart, en dus ook internetverbindingen maken.
Denk aan het Media Player DRM probleem begin dit jaar (MP
gebruikte IE componenten, OOK als je een andere webbrowser
als default had ingesteld, om op het web te checken of je
rechten had om de media file af te spelen; via die route kon
malware je systeem in geloodsd worden). Zie "Microsoft: DRM
Trojan hole is not a vulnerability":
http://news.zdnet.co.uk/internet/security/0,39020375,39184120,00.htmen niet lang daarna, quote er uit:
"No DRM is perfect," said David Caulton, group
product manager in the Windows Media division. "This is
another example of somebody finding a way around the
technology that we didn't think about.
http://news.zdnet.co.uk/internet/security/0,39020375,39188216,00.htmMet een "runas" -achtig commando dat iexplore.exe onder een
less-privileged account opstart ben je dus er helaas niet
(aan de grootte van dat bestand kun je al zien dat het niet
veel meer dan een wrappertje is om een reeks DLL's, te
vinden in System32). Het lijkt me op z'n zachtst gezegd een
"uitdaging" voor Microsoft om dit in toekomstige windows
versies goed dicht te timmeren, dus dat elke applicatie (of
DLL, OCX etc.) die internet verbindingen initieert dat onder
een gelimiteerd account doet of de "rechten" van die
applicatie op andere wijze inperkt.
Ook het idee om "privileges", of "capabilities" aan
applicaties toe te kennen (of niet), is niet nieuw.
Deze moeten niet verward worden met permissies, waarmee voor
groepen en gebruikers toegang tot objecten zoals bestanden
wordt geregeld; privileges gaan van de gebruiker (acties
dus) uit, zoals bijv. het recht dat
jij al dan niet
hebt om de systeem datum en tijd te mogen wijzigen.
Het feit dat de programmeur van elk programma dat jij
opstart kan doen en laten met jouw bestanden wat hij wil, is
historisch zo gegroeid en mogelijk de makkelijkste weg, maar
zeker niet de verstandigste. Zo is er zelden een reden voor
programma's om willekeurige bestanden met uitvoerbare code
te kunnen wijzigen; zoiets zou je best met privileges kunnen
dichtzetten (bijv. een trusted hexeditor voor binaire
bestanden, een idem text-editor voor scripts etc. waarbij
beide dat privilege pas krijgen nadat een digitale
handtekening door het OS is gecheckt). Indien goed toegepast
zijn exe-file besmettende virussen kansloos. Voor de hand
liggen ook privileges die code toestaan om als client
internet verbindingen te starten, of zelfs een listening
port aan te maken. Als je dat goed in je OS weet te
verwerken hebben we ook geen halfbakken firewalls nodig die
uitgaand verkeer proberen te regelen (maar telkens weer te
bypassen blijken).
Uit oogpunt van beheer konden deze code-privileges wel eens
knap lastig worden, maar het zou mij niet verbazen als we
deze kant op gaan. N.B. ik ben absoluut geen expert op dit
gebied, maar vind het wel erg interessant.
In dit artikel "Securing a Linux Kernel" van Prabhaker
Mateti uit 2004 worden o.a. "capabilities" aangekaart:
http://www.cs.wright.edu/~pmateti/InternetSecurity/Lectures/LinuxSecKernel/Erik van Straten