Users Still Not Willing to Abandon Windows XP

Maybe you've already seen the following, where MS' Mark Russinovich's explanation supports your notion:

http://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx

I think originally, though, as you've indicated, they did promote it as a security feature.

 

I must've missed something important. If UAC is set to max and you have to type the admin's password, why is it not an excellent security feature? My gpedit settings also forces me to do the ctrl-alt-del sequence whenever I need to use somebody else's credentials.

 

Because UAC does not guarantee processes of higher integrity levels are protected from lower integrity level processes.

 

NGRhodes, can you provide a source for that? I'd like to know more - I know UAC can be bypassed, but I didn't think the design was so badly flawed.

 

http://msdn.microsoft.com/en-gb/library/bb625963.aspx

Cheers, Nick

 

Ah I see.

I don't see how this is readily exploitable?

 

In addition to Nick's link, there is also this that may be of relevance...

http://blogs.technet.com/b/markrussinovich/archive/2007/02/12/638372.aspx

...but I'm not sure it relates to UAC. It might actaully have more to do with kernel exploits that can elevate to Administrative level?

 

But this concerns Administrative Users, not regular LUA users.
I think it's fair to say UAC has to be combined with LUA to reach optimal security.

 

I didn't read the article word for word but doesn't it describe the potential /theoretical problems with running Low IL sandboxed apps (via PsExec) in an admin environment?

 

No. The key "word" (it's more than one word) here is: Admin Approval Mode.

Admin Approval Mode is when you elevate an application and get an UAC prompt to elevate the application. This application will be running with HIGH integrity level, but it will be running under the same desktop as the other processes running with the user's privileges (MEDIUM integrity level).

For example, you run as a standard user (medium integrity level) and so do your processes, but if you elevate an application such as Process Explorer (just an example), it will be running with administrator privileges (high integrity level), but both the medium integrity and high integrity level processes will be sharing the same desktop.

 

You're right. I read it wrong. But what am I missing? What are the real life threats that are associated with medium integrity processes that share the desktop with a temporarily elevated high integrity process? And even if I did not elevate any application, a big part of my system and services are running with high IL and if that alone were a security issue, what would be the additional danger in elevating, say, Process Explorer as a regular non-admin user?

 

There also seems to be a definitive group of folks that hate the new OS and hold back or have legitimate application concerns, and refuse to update because the alternative is unacceptable. I seem to fall into the second group, in that some of the games I love to play are Windows XP only. I still cant get them to properly function with compatibility mode and the developers have killed my interest in the continuation of the series. This has put me in a tight spot, so I can understand why people are holding on to XP. I can even understand those holding on to Vista and Seven now that Windows 8 has been released. Some people just aren't going to compromise on what they want. Even if that means retaining a version of windows pre-UAC or pre-whatever irritates them.

 

Looks like that's how it's going to be from now on too...

 

As promised:

Let me enlighten you: This is an important article discussing the upcoming end of life of Windows XP support, arguing against the false security drama about Windows XP malware infection rates, with extensive analysis of data, statistics and contradicting reports by Microsoft versus third-party security companies, the law of large numbers, incomplete and partial truths, alternative focus on functionality, user needs, hardware refresh, potential benefits and downsides of newer versions of Windows, other business ans usage considerations, and more. If you save money after reading this piece, consider donating to charity.

http://www.dedoimedo.com/computers/windows-xp-death.html


Cheers,
Mrk

 

Nice article, Mrk

You're one of the very few in these forums who take a cool, calm, logical and rational approach to computer security. It's refreshing

 

Yeah, good one Mrkvonic. Sensible...

 

Great article. Thanks!

 

Malware infection rates do not make up for an insecure kernel.

Despite what people will tell you, a flaw in the kernel allows an attacker to execute unauthorized code. Sandboxes, antiviruses, and built-in protection measures do not compensate for this fact.

XP is inherently not secure anymore. Any geek will not be able to hold off specialized infections targeted towards the kernel. Common measures to fend off malicious code and files simply do not exist on that platform, whereas Vista and 7 provide a good compromise between user security and functionality. The latter more so.

Windows 7 and other OSes are so much less of a headache to work with in terms of precautions. Unless, that is, you enjoy spending more time tweaking security than actually using your computer productively.

 

Running unauthorized code is all nice and well.
But whence that unauthorized code cometh from?
Mrk

 

All updated, I just don't see XP as so inherently insecure compared to the newer Windows version... Yeah, I know about the ASLR, Integrity Level, etc. difference, but most of that (not ASLR) is for user mode stuff. All updated, doesn't matter. EMET helps. Sandboxie contains if something does run or try to infect.

WHERE are the Sandboxie bypasses? It should be great! Of course it can't protect against a kernel exploit, but neither can anything else. Although, by chance, it MAY block/interfere with some communication channel a kernel exploit needs to succeed.

If XP was so bad, there should be massive, targeted attacks and infections with it. Yet, there isn't really. (I absolutely believe there will be after updates end. Hammer it, since there's no hope for plugging holes.)


The kernel exploits, I've said before, they ALSO apply every time to the later versions of Windows as well. Even with ASLR/whatever, you still have the same exploits, so what have you gained?


So tell us, how exactly (or in general) are some ways that XP is insecure and is going to get us exploited/infected while browsing around anywhere or running whatever we want in Sandboxie?

(BTW, my IE/plugin Flash is almost a year old! Ooops. I was sort of waiting on purpose 6 months ago, but... Anyway, would never have done this without Sandboxie. I've never seen anything happen so far, but I shall upgrade it soon. Java is kinda old too. And NO .NET Framework updates, although I'm not sure that's available from browsers FF/IE 6.)

 

This is nonsense... Any geek, can, and will be able to secure XP in any number of ways and make it reasonably bullet-proof for all practical purposes.

 

And anything targeted towards the kernel can't be held off by "geeks" on newer versions of Windows either!


What are those "common measures" to fend off malicious code and "files" that I'm missing? I have some idea of what might be said, but am I forgetting something magical?

 

The entry point for exploits - the browser - is probably the key to stopping them. Firefox with NS carefully managed along with its "Block reported..." checkboxes under the Security tab (which I feel don't get the credit they deserve), plus Adblock+ will likely stop the majority of them. Sure something could be allowed inadvertently, but if a user only allows the required content and blocks everything else, the danger is mitigated substantially. Even HM has high words of praise for NoScript. So even on an unsupported and weaker-by-default platform like XP, these simple measures could, and probably do, provide tremendous defense against exploits.

 

The words I've bolded are key IMO. "For all practical purposes" applies now; it may not apply in a few years. Attacks that use a direct remote exploit -> privilege escalation -> payload route, instead of remote exploit -> payload -> privilege escalation, are theoretically possible (and have been demonstrated repeatedly on Chrome and other browsers). Such attacks are also easier on XP.

The question in my mind is (still) whether automation of such attacks will ever become commonplace.

In any case, yes, HIPS/AppLocker/SRP/etc. block almost all ITW malware right now. But one has to recognize that this isn't "bear proof," so much as "You don't have to outrun the bear if you can outrun your friend." Sadly that is what almost all desktop security products boil down to at the moment.

Noscript is fantastic, but doesn't cover all bases. You still have HTML renderer vulnerabilities, bugs in image libraries, bugs in font handling, probably bugs in the XUL toolkit... And of course hostile JS embedded directly on a whitelisted domain, instead of on some other domain. (Rare but definitely possible.)

It's very effective, but in the end it's still not outrunning the bear.

 

Well, I say "for all practical purposes" because as wat0114 said above, most of this can be filtered out at the browser level with a few tools/extensions etc, and Firefox for example, as well as Chrome, are always kept pretty much up to date. What's left, payloads and whatnot, can be covered by an antiexecutable, and then there is EMET, and if you're really paranoid, use a antilogger like Zemana or whatever.

Some of this type of discussion gets way out there in the land of what I'd call "theoretical" and isn't likely to occur much or be encountered much by the average home user, hence the "for all practical purposes" phrase. Sure, anything's possible, but is it likely?

How is it that I have been online since 95 and done just about everything there is to do, and yet I've never once been bitten by malware or had a problem, and my security measures are much more lax than many users' here. I'm either super unbelievably lucky, or maybe I just have good "street smarts", or even perhaps the so called "threat" really isn't all that great, "for all practical purposes".