If the "1002.exe" sample on Reddit is accurate the installer is unsigned, so forbidding unsigned binaries should be sufficient. The number of legitimate unsigned Windows binaries is small enough that you should be able to whitelist them by hand.

http://technet.microsoft.com/en-us/library/ee424382.aspx

That being said a very restrictive Software Restriction Policy as linked below would mitigate CryptoLocker as it exists today. It has worked well for me so far.

http://www.mechbgon.com/srp/

Edit: It's the BTC aspect that's worrisome. Ransomeware is nothing new -- AIDS Information Trojan did it in 1989, but the (potentially) safe method of payments in crypto currency seem to be a new factor that will attract much more innovation in these type of attacks.

Anyway, what really makes me nervous is Microsoft's insistence of executing any data that a their programs touch.

https://blockchain.info/wallet/send-shared

(Please note, before downvoting, that I'm not saying that's a bad thing)

[0] - https://www.securelist.com/en/descriptions/old313444

> The first known ransomware was the 1989 "PC Cyborg" trojan written by Joseph Popp

GitHub for Windows and dozens of apps it installs in there F.lux Anything installed with ClickOnce Chrome GMVault Xamarin's Android Support Markdownpad SkyDrive Join.me

Assuming that everything in there is a virus is too much, I think.

Yes, and from a security point of view it should be treated as hostile accordingly.

There is no need to actively circumvent Windows security like this. Firefox, among many other examples, is quite capable of automatically updating itself using a proper Windows service mechanism.

It's long past time that Google were called out on this one. Not only is it a potential security risk, it also interferes with backups of %AppData%, which is generally an area of Windows PCs that you do want to save regularly in case of disasters.

ClickOnce-installed applications are limited to "Internet Zone" permissions. This can make them immensely frustrating to develop with, actually, since many of MS's own development frameworks fail miserably in Internet Zone even when they have no reason to do so (mostly they generate temporary files in places they aren't allowed).

I'm not sure how Google Chrome gets permissions to save files into your documents and whatnot from there - I don't recall Chrome requesting a permissions escalation during install or anything.

[1] http://msdn.microsoft.com/en-us/library/142dbbz4%28v=vs.90%2...

They have had it for ages, presumably to answer your mentioned complaints.

EDIT: If I want to run/update something (Chrome) in Userland, why should an OS security model stop me? My guess is, Microsoft have successfully confused a common business requirement with a security one.

Of course, Windows has now partially solved that with UAC. Unfortunately you can never know if you can trust the software or not though. However this does stop malware from secretly running without your permission, since it would require a UAC prompt to run. Then we get into uneducated users.

In windows there are too many ways to get elevated. And only one level of elevation.

After all, there are tons of popular projects requesting users to run "curl http://... | sudo sh" and consider that a good idea, too.

I keep trying to teach my nephews that the default answer to that question is no... but of course, "yes" is the way you get anything done.

Do you know one of the most asked questions in Mac OS X user forums from new users is how to disable root?

I fail to see the difference. Sorry.

You don't even need to do that. You should need administrator access to install software initially, but that installation process can set up a system service that handles any subsequent updates automatically. This then runs independent of any current user on the system, and therefore does not depend on their personal privileges, nor does it need to prompt anyone for permissions for every update.

Clearly there is a risk involved with any process that can automatically download code you will subsequently execute. However, with proper access control, at least a compromised application running in user space can't do things like modifying its own executable so the malware has a place to live or, more generally, anything else that the user couldn't do without elevating their privilege level.

This certainly doesn't get us to an ideal security model. As I noted elsewhere in this discussion, a user on most systems today can probably still do things like e-mailing all the sensitive work documents they can access to a hostile party with just their normal privileges. However, it does at least prevent one common kind of attack.

Every time my interent connection slows (WiFi) I know it's Chrome Updater so I kill it via Task Manager and everthing is good again.

There doesn't apear to be away to turn it off inside Chrome itself and turning off updates via the registry does not seem to stop it.

Or try Firefox!

You could say it's in its DNA

/ducks

The real problem, I think, is that Microsoft thinks requiring admin rights to write to "Program Files" is the be-all and end-all of solving the "application-environment integrity problem." That works for enterprise-wide deploys of sysadmin-supported software, but falls down for user-specific installations. On OSX, "application-environment integrity" can be enforced easily enough, since the OS delineates applications by a line called "the app bundle." OSX can (though I'm not sure it does) just disallow apps from writing into other apps' bundles without a "do you really mean it" prompt. But in Windows, the The Directory Is The Application Bundle[1], and so Windows doesn't know that this directory is special and should be protected from having other apps in other directories tinkering with it.

[1] http://blogs.msdn.com/b/oldnewthing/archive/2011/06/20/10176...

    dir /S /P "%userprofile%\AppData\*.exe" > %userprofile%\Desktop\FoundFiles.txt

    dir -Path "$env:userprofile\AppData" -Filter *.exe -Recurse > "$env:userprofile\Desktop\FoundFiles.txt"