Dailydave mailing list archives
So, the security industry has given up on the principles of least privilege and separation?
From: Dave Korn <davek_throwaway () hotmail com>
Date: Sat, 14 Feb 2009 15:11:34 +0000
There's a story from yesterday on ElReg, following up the ongoing issue with UAC in the win7 betas. The exploit itself (not well explained in the article, but amply illustrated by the OPs referenced there) is interesting, as much from a political point of view (it appears to be a blatantly anti-competitive attempt to give MS' apps an advantage over all others in the ability to present a smooth and pleasant user experience uninterrupted by UAC popups) as from a technical one, but the thing that boggled me was a quote from Secunia: --------------------<snip>-------------------- Thomas Kristensen, CTO at security notification firm Secunia, explained "This isn't a major issue; after all it requires that the user already downloaded some executable code and decided to run it. No matter which security features have been built into the operating system, then the user should never run code, which they don't trust in the first place. Untrusted code should only be run on dedicated test systems." [ ... ] "UAC should only be considered an extra security feature, which will remind users that the code they run potentially could harm their systems - it is not meant as a guarantee against code's ability to harm a system," Secunia's Kristensen added. --------------------<snip>-------------------- That made me snort into my breakfast cereals, I can tell you. Has the entire security industry abandoned all hope of using the principle of least privilege and limited user accounts, or just him? It's been said time and again that actually having your users running under limited user accounts is in practice a very effective measure against an awful lot of malware, breaking a lot of its mechanisms for self-propagation, installation and infection. Is that no longer the case or was it never was? Was least privilege only ever a mechanism to prevent an accidental "rm -rf *" from running away too far? It's easy to say that the user must never get "untrusted" software on there machine, but that don't help Joe Sixpack much; how's he supposed to "trust" an impenetrable blob of binary? He's not a reverse engineer, and can't be expected to be; so isn't it a good idea that there should be a way for him to run processes in a constrained fashion that won't give them the ability to modify the system? Perhaps there always going to be loopholes in any such restricted-user account, maybe not; even so, would that make it worthless in day-to-day use? I was surprised, anyway. I thought (unauthorised) privilege escalation was an exploit and desirable to prevent; I didn't expect a security commentator to describe it as just one of the things you should expect from life as routine. Why did we spend all those years berating MS for installing everything with admin rights by default, if it was fine all along? Why doesn't everyone just give all there *nix users root, if it doesn't matter? cheers, DaveK -- [*] - http://www.theregister.co.uk/2009/02/13/win7_uac_attack_demo/ _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- So, the security industry has given up on the principles of least privilege and separation? Dave Korn (Feb 14)
- Re: So, the security industry has given up on the principles of least privilege and separation? Michal Zalewski (Feb 16)
- Re: So, the security industry has given up on the principles of least privilege and separation? Joanna Rutkowska (Feb 16)
- Re: So, the security industry has given up on the principles of least privilege and separation? Andre Gironda (Feb 16)
- Re: So, the security industry has given up on the principles of least privilege and separation? Michal Zalewski (Feb 17)