Linked by Thom Holwerda on Sat 31st Dec 2005 16:55 UTC
Windows Microsoft acknowledged late Wednesday the existence of a zero-day exploit for Windows Metafile images, and said it was looking into ways to better protect its customers. Even worse, by the end of the day nearly 50 variants of the exploit had already appeared. One security company said the possibilities were endless on how the flaw could be exploited. 'This vulnerability can be used to install any type of malicious code, not just Trojans and spyware, but also worms, bots or viruses that can cause irreparable damage to computers,' said Luis Corrons of Panda Software.
Permalink for comment 80727
To read all comments associated with this story, please click here.
RE[4]: Zero Day?
by makfu on Sun 1st Jan 2006 22:11 UTC in reply to "RE[3]: Zero Day?"
Member since:

On Windows systems, this is false. The explanation of why is a little long-winded, but I will attempt it anyway.

I think you are a tad confused.

First try an experiment: find a simple innocuous executable (similar to notepad or calculator) somewhere on the web, and download it to media formatted as FAT32. As a non-admin user attempt to run that executable - it will run.

Correct, just like on my FC4 Linux box. However, try running an application that attempts to invoke a privilege not granted to standard users, or access a portion of the file system or registry not granted access to standard users. You won’t get very far.

An executable will run on a Windows system without any local user giving it permissions to run. The only thing that a Windows system requires in order to attempt to run an executable (from anywhere) is that the executable has a particular extension (one of about twenty or so).

And your point it is?

On Windows systems - program installers are simple executable files. By "program" I could mean adware or spyware or keylogger type programs - any malware at all.

They are anything but simple executables. They can be MSI (Windows Installer) packages, they can be self contained exe’s. But they almost always have some common features including registering class id’s and setting global defaults in the system portion of the registry, which is not writable by non-privileged users. That said, some applications, such as Google earth, will install a profile specific (profile directory and HKCU hive) version that is localized to the current user profile only (thus allowing a non-privileged user to install the application). This application however would be accessible only to the user who installed the application (other users would not have access to the application and its settings).

As for installing malware, an executable running in the context of a non-privileged user will not be able to modify global portions of the registry, system files, install device drivers or access the debugging facility (among other user rights).

On Windows systems - it is possible to schedule an executable to be run (say at a specific time or on next boot) without any local user intervention at all.

Not as a non-privileged user. You are limited to the user rights granted to a non privileged user and the properties defined in the ACL’s on the file system and registry.

On Windows systems - there are many, many ways to get an externally-supplied executable file to run on a target system without any local user giving permission or even being aware that something has been run.

Only if running as an Admin.

Windows systems are arranged in this way in order to maintain backwards compatibility with legacy binary applications. (Windows customers tend to get upset if some expensive binary-only program they purchased in 1998 does not now run on their new XP system).

No. Windows of the NT variety are most often run as Admin because of said legacy apps and Microsoft’s unwillingness to (up until very recently) proactively educate users adequately on how to run their systems in a secure fashion (not to mention the laziness of most users). Nearly all legacy apps (and newer problem apps, such as games) can by run using the runas command invoked from a non-privileged user. This is how I run my Windows systems (and how I install apps, etc.) and I have never gotten a single piece of malware on any of my boxes. It is significantly more secure to invoke an application with raised privileges on an as-needed basis than to have the default security context of your user session be highly privileged. Running IE, Firefox, Outlook, Thuderbird, mIRC, and other apps as an admin is just not a good idea. Furthermore, if malware is invoked from a non-privileged account, your AV software at least has a fighting chance of cleaning it up since your malware won’t be able to interact with system service settings as a non-privileged user, thus preventing AV from becoming disabled (something most malware attempts immediately).

Because modern Windows systems are backwards compatible (in a binary API sense) with an insecure non-networked single user OS from circa 1995, they are FUNDAMENTALLY, BY DESIGN insecure.

Incorrect; they are not “fundamentally insecure” by design. But Microsoft’s previous stance of having all users run with admin privileges by default WAS a very bad idea. However, that stance was driven out of a wish to provide easy to support compatibility by circumventing all the security features of modern NT variants (2000, XP, 2003). In the end, all this did was promote laziness in users and developers and provide a wide open target for bad guys. Microsoft, and users who don’t take it upon themselves to properly secure their systems, will be paying for this mess for a long time to come.

With all that said, this is a big old bug, and very serious problem that users should be very careful to avoid until a patch is released. Even a non-privileged user could inadvertently infect his or her profile and running as an admin could easily lead to a very serious compromise.

Reply Parent Score: 2