Winstep

Software Technologies


 Winstep Forums


Print view
Board index : Winstep Forums : Articles  [ 1 post ]
Author Message
 Post subject: Windows Vista 32bit: Security (PART 4)
PostPosted: Tue Jan 15, 2008 11:19 pm 
Offline
Site Admin
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 11930
Security in Vista:

These last couple of weeks I have plunged deep into the 'programming on Vista' side of things. My overall vision of Vista as an OS has also become a lot more clear.

Overall, I like Vista. It's stable, it's fast - given enough memory and a half decent GPU - and it's pretty. Of course there are still driver problems and of course Vista requires more hardware to run than XP, but that is only to be expected - same thing happened in relation to Windows 2000 when XP came out and before that with Win9x, etc...

I can even understand where Microsoft is coming from in terms of the UAC (User Account Control) and the security restrictions being enforced in Windows Vista (they were already there in Windows 2000 and XP, but they were not enforced and thus not visible because everybody was running under an Admin account). Developers now either follow the strict security guidelines or their applications break - it's that simple and it's a necessary growing pain.

The problem is that enforcing those rules broke backwards application compatibility. Never before have so many day-to-day applications stopped working properly after an OS upgrade. Not a big problem if the developer is still around to make a Vista-compatible version of their software, but if not...

Anyway, most of these applications will work properly if you run them with admin privileges, but this is not very practical: you can tell Vista that a specific application requires elevation to run, but then the application is blocked from running automatically at startup, and every time you launch it you get a UAC prompt.

The former is one of my biggest gripes with Vista, because there is actually a work-around: using Vista's Task Scheduler you can schedule the application to run at Windows startup with elevated privileges, and, in such a case, there is no UAC prompt.

Microsoft reasoning for blocking applications that require elevation at startup is the following: any application, regardless of its privilege, can add itself to the list of programs being executed at Windows startup. If you got a UAC prompt for each of the startup applications that required elevation, not only would the user be flooded with prompts - one after the other - as the door would be open for a Denial of Service attack, where a malware with low privileges could add hundreds of entries requiring elevation to the startup list, thus generating hundreds of UAC prompts.

Microsoft says the Task Scheduler work-around is ok because only elevated applications can add themselves to the list of scheduled tasks, or they can be otherwise manually added by the user (which also requires bypassing a UAC prompt). Since applications can only run with admin privileges if the user says its ok to do so via the UAC prompt, malware with low privileges cannot elevate itself by taking advantage of the silent elevation mechanism provided by the Windows Task Scheduler.

I think this is highly convoluted, to say the least, because the Windows Task Scheduler is a bit complicated to operate when all you want is to make an application run elevated at Windows startup, not only from a user's perspective but especially from an application's perspective.

It would make a lot more sense to have a simple, dedicated Windows applet, whose sole purpose would be to act as an interface between the user/application and the Windows Task Scheduler; allowing applications to run elevated at startup and exposing a simple API entry for programs to add themselves to this list. The end result would be the same, but without all the complication: this applet would still require elevation to run manually and only elevated applications could communicate with it. All the brute force work of communicating with the Windows Task scheduler would be done by this applet. For the user, adding an application to the startup list would then become a simple drag & drop affair, and, for applications, a single API call (a call that would silently fail if the application was not itself elevated).

Hmm... now there's an idea for something I could write. :wink:

Another MAJOR problem is that applications can request elevation, but, once elevated, they cannot LOWER their privilege level! Worse, anything they spawn then inherits the elevated privilege and nothing can be done to prevent this. This is an incredible oversight, and one that, once more, requires a convoluted work-around via the Windows Task Scheduler: you have to schedule yourself to run with normal privileges as soon as possible and then exit the elevated version. Or use the Task Scheduler again to launch a non-elevated version of whatever you are trying to launch. The mind boggles!

And then there is the killer factor for elevated applications: you absolutely cannot drag & drop into them, unless the source of the drag & drop is itself an elevated application (which Explorer isn't). The Vista message filter that is part of the UIPI (User Interface Privilege Isolation) silently drops messages from untrusted (lower integrity) processes unless told otherwise. An elevated application can still call the ChangeWindowMessageFilter API to allow messages from lower privilege applications to pass through, but even if you allow WM_DROPFILES, drag & drop will still not work. This is just dumb - if a message filter mechanism has been provided for Windows messages, then a similar mechanism should be provided for drag & drop operations!

Another common complaint is why can't the user, as it happens with Firewalls, allow an application to run elevated once and then have Windows remember this choice so the user is not prompted again. Although the current state of affairs is a nuisance, I understand Microsoft's reasoning behind this: if such a thing was allowed, we would soon be back to the state of affairs in XP and Windows 2000. The developer would not bother separating admin and non-admin tasks within the program and would just instruct the user to run the application elevated for the first time and to tell Windows to remember that setting.

Why is this so bad? Because vulnerabilities in elevated applications can be exploited as a vector for malware attacks.

For instance, if Outlook is always running elevated and a non elevated malware manages to fool it into doing specific actions, those actions will have system wide implications. On the other hand, if Outlook is not running elevated, then it won't be able to do more than the malware application itself can.

Hope this clears things up a bit.

(END OF PART 4)

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
Post new topic Reply to topic Board index : Winstep Forums : Articles  [ 1 post ]
Display posts from previous:  Sort by  

Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron