Rootkitware... how are regular people supposed to cope?

[Dominus Atheos]

That's not true. Processes can be run with fine-grained ACLs under Windows.

Is this app-dependent or OS dependent? I was under the impression that what DA said was the case, ie that a given process is either admin or not, similar to rights elevation under Linux. I'm curious to know what kind of spoofing is effective with regard to Vista's UAC (since I believe that fake Vista window virus install tihng from a few months back got right past it by authorising something seemingly mundane?).

You can assign processes limited, user or administrative rights in XP. User-level rights can also be monkeyed with via Group Policy, so you could have a process under a certain user restricted.

So you can create a new group and run a process under that group and by doing so, control what actions it can and can't perform like allowing it to write to program files but not the windows folder? That's pretty neat and it sure would be nice if Microsoft could configure UAC to check what action the program is trying to perform and just punch a hole in the ACL for that one program for that one action. But it's not like that right now, so in any default configured Vista box, UAC functions the way I described?

[Stark]

That's really what I was asking; if you can elevate a process/app for a single action group (like writing to a folder) but not for other actions (like writing to the MBR). I don't think it's like this now, I believe it's the way DA describes (and the way I believe elevation works in Linux too).

[phongn]

That's really what I was asking; if you can elevate a process/app for a single action group (like writing to a folder) but not for other actions (like writing to the MBR). I don't think it's like this now, I believe it's the way DA describes (and the way I believe elevation works in Linux too).

Elevation is an all-or-nothing affair, but there's more fine-grained process controls available.

[Dominus Atheos]

That's not true. Processes can be run with fine-grained ACLs under Windows.

Is this app-dependent or OS dependent? I was under the impression that what DA said was the case, ie that a given process is either admin or not, similar to rights elevation under Linux. I'm curious to know what kind of spoofing is effective with regard to Vista's UAC (since I believe that fake Vista window virus install tihng from a few months back got right past it by authorising something seemingly mundane?).

It should be impossible to spoof UAC. Back in XP, when the system asked you "are you sure you want to do this?", programs would put a dialog box in front of the windows box that said something completely different and when you clicked on the okay button on the spoof box, you were actually pressing the "allow this program to do what ever it wants" button on the windows dialog box. (You probably know this already but I'm just explaining it for all the people who don't who might be following this discussion)

In Vista, UAC prompts darken the whole screen and leave nothing on there except the UAC box, so it's impossible to put something in front of it. For some bizarre reason I haven't figured out, Windows 7 will remove this feature so it's UAC boxes may be vulnerable to spoofing.

[Dominus Atheos]

That's really what I was asking; if you can elevate a process/app for a single action group (like writing to a folder) but not for other actions (like writing to the MBR). I don't think it's like this now, I believe it's the way DA describes (and the way I believe elevation works in Linux too).

Elevation is an all-or-nothing affair, but there's more fine-grained process controls available.

So if I'm understanding you right, you can launch a program with specific actions it can and can't do (like writing to a folder but not to the MBR) but if it needs elevation for any reason, the only thing you can do is give it full system-wide access?

[Stark]

I imagine the thinking was that UAC would be too complex For most people if it had grades of request and too annoying if it was per-action - people already think it's so annoying theyll turn it off after all.

[Beowulf]

In Vista, UAC prompts darken the whole screen and leave nothing on there except the UAC box, so it's impossible to put something in front of it. For some bizarre reason I haven't figured out, Windows 7 will remove this feature so it's UAC boxes may be vulnerable to spoofing.

It's possible to modify the UAC prompt to not darken the screen in Vista. W7 removes it because most people got annoyed that it took several seconds to switch to the darkened desktop and back.

Elevation is an all-or-nothing affair, but there's more fine-grained process controls available.

So if I'm understanding you right, you can launch a program with specific actions it can and can't do (like writing to a folder but not to the MBR) but if it needs elevation for any reason, the only thing you can do is give it full system-wide access?

The finer grained process controls are so much of a pain to use that it's mostly only useful for programmer to do so. So there's the elevated/not-elevated dichotomy, which is much more user friendly.

[Stark]

There are a lot of security approaches that are basically uselss to 80% of the population given the setup required. UAC was a big step for windows because it defaults to on and is easy enough for anyone to understand. I'm just curious to know how it works with malware like this, since there was that virus spoof window thing n the past which prepped the user to click past the UAC popup.

[Dominus Atheos]

There are a lot of security approaches that are basically uselss to 80% of the population given the setup required. UAC was a big step for windows because it defaults to on and is easy enough for anyone to understand. I'm just curious to know how it works with malware like this, since there was that virus spoof window thing n the past which prepped the user to click past the UAC popup.

That's not a spoof, that's a trojan. Any operating system can have a bad program that puts up a dialog box right before the escalation box that preps the user to just click continue or enter their password. There was even an example on Mac OSX a few weeks back. All in all, UAC should function exactly the same as Linux and OSX.

[Dominus Atheos]

In Vista, UAC prompts darken the whole screen and leave nothing on there except the UAC box, so it's impossible to put something in front of it. For some bizarre reason I haven't figured out, Windows 7 will remove this feature so it's UAC boxes may be vulnerable to spoofing.

It's possible to modify the UAC prompt to not darken the screen in Vista. W7 removes it because most people got annoyed that it took several seconds to switch to the darkened desktop and back.

Then they should fix it so it doesn't take so long. I have a 9800 gtx and it still takes several seconds to pop-up. Removing the feature is (unless they add something else) just going to make 7 vulnerable to spoofing.

[Dominus Atheos]

All in all, UAC should function exactly the same as Linux and OSX.

How does it work? (I'm a Linux user, but don't use the Linux GUI's very often at all, and have never used them for anything admin related.)

Are you asking me how privilege escalation works? Have you been reading the thread? I explained it already:

All programs under XP runs with full administrator access to the entire computer including system files and can make any change it wants to without the user even being aware. Under Vista, Linux, and Mac all programs run as a normal user, which means they can't make any changes that affect the entire system, only changes that affect that one user. If a program tries to make a change that affects the entire system, UAC and the Linux and Mac versions will stop it and ask the user if it wants to give that program permission to do that.

[Stark]

There are a lot of security approaches that are basically uselss to 80% of the population given the setup required. UAC was a big step for windows because it defaults to on and is easy enough for anyone to understand. I'm just curious to know how it works with malware like this, since there was that virus spoof window thing n the past which prepped the user to click past the UAC popup.

That's not a spoof, that's a trojan. Any operating system can have a bad program that puts up a dialog box right before the escalation box that preps the user to just click continue or enter their password. There was even an example on Mac OSX a few weeks back. All in all, UAC should function exactly the same as Linux and OSX.

Yeah, this was what I expected. It can't check the 'honesty' of applications after all - but in the OP, with the PDF sploit, wouldn't this work through UAC if the user was prepped in this way? Obviously the user is the weak pointt in security but I've seen people ascribe protection to UAC that my understanding of it doesn't seem to cover, suggesting it'll jump in to save a stupid user when I don't think it'd be able to, so I thought my understanding might be flawed.

Sorry about my posts ATM I'm on my phone and it's a shit to edit.

[Dominus Atheos]

Are you asking me how privilege escalation works? Have you been reading the thread? I explained it already:

No, I'm asking about the user interface part of it. I know full well how the technical part works, but that isn't really relevant to the real problem being discussed: how to present it to the user. Vista is the best I've seen so far for regular people. (Personally, I prefer:

Code: Select all

$ program do something
program: Permission denied
$

but that isn't quite as pretty, nor necessarily the best way it should be implemented, but it works for me.)

Vista does have the downsides of how it works though, like conditioning the user to click "accept" without really thinking it through. (Similarly, I'd probably respond with the Permission denied message by hitting up, home, sudo, space enter - that is, rerunning it with full power, optionally adding the -f flag to force it to shut the fuck up and just obey my command already; we technical users certainly aren't immune to this conditioning either.)

How do the GUIs on Mac or Linux address the user interface problems, and why is it better?

They don't, and they aren't. They still provide no information about what the program is trying to do, the only difference (and I mean the only one) is that the Linux and Mac ones require your full account password instead of clicking a button. Some people say this is more secure, but if Windows tried to implement it even more people would turn it off then do UAC with it's continue button. It's a struggle to find a balance between security and convenience.

But seriously, there's no difference between Linux/Mac and UAC besides button vs password.

[Turin]

The thread's moved on a bit since, but...

I don't know if you use Windows at work or ever at school, but any half-way competently set up business system will have all users run as users and only the system administrators have administrator access (thus the names).

Maybe not with typical office drone software (Office or whatever), but a good deal of higher-end software has to be run as admin in XP. Which means giving power user access to nearly every Tom Dick and Dumbass in your organization if you're, for example, an architectural or engineering firm.

What programs are you running that require admin access? Here is a list of everything that requires admin access (at least in vista):

Not in Vista, in XP, which is what you were talking about at the time.

[Dominus Atheos]

The thread's moved on a bit since, but...

Maybe not with typical office drone software (Office or whatever), but a good deal of higher-end software has to be run as admin in XP. Which means giving power user access to nearly every Tom Dick and Dumbass in your organization if you're, for example, an architectural or engineering firm.

What programs are you running that require admin access? Here is a list of everything that requires admin access (at least in vista):

Not in Vista, in XP, which is what you were talking about at the time.

There shouldn't be any differences. The only change to the security I'm aware of is that XP requires admin access to change the timezone while Vista does not.

[Dominus Atheos]

Obviously the user is the weak pointt in security but I've seen people ascribe protection to UAC that my understanding of it doesn't seem to cover, suggesting it'll jump in to save a stupid user when I don't think it'd be able to, so I thought my understanding might be flawed.

Are you referring to this post? Because what I was talking about were drive-by downloads. UAC will jump in and save a stupid user who visits the wrong internet site were as in XP you'll just be fucked and never even know it until you close the browser and notice the new icons on your desktop for anti-virus software (that's actually a virus itself) and porn dialers.

