A Blog for Graymad

You can also look at it this way: it's my system, why can't I do on it what I want? AND why are intrusive programs not ran in a sandbox?

Especially the second issue is way more important than saying 'don't run as administrator'. Because the way some applications are ran in IE/with IE, make it possible to hack a system by running code under administrator privileges. By saying 'don't run as administrator' you are trying to solve the symptoms, why you should solve the cause: insecure ways of running logic that is pulled from an outside source.

"You can also look at it this way: it's my system, why can't I do on it what I want? AND why are intrusive programs not ran in a sandbox?"

For the first part, because you are connected to a network, and your actions impact others. If you are running as admin, and get infected by a virus that requires admin privileges to propagate, you cause problems for others. If you want to disconnect your machine from the Internet, and never connect it again, be my guest and do whatever you want.

For the second part, you aren't demonstrating a very good grasp of how software operates in Windows. If we could convince malware authors to only write in managed code, then sandboxing would be a breeze. But given the way unmanaged code operates in Windows, it would be impractical to sandbox all code without breaking a very large number of programs, if it could be done at all.

And neither of those addresses the other problem with running as admin...if you're developing software as admin, you may end up with software that will not run correctly for normal users. When users run into problems with your software, the most likely way that they'll work around it is to run as admin themselves, thus perpetuating the problem.

"Especially the second issue is way more important than saying 'don't run as administrator'. Because the way some applications are ran in IE/with IE, make it possible to hack a system by running code under administrator privileges."

This is *not* just an IE issue. This applies to email attachments, ActiveX controls, and spyware that you may inadvertently install, thinking it's something useful.

"By saying 'don't run as administrator' you are trying to solve the symptoms, why you should solve the cause: insecure ways of running logic that is pulled from an outside source."

I'd love to hear what your magic solution is Frans. I haven't heard anything from you that remotely approaches an actual solution, nor have I heard any justification for why you *need* to run as an administrator, other than that you feel like it and you don't like being told what to do. You're certainly entitled to your opinion, but your attitude is fairly selfish given that your determination to do what you want may well impact others.

this is helping me learn....

http://www.develop.com/kbrown/book/

"For the first part, because you are connected to a network, and your actions impact others. If you are running as admin, and get infected by a virus that requires admin privileges to propagate, you cause problems for others. If you want to disconnect your machine from the Internet, and never connect it again, be my guest and do whatever you want. "
But how am I going to get infected with a virus if all external content is sandboxed? That's what I'm trying to say: if you CAN'T get a virus, you will also not propagate it further. Like the virusscans on outgoing mail. That's nonsense since you don't have a virus present, so you can't send one along too.

All programs on my machine are running with local content and are started locally. All programs coming from an external source are thus or opened in a browser or via an email. If these sources are sandboxed, they will never be able to have any effect on my local machine nor on the health of the network.

But because that's not the case, we have to fall back to 'don't run as administrator'-kind of behaviour.

You know, not running as administrator is not helping you one bit. This is because the windows shell contains a race condition via gui elements of applications running under another user with higher privileges. In other words: as long as you can start a program on a machine with an open shell (and you are working on the machine, aren't you? ;)) the program you start will be able to evelate its access rights. So you have to effectively lock down your complete machine. If you don't believe me, search on bugtrack why it is dangerous to have a gui in a service running as system. You locked down your virusscanner service with gui, didn't you? That's why it is silly to tell everybody not to run as administrator, because it is not safer. Furthermore, it will give you problems in all kinds of areas with applications, f.e. visual studio.

For whom are you locking the machine down? You're the one working on the machine. The more you lock down the box, the more you will loose time working around the lockdowns.

What DOES help more is paying attention you will not open up the box to external software or software which opens the box for you: virusscan attachments, strip off any attachments which are executable, be aware of what you install on your machine and if you are unsure, do not install the software.

On which level do you run your software now, if I may ask? Power user? I hope not, as that's also pretty powerful. A normal user then? How much time do you loose in your 8 hour/day development time? I tried, I lost a lot, it was so darn annoying I put some thinking in it to avoid intrusion AND be able to run the software on MY machine how I want to.

Agreed, when your main task is typing texts in word, you don't need to have admin privileges. Developing software is another thing.

"I'd love to hear what your magic solution is Frans. I haven't heard anything from you that remotely approaches an actual solution, nor have I heard any justification for why you *need* to run as an administrator, other than that you feel like it and you don't like being told what to do. You're certainly entitled to your opinion, but your attitude is fairly selfish given that your determination to do what you want may well impact others. "
I'm selfish? I'm realistic and you're not. You also close your eyes for the real reasons why you think you have to run stuff as a non-admin user. I'd be happy to switch to a normal user, if I could do what I want to do on my machine and I'd be really safe. Because of certain shell leaks I'm not, so why bother? Better keep the doors closed, and I mean: all doors. Do you keep your doors locked when you're at home? Why not?

I'm in general against 'solving the consequences'-policies, because it will never solve the real cause. If everybody tells eachother "Do not run as administrator", it looks like the problem is solved, but it is not: what you can do is what an intruder can do and probably more due to some sideeffects in the windows gui and services.

And that while it is so unnecessary as the windows core security system is so well designed, much better than Unix' system for example (security descriptors per object). The problem is however that the shell is developed too sloppy, a lot of win32 applications are not developed with security in mind.

On Linux and Unix for example, applications do not ask for an 's' bit, simply because no user has that access. So running as non-root (or no 'euid'==0) is not a problem. There are also no problems with leaks to processes which do run with real-uid == 0.

It's that last fact which makes it easier to run as non-root or your applications without the 's' bit set.

To sum it up: I'm all ears for a solution for stopping intrusive code. But running as non-administrator is not the solution, that's solving one of the many consequences of having code which allows intrusion. I mean, the main application which you'll use to get access to the outside world (and thus connecting that outside world to your box!) is IE. IE can access any element in your machine and often has to. Ever wondered why? Why is all that necessary when you simply want to visit a website. If IE and Outlook/Express were properly sandboxed it wouldn't be such a problem and if the windows system setup wouldn't have been setup for openness, everybody would have been running as normal user for years already.

I hope with vs.net 2005 and OTHER applications' next versions (software development as a normal user with accessing / setting up databases, IIS websites, vs.net projects etc. is a pain, really it is) we all can move away from being an administrator or poweruser. Today however it's better to keep your eyes open and think 3 times before you install something or use stuff like IE. (that hole of last week: I read a document in .chm format and it can access my machine... why? THAT's the problem so THAT should be fixed.).

For more info: http://security.tombom.co.uk/shatter.html (there are many other documents documenting other exploits)

Andrew: I'm on your side, I just want to point out that solving the consequences is not bringing us anything, except annoyance in our daily development job. I do have tried running as a normal user, however it is impossible because of limitations in several applications which I need for my development work. One indeed being remote debugging.

Frans wrote:

"But how am I going to get infected with a virus if all external content is sandboxed? That's what I'm trying to say: if you CAN'T get a virus, you will also not propagate it further."

You're living in a fantasy world, Frans. Can you name ONE OS where all external content is guaranteed to be sandboxed, regardless of the privileges you're running under. I don't know of any, and Windows certainly isn't one. It might be nice if this happened eventually, but for now we have to deal with the reality that exists, which means the possibility that external code CAN execute with the privileges of the user that runs it.

"All programs coming from an external source are thus or opened in a browser or via an email."

Not necessarily. What about (don't know if you have any) when your kids download the latest peer-to-peer file sharing client without realizing that it also installs a bunch of spyware? If you're allowing them to run as admin, too, then they can install and/or run all kinds of potentially dangerous crap. It's not just mail-borne viruses that are at issue, so sandboxing isn't going to solve the whole problem.

"If these sources are sandboxed, they will never be able to have any effect on my local machine nor on the health of the network."

And *then* you'll complain that the code that you're running intentionally doesn't have access to any functionality you want it to have. Again, sandboxing may be a useful feature, but it's not the end-all-be-all solution.

"You know, not running as administrator is not helping you one bit. This is because the windows shell contains a race condition via gui elements of applications running under another user with higher privileges."

Which GUI elements are you talking about here? Yes, there are services that run with higher privileges, but those are issues that should be resolved as well. I would note that if you run MBSA on a machine that has SQL Server installed, it will warn you if you're running the SQL service as SYSTEM, for the exact same reasons that I'm discussing here. Running with elevated privileges when it's not necessary to do so is a poor practice.

"If you don't believe me, search on bugtrack why it is dangerous to have a gui in a service running as system."

I don't recall arguing otherwise. The principle of Least Privilege applies to services, as well as to how you log into your machine. Use the lowest possible privilege to get your work done. When you need to elevate privilege, do so for the smallest scope possible. They're pretty simple notions, Frans, although the implementation can take some practice.

"Furthermore, it will give you problems in all kinds of areas with applications, f.e. visual studio."

I've been running as a normal user for more than a year now, including developing in Visual Studio, and I've not run into anything I can't do that I need to. Where necessary, I elevate my privilege, typically by running a command line with admin privileges. But there is ZERO need to log into my machine as Admin. There's NO reason that Word, Outlook, etc. need to be running with elevated privileges. Even if you're correct that arbitrary code can elevate its own privilege, why should I make it any easier?

"For whom are you locking the machine down? You're the one working on the machine. The more you lock down the box, the more you will loose time working around the lockdowns."

I would consider any time lost to workarounds to be a wise investment against having to completely re-build a machine from the ground up, which is the only completely safe response to getting infected with malware. Furthermore, I would argue that once you know your way around a command line, you can get your work done *faster* the way I do it.

"On which level do you run your software now, if I may ask?"

I run as a normal user. No elevated privileges for my logon account, other than belonging to the VS Debuggers group. When necessary, I use a command line running with Admin privileges to run commands such as compmgmt.msc, control panel applets, etc., to take care of tasks that require elevated privileges.

"How much time do you loose in your 8 hour/day development time? I tried, I lost a lot, it was so darn annoying I put some thinking in it to avoid intrusion AND be able to run the software on MY machine how I want to."

As I said earlier, I don't think I lose any time as a result of running the way I do. Perhaps if you'd spent the time you were "thinking" in researching how to work as a non-admin, you'd've had an easier time of it. I would recommend that you take a look at "Writing Secure Code, 2ed" by Michael Howard, and Keith Brown's Web site (http://www.develop.com/kbrown/book/html/lifestyle.html) for both the justification for what I'm saying here, as well as tips that make life as a non-Admin considerably less painful, if not easy.

Do you consider yourself more of an expert on Windows security than Michael Howard? He's the point man for the Secure Windows Initiative at Microsoft. And he runs his machine as a normal user (http://blogs.gotdotnet.com/mikehow/PermaLink.aspx/5f0bd4f8-7d75-4c4e-b8d7-e1c7b43e5211). Do you know something that he doesn't?

"I'd be happy to switch to a normal user, if I could do what I want to do on my machine and I'd be really safe."

You're never *really* safe. But you can take steps to be *safer*. I've provided resources that will allow you to "do what [you] want to do" while increasing your safety. It's up to you whether or not you actually take a look, or keep insisting that it's too hard, or wastes too much time.

"Because of certain shell leaks I'm not, so why bother?"

Can you please post some specifics here? I'd be interested in knowing what you're talking about, but your statements regarding "shell leaks" are so general as to be impossible to respond to.

"Better keep the doors closed, and I mean: all doors. Do you keep your doors locked when you're at home? Why not?"

I'm not sure what you're getting at here, but of course I keep my doors locked when I'm at home. Perhaps it's overly cautious, but the cost of making a mistake is too high to be otherwise, IMO.

"I'm in general against 'solving the consequences'-policies, because it will never solve the real cause. If everybody tells eachother "Do not run as administrator", it looks like the problem is solved, but it is not: what you can do is what an intruder can do and probably more due to some sideeffects in the windows gui and services."

Again, please provide some specifics. I'm all for arguing for better sandboxing of code, and we've got partway there with managed code. But I think you're wrong that sandboxing can completely solve the problem. Unless you completely remove the ability to run unmanaged code, there will ALWAYS be potential attack vectors for mobile code. Least privilege, therefore, will ALWAYS be a part of the solution, IMO. And, as I already pointed out, mobile code is not the only reason to use least privilege when developing software.

"IE can access any element in your machine and often has to."

Documentation, please? I've never heard of this, and it runs counter to my understanding of how processes run in Windows. If I run iexplore.exe from a non-admin account, it should not be able to access any resources that that account does not have permissions to. If that's not the case, it would be a complete violation of the entire Windows security system. So I have a hard time believing that your assertion is correct. I'll be happy to look at any documentation of this that you can provide, though.

"Today however it's better to keep your eyes open and think 3 times before you install something or use stuff like IE. (that hole of last week: I read a document in .chm format and it can access my machine... why? THAT's the problem so THAT should be fixed.)."

But that's a perfect example of what I'm talking about, Frans. The IE CHM vulnerability (http://www.kb.cert.org/vuls/id/323070) can only run arbitrary code "with the privileges of the user running IE". So you, running as admin, are vulnerable until you learn of the vulnerability and stop opening any CHM files with IE, or get a patch. Meanwhile, I'm running IE using a non-admin account. So even assuming that I opened a malicious CHM file, the damage that could be done would be limited.

As long as software is written by humans, it will continue to occasionally have vulnerabilities. Running that software with elevated privileges will increase the likelihood that these vulnerabilities will result in damage to your system, and possibly to propagation of malicious code to other systems. Why do you find this so hard to grasp? It's not a question of whether I'm addressing the cause or the symptom. It's a question of following sensible security practices to protect myself and others.

One last thing. You mentioned Unix and Linux. How many *nix users do you know who run as root?

Have you even read the doc on the link I posted? It will teach you that running software under normal user privileges is not helping you.

The problem is that any software you run can hurt your system in one way or the other. A process can still send a virus on your behalf via Outlook via automation, if you have outlook open.

I.o.w.: running as a normal user gives you a false sense of security that is not there.

btw, running as normal user to avoid misery requires excessive policy definitions as well. Otherwise, a mailicious CHM file can still harm you in a very bad way.

I don't know any Linux users who run as root. Suse 9.x doesn't even allow you to login as root. I do know however that every Windows XP home user runs as administrator.

"Suse 9.x doesn't even allow you to login as root"
I of course meant: Suse 9.x' XWindows system..

"Have you even read the doc on the link I posted? It will teach you that running software under normal user privileges is not helping you."

Yes, I read it. And it teaches me nothing of the sort. What it *may* teach me is that there are more steps I need to take to ensure that I'm not vulnerable to this particular class of vulnerability, that is, ensuring that I'm not running interactive services using LocalSystem. As it happens, this is also a fairly standard recommendation relating to least privilege.

Here's the difference I see between me and you, Frans. You see the problem described by Chris Paget, throw up your hands and say "can't be fixed, so I might as well run as Admin". I say "do everything I can to reduce privileges, and reduce attack surface, and if there's something I can't fix, at least I've made it somewhat harder to exploit my system."

"I.o.w.: running as a normal user gives you a false sense of security that is not there."

I disagree. Just because it is *possible* to elevate privileges in the way you describe does not alter the fact that running as a non-admin eliminates a whole class of malware that do not use the techniques you describe. So running as a non-admin doesn't solve *all* security exposure...so what? Security is not all or nothing, it's incremental.

Again, as far as I can see, all you're doing is throwing up your hands and giving up. I don't disagree with you that ideally, code would be sandboxed, but that's not the case today, and it's not likely to be the case for unmanaged code in the near future. So if there are problems with privilege elevation vulnerabilities, then the solution is not to just say "screw it" and run as admin. The solution is to address those vulnerabilities.

"I don't know any Linux users who run as root. Suse 9.x doesn't even allow you to login as root. I do know however that every Windows XP home user runs as administrator."

And that would be one reason why I neither run XP home, nor do I recommend that anyone who cares about security run it.

"Yes, I read it. And it teaches me nothing of the sort. What it *may* teach me is that there are more steps I need to take to ensure that I'm not vulnerable to this particular class of vulnerability, that is, ensuring that I'm not running interactive services using LocalSystem. As it happens, this is also a fairly standard recommendation relating to least privilege."
You can't prevent winlogon or csrss to have windows on the desktop. That's the point. You can try hard, and I'm sure you will, but it won't be of any use, sadly enough.

"Here's the difference I see between me and you, Frans. You see the problem described by Chris Paget, throw up your hands and say "can't be fixed, so I might as well run as Admin". I say "do everything I can to reduce privileges, and reduce attack surface, and if there's something I can't fix, at least I've made it somewhat harder to exploit my system." "
How on earth could you possibly know what I've done to limit the attack surface and what I know about system security? Do you run a hardware firewall? Do you run IE with tight security on local files and 'intranet' souces? (I don't use IE at all btw, for security reasons).

I find it nobel of you that you try hard and want to tell everybody to try hard as well. I'll be next to you shouting that everybody should try hard to limit the attack surface. However please understand that a system which looks like 'somewhat harder to exploit' is simply an exploitable system, nothing has changed. There is no 'somewhat secure system'. It's OR secure, OR not, but no half-baked secure system.

Most attacks require access from outside the system and this is preventable with various techniques. An attach which requires 'local access' is often considered a 'non-fixable' exploit, as local access also means that you can slam in a bootable cd and boot some other OS to attack the HDD. The problem is: by your access to the system, you give malicious code local access to the system. Preventing it from doing anything is also preventing YOU to do anything. As I said: what you can and may do is also what the malicious code can and may and WILL do, plus it will (likely) use exploits to elevate its privileges. Btw, it doesn't take admin priviliges to format C: using format.com, and it doesn't take special privileges to log you off (Call win32's ExitWindows()).

"I disagree. Just because it is *possible* to elevate privileges in the way you describe does not alter the fact that running as a non-admin eliminates a whole class of malware that do not use the techniques you describe. So running as a non-admin doesn't solve *all* security exposure...so what? Security is not all or nothing, it's incremental. "
No it's not. It's all or nothing, because 1 exploit can be used to get a step higher on the ladder to be able to do something more so another exploit is usable etc.

Back in 1992 in an internship for a Unix firm, I did work on a distributed calculation system (150 sparc stations working as 1 supercomputer). I had to run the software under elevated privileges so they gave me a script which simply ran the app specified with the privileges of the script, which had the 's' bit set. This means that your effective uid is 0 (root) but your real uid is still your uid. They said: you can't use this to get root access (as an intern they didn't want me to have that obviously). It took me 20 seconds. Why? Because the script could be used to run a small C program which simply called a system lib to set the real uid a process ran under. That system call only worked if your effective uid was 0. So 2 small C programs later I was root. I used a small step up to get access to a higher level routine which made it possible to get higher on the ladder to become root.

For hackers who want to do you harm, the slighest hole is enough.

I simply couldn't run under normal user privileges because I couldn't remotely debug on my dev server and some other annoyances. So the only thing left was pay attention and prevent malicious code from entering whatever process on my systems. The same thing you do only I do know that whatever I do, it will never be enough, while not running as administrator might (perhaps you do realize it) give you the false feeling you're secure, while you're not.

I read in Longhorn any interactive session is not having any direct connection with system elements, which is a great thing to have. Let's hope they'll port it back to XP (or at least try) and also that they patch VS.NET 2003 to have normal behaviour under non-admin accounts.

I do know what I'm talking about, Andrew, trust me :) I'm just saying: please, don't be fooled by the feeling you're secure now, because you're not, because there is still an opening for malicious code to ruin your day (even using your own privileges!).

"It's all or nothing, because 1 exploit can be used to get a step higher on the ladder to be able to do something more so another exploit is usable etc."

You miss my point, Frans. I agree 100% that all an attacker needs is to find one hole. But that's not the same thing as saying that if you're vulnerable to one avenue of attack, you're vulnerable to *all* avenues of attack. There are exploits in the wild to which you *will* be vulnerable if you run as admin on a day-to-day basis, but would *not* be if you were running as a non-admin. *That's* what I'm getting at here.

There is no such thing as a machine that's 100% secure, so long as it's powered up and connected to a network. But for you to say that it's better to "pay attention and prevent malicious code from entering whatever process on my systems" doesn't strike me as being any more secure than what I'm doing. And when did I say that I'm not "paying attention" to the software I'm running? Just because I don't run as admin doesn't mean that I'm assuming that alone makes me completely secure. But what it *does* mean is that there are certain classes of vulnerabilities that are not as easy to exploit.

Yes, if I execute code that contains a 'shatter' attack, it may be possible for that code to elevate its privileges. I've granted that already. But if I run as admin, the malicious code doesn't even have to do that much. Why should I do the attacker's work for them?

"I do know what I'm talking about, Andrew, trust me :) I'm just saying: please, don't be fooled by the feeling you're secure now, because you're not, because there is still an opening for malicious code to ruin your day (even using your own privileges!)."

A.) I didn't say you didn't know what you're talking about. I asked whether you consider yourself more expert than Keith Brown and/or Michael Howard, both of whom recommend running as a non-admin, and follow that recommendation themselves.

B.) I *never* claimed that I felt "secure" because I run as a non-admin. Again, there is no such thing as a 100% secure system. But running with elevated privileges, whether by logging in as Admin, or by running code as LocalSystem, when it's not necessary, exposes you to *more* risk by making the attacker's job that much easier.

I am a VC++ developer by profession, using Visual Studio 6.0 extensively for my work. Reading all these advices about the hazards of working after logging in as an Admin User, I removed the Local Admin privileges for my domain account. But the immediate outcome of my deed was that my domain account failed to access the VSS repositories from then onwards. The working order was restored only after restoring the Local admin privileges back.

Thank you.

Senthil,

I'm virtually certain that there has to be a better way to access your VSS repository than to run as a local admin. Do you administer the VSS database yourself, or is it a central DB run by someone else? If the latter, you should work with them to get your domain account set up properly to access VSS.

UPDATE:

As far as I can tell, the following KB article (and patch) addresses the 'shatter' privilege escalation issue raised by Frans:

http://support.microsoft.com/default.aspx?scid=kb;en-us;328310

Chris Paget, the author of the 'shatter' whitepaper claims that this patch doesn't solve the problem, but doesn't provide any specifics, saying only "WM_TIMER is fairly well blocked, I'll agree, but there's a lot more that you can do with Shatter-style attacks than just screwing with WM_TIMER." This is as of February, 2003:

http://security.tombom.co.uk/moreshatter.html

As far as I'm able to ascertain, much of the problem you're complaining about, Frans, has either been patched or does not exist in Windows XP. That's not to say that new vulnerabilities won't be discovered, or that Paget may not have found new ways to execute his 'shatter' attacks. But in a brief search, I wasn't able to find additional specific information from Paget on this issue. So at the very least, the information that you posted on these vulnerabilities is out of date, Frans.

Sooo long...the post...so long. I think that if you don't run as admin your posts should be truncated to 225 characters.

The major drawback for me is that you can't override Windows Explorer operations. Good luck changing Control Panel setting as non-admin.

Mikhail writes:

"Good luck changing Control Panel setting as non-admin."

Easy. Just open a command prompt with admin credentials using runas, then type c:\program files\internet explorer\iexplore.exe. Now you have an IE window running as Admin. Change the address to C:\, click the Folders button in the toolbar, and VOILA!, you now have an Explorer replacement running with admin credentials, and you can change ACLs, use Control Panel applets requiring elevated privileges, etc.

An alternate technique is to select Tools | Folder Options in Windows Explorer, click the View tab, and then check the Checkbox labeled "Launch folder windows in a separate process", and click Apply. Now, you *can* use runas to run Windows Explorer with different credentials.

More thoughts on my frustration with Windows security.

Frans - I think your arguments and length of your posts are both very silly - in spite of you obviously knowing some technology fairly well. (Duthie - good job with the rebuttals - but don't let Frans give you carpal tunnel.)

The point is for everyone to try harder to make multi-level Access Control work as intended - and to move away from habits and attitudes which decrease overall security - AND apply pressure to MS and Software Developers to do the same.

Frans, your attitude is a perfect example of 1 half of the problem.

AtomicPunk

Coming in really late here, sorry -

Frans: the bulk of the Shatter issue was addressed two years ago. AFAIK, there is nothing that ships in a fully patched Windows installation that allows elevation of privilege from normal User. There are no privileged services displaying vulnerable UI on the desktop.

As to the larger question of "it's my computer", here's an analogy. (Admittedly analogies are never perfect, but...) it's my kitchen and I want to be able to prepare anything I want, whenever I want. That does not mean I keep the stove and oven on 24 hours a day, or that I always carry a very sharp knife in case I need to cut something. I do these things only as needed.

Clarification on using Explorer with RunAs: the SeparateProcess flag is a per-user setting and needs to be set for the *target* account. See my blog for more info on that and a bunch of other run-as-non-admin tips/tricks/advice/etc.

Pingback from  The “run as non admin” saga continues «  An Active Coder