If you were referring to someone else, then disregard all of the above.

[Stark]

Nah, it seemed that people were suggesting UAC would popup to authorise an untrustworthy install and then popup AGAIN when it started to do fishy things, which wasn't my understanding at all. With the PDF in the OP, anyone who 'authorised' Acrobat Reader when opening this kind of PDF would be just as vulnerable under XP, no? This is why I was asking about granularity because it seemed I was missing something in my understanding of how the UAC/elevation thing worked (andit appears now that I was right the whole time).

I'm clearly not making a lot of sense today. Still, informative thread nonetheless.

[Beowulf]

Nah, it seemed that people were suggesting UAC would popup to authorise an untrustworthy install and then popup AGAIN when it started to do fishy things, which wasn't my understanding at all. With the PDF in the OP, anyone who 'authorised' Acrobat Reader when opening this kind of PDF would be just as vulnerable under XP, no? This is why I was asking about granularity because it seemed I was missing something in my understanding of how the UAC/elevation thing worked (andit appears now that I was right the whole time).

I'm clearly not making a lot of sense today. Still, informative thread nonetheless.

Actually, unless the program is coded to prompt for elevation, actions that require it will just fail, when the program itself isn't run elevated. Vista uses some heuristics to detect installers, so that they'll cause an elevation prompt when run, because most people actually want that behaviour. One of the rules used involves the name, which is how two identical executables can have different elevation requires, simply because one is named "xxxx setup" and one is named "xxxx".

[Turin]

What programs are you running that require admin access? Here is a list of everything that requires admin access (at least in vista):

Not in Vista, in XP, which is what you were talking about at the time.

There shouldn't be any differences. The only change to the security I'm aware of is that XP requires admin access to change the timezone while Vista does not.

My primary experience from an administrative end is with AutoCAD (and other Autodesk products). They perform registry edits which require admin access. When Vista first came out, no Autodesk product would work on Vista (unless you were running as admin) until the next versions, where they had to change this behavior.

[Ryan Thunder]

For some bizarre reason I haven't figured out, Windows 7 will remove this feature so it's UAC boxes may be vulnerable to spoofing.

Marketing probably beat it out of them because a few vocal dumbshits complained about it.

[Durandal]

If so, that's a giant step forward but there's a good chance people would click on it anyway. I guess the Vista malware might detect it and block it silently, but as I said I don't have any commercial experience with Vista. Once you've UAC-authorised an application for xyz (an install, say) does that give the installer rights to do anything it wants? I'm interested to know what granularity it has.

No, unfortunately the security model doesn't have very much granularity. A program is either running with user permissions or admin permissions, and the same is true of Linux and Mac. Basically when Microsoft was working on Windows NT they copied over the security model from Unix that Linux and Mac are based on and Vista inherited that and was the first to apply it by default to every account. It could stand to be a lot more secure, but since it's "as good" as the competition I doubt Microsoft is ever going to do that.

No, that is not true. One of the most common misconceptions about Mac OS X's authentication dialog is that it's the mechanism by which a process' privilege is elevated -- or put another way, that it's a "GUI sudo". It's not. That dialog tells developers one thing: whether the user at the console is who he claims to be. This is done by having the user enter his password, insert a SMART card, etc. When the application that put up the dialog gets the result of the authentication back, its privileges are exactly the same as when it started. Nothing about the application's environment changes as a result of a successful authentication. The only difference is that now, it possesses a blob of bytes that can be inspected and verified as saying "User A proved that he is at the console and possesses Right B."

The pattern for using that dialog is that, once the application has obtained an authorization reference, it can ask a daemon running with the needed privileges to perform an action on its behalf. It will give the daemon the authorization reference it has obtained, and the daemon will check it to see what right(s) the user is authorized for. It can then perform the corresponding actions on behalf of the user application. You can even click a little disclosure triangle in the authentication dialog to see what right the application is asking for. Developers can also use the this mechanism to restrict non-OS-related functionality within their own applications, independent of the user's access privileges.

The one exception to this is AuthorizationExecuteWithPrivileges(), an API that lets a user task execute a given program with root privileges. The user must obtain the "system.privilege.admin" right in order to call it. But it's a very messy API call that's only around to support certain legacy third-parties. Anyone new to the platform is encouraged to treat it as deprecated.

The fundamental difference between Vista's UAC and Mac OS X's authorization dialog is that UAC is an interactive sandbox. The address space asking for approval to perform a certain task actually goes on to perform that task. (Unless Microsoft has privileged daemons behind all those API calls that require UAC, but I don't think that's what they did. Or at least, not across the board.) On Mac OS X, it's entirely up to the programmer to do what he needs done in a privileged address space.

Leopard also introduced Seatbelt, which is basically Apple's implementation of FreeBSD's MAC framework. Seatbelt lets you define what resources your application needs access to ahead of time, so it offers much finer-grained control over privilege. You can define what files a program can open, what Mach services it can look up, what system calls it's allowed to make, etc. It's kinda-sorta available to developers, though it's treated as SPI for now.