About | Buy Stuff | News | Products | Rants | Search | Security
Home » Resources » Rants

The Myth of LUA

Week of 20 June 2006


Besieged - humiliated - as they have been for the past seven years by malware attacks, Microsoft have attempted to shore up the defences in their 'standalone' operating system Windows. Perhaps the most significant step they have taken is the implementation of LUA - the least privileged user account. This article will show why Microsoft's efforts are in vain and why Windows is hopeless.

The Background

Viruses have always proliferated for Microsoft platforms. This is related to the onslaught of malware in recent years as will be shown later. Worms and trojans are a more recent form of attack, dating to the Melissa worm for MS Word and above all the 'love bug' of 5 May 2000.

The Damage

News sources such as eWEEK estimate the total damage of the worm outbreaks to 'double what Bill Gates is worth on a good day at NASDAQ'. In other words, if Bill Gates gave everyone a full refund because his products underperformed and also compensated everyone for the damages these products had caused, he'd still come up short. He's probably have to borrow from all the other Microsoft executives who've become billionaires off the Windows profits.

The situation is so critical that Bill Gates himself made a surprising apology to the planet in early 2002, promising things would get better. Windows users are still waiting.

The latest 'hype' is that Microsoft's implementation of 'LUA' - 'least privileged user account' will save the day.

Windows Security

The Windows Microsoft market today is not the same Windows Microsoft released in December 1985. That Windows was a semi-graphic shell on top of MS-DOS; this Windows is very much a copy and enhancement of Digital Equipment's VMS operating system written by David Cutler in the 1970s.

[That's not just conjecture either: Digital Equipment sued Microsoft for stealing the code to a coming operating system based on VMS; chief engineer David Cutler made no effort to hide the theft; Microsoft settled out of court for a nine figure sum. Ed.]

VMS is generally considered one of the most bulletproof operating systems ever, but it's important to note that it is not a personal computer operating system: it's a 'server' operating system. Users have no physical access to the 'computer' itself but work from 'dumb terminals'. Their files are stored on this centralised inaccessible computer and are protected by various mechanisms. The operating system on the computer metes out access privileges as needs be.

The VMS server is of course most secure when it is not connected to a network with other servers. This was evidenced strongly in the 'wanker' attack on NASA.

Windows users may be required to log in to begin using their systems; if not, the system uses an automatic login. In either case the user acquires an 'access token'. This is security information that follows the user around during the login session.

Whenever the user attempts to do something on or with the system, the system may check the user's access token first to ensure sufficient rights have been granted.

Windows also allows for 'privilege escalation' which is a kind of 'LUA' in reverse. Users may be capable of more rights but have to ask for them - and then are only granted these rights for as long as they need them.

Windows comes with its own file system NTFS which is able to store 'access control entries' for both permitting and denying access to users and groups. Resources do not have to have access control lists; if they do not, the resources are freely available to all. Once an access control list is created, it must contain explicit permissions for anyone to be able to access the resource.

[Thus a non-existent ACL is completely different from an empty one. Ed.]

Normally administrator privileges or higher are required to configure ACLs. Totally inaccessible resources can normally be 'unlocked' by administrators - with programs such as this.

The Path of Least Resistance

Surveys show that despite Windows sporting a purportedly 'secure' file system of its own (NTFS) most installations still use the 'standalone' file system FAT32. FAT32 totally lacks security. It is simply a 32-bit upgrade of the original FAT16 and FAT12 file systems used on the original IBM PC with attributes any user can modify.

Although some files and directories can appear to be inaccessible and or hidden, a simple command line procedure (or GUI-based utility) can remove all obstacles.

Neither FAT32 nor NTFS have security file attributes; the only security either of these file systems have is in the access control lists implemented on NTFS. The basic attributes for both file systems are otherwise equivalent, relegating the administration of a computer to issues such as 'read only', 'archive', 'system', 'directory', 'volume', and 'hidden'.

'Archive' is used to keep track of what files have to be backed up: the flag is set every time a file is updated. 'System' is an attribute without 'bite': it does nothing on its own. 'Directory' and 'volume' are not security attributes but indications of file type used by the file system drivers. 'Hidden' will make a file hidden in many (legacy) circumstances, and 'read only' will prevent modifications to a file, but both are easily removed from the command line by any user regardless of privilege level.

While Windows Explorer and Internet Explorer will often refuse to show directories marked with both the 'system' and 'hidden' flags, there is nothing stopping the user from removing those flags without privilege escalation and there is nothing stopping malware from doing it either.

Windows users are confronted with - and stymied by - a server operating system layered as it were atop a standalone system, with no easy way to make things secure.

Faced with the prospect of either spending innumerable hours on a regular basis configuring the access control lists of NTFS or using FAT32, it is no surprise most choose to do the latter. It is the 'path of least resistance'.

Ownership

It is only with NTFS - and the use of access control lists - that Windows is able to implement and benefit by resource ownership. On the original PC no one was the owner - and simultaneously everyone was. Windows users who have never come into contact with other ('server') operating systems are befuddled to this day by such concepts.

They are used to putting all their programs in a special 'program files' directory. This directory is not their own but is shared by all users of the computer. The Registry is somewhat capable of authority granularity and ownership specifications but not the physical disk layout. Security settings for each user are locked on disk and written into the 'HKEY_CURRENT_USER' Registry key on login.

It is possible to prevent access to application software in this way, but it is only a 'backhanded process'. Physical access to the software is still possible - and consequently so is the threat of attack. The Registry implements a security model similar to NTFS; if the file system in use is however FAT32, much of the security is lost.

Security Model

It is through the cooperation of a properly implemented file system and the operating system kernel that an adequate security model can be achieved. The file system must be able to tell the kernel to not access or run certain things and the kernel must prevent unauthorised users from accessing resources in the file system.

Because Windows primarily uses FAT32 as its file system, this is impossible to achieve. Because the access control list implementation of NTFS is a path of great resistance for almost all users, it is not a practical solution. VMS was secure to the extent the ACLs were properly configured on the server and to the extent users could not physically access the server. Today everyone accesses their 'server'.

Sandboxing

One way out of this dilemma is to 'sandbox' sensitive applications. The most sensitive applications are of course those that interface with the Internet. The Internet can usher in all sorts of rogue processes that can do the user harm.

Once a rogue process gains access to a Windows system it's generally 'lights out'. There are no internal defenses against damage. The FAT32 file system cannot protect itself - or the user - and NTFS installations, to the extent they are used, will invariably be incomplete.

Worse, because of the deliberate opacity of the access control list system, it is impossible for a system administrator - much less an ordinary user - to obtain an overview of the general security status quo and with any success at all single out potential weaknesses.

Sandboxing applications can hopefully address some of these issues, but their success is dependent on use of access control lists and specification of resource ownership. All other methods are to be regarded as 'hot wiring' - precisely the type that is so easily circumvented by the sophisticated malware plaguing Windows computers today.

Without an adequate security model Windows can only continue to plug holes in an ad hoc fashion - and the planet will simply sit still and wait for the next major catastrophe.

A common misconception has been that it is applications such as Internet Explorer and Outlook that have been responsible for the extensive damage caused over the years. While it is true that these applications have been found to contain sloppy code to an extent previously thought impossible, the applications themselves are not responsible for the damage caused.

Any self-respecting operating system will always protect itself from 'wild code'. This pertains to both the running operating system kernel and the file system. But Windows cannot contain such damage: there is no effective security model.

So although it is true that innumerable inexcusable flaws have been found in Microsoft's flagship Internet software products, these products are not themselves responsible: the operating system is expected to prevent damage caused by erratic behaviour.

And Windows - NT, 2000, XP, Vista - generally cannot.

The Windows Food Chain

Windows user accounts fall into the following categories.

  • SYSTEM. This is the equivalent of the Unix 'superuser' or 'root' account. It is rarely used for reasons given below.
  • Administrators. Note this is not a user but a group of users. Windows systems are normally set up first with an administrator account. An administrator does not have access to all the resources in the system but may - without privilege escalation - 'assume' ownership of all resources, including those owned by 'SYSTEM', after which they become accessible.
  • Power users. Power users do not have the full range of administrator rights but may still access and modify system resources. (Of course this is not good: no Unix system lets anyone save the superuser do that.)
  • Ordinary users. These users are prevented from making changes to the system.
  • Guests. A very limited range of rights.

Because of the way Windows is set up, a user may belong to any or all of the above groups (save SYSTEM). When checking rights and privileges, the security account manager will always pick the highest rights available. Thus if a user belongs to both the administrators group and the guest group, full administrator rights will be granted.

This can only be overridden by use of access control lists, and this can only apply fully if the file system in use is NTFS.

Even with 'user' status and no more, a user can do all the following.

  1. Inspect running drivers and services.
  2. Modify HKEY_CURRENT_USER and read HKEY_LOCAL_MACHINE.
  3. Run programs.
  4. Read system files.
  5. Inspect running processes.
  6. Inspect firewall settings.
  7. Inspect the system logs.

#1, #2, #5, #6, and #7 can be controlled regardless of the file system in use; notably #3 and #4 cannot. Obviously this is not good - and with an adequate security model with ownership specifications in place it would be prevented. But the lack of an adequate security model means malware will - even in the best of all possible worlds - creep and seep through the cracks.

Why Only LUA?

With all the embarrassing worm outbreaks and spyware fiascoes clobbering Windows, can't Microsoft do more than implement LUA?

Yes, Microsoft could - in theory - do a lot more, but in practice they won't, because too many legacy issues haunt their software.

  • There's an assumption of 'standalone' operations. Not only Windows but hundreds of thousands of important applications depend on the assumption of free access to everything in the system.
  • A migration to an 'ownership' model with protected 'user areas': all Windows software, both Microsoft's and everyone else's, would have to be rewritten from scratch to accommodate a new file system layout no one's ever used before - with the concomitant snags that are surely to result. Considering the huge amount of software available for the platform today, this is not feasible.

Microsoft can only 'advise' use of LUA - it can't be enforced. And even if it were possible to enforce it, it would be much too little far too late.

Early 'server' operating systems were initially not concerned with malware attacks - they only worried about 'erratic' or unauthorised behaviour in a multiuser environment. Fortuitously this translates easily to the connected world we have today.

Microsoft Windows was never a 'server' operating system, and the 'layer' of 'VMS' put atop today is subject to compromises Microsoft cannot eradicate. Instead they can only continue to choose more and more desperate ad hoc solutions in the hope things will get better - while everyone already understands things will only get worse.

You're Alone

Microsoft might dominate on the desktop but they're otherwise alone in the world of computing in general and in the world of Internet computing in particular.

Every other available operating system in common use today is based on Unix, a 'server' operating system. The infrastructure of the Internet itself was built for computers running Unix and was built on computers running Unix.

IBM have their AIX and Linux, both Unix systems; Sun have their Solaris, also a Unix system; Hewlett-Packard have their HP-UX; Apple have their OS X; and the Linux community today have hundreds - if not thousands - of so-called 'distributions' all of which are Unix.

None of these other systems have ever had any trouble with malware; more importantly, they've rarely had any trouble with viruses, as they all have an adequate security model which prevents program files from being compromised. None of these systems worry about worms or trojans; there has never been (and most likely never will be) a worm outbreak on Unix systems.

And it's not because Windows is so popular either: Unix systems run over 70% of the planet's web servers: if there were an opportunity to exploit these computers, the authors of malware would have been there long ago.

For while it is true that to malware authors there is money in numbers - in the proliferation of Windows systems on kitchen tables and in shops - it's just a lucky fact for them that Windows is also hopelessly insecure.

The release of Microsoft Windows Vista is hardly going to change that.

Further Reading — Radsoft

Service Pack 3
Who Cares?
Windows Defender
Windows OneCare Live
Unplug the Internet
Writing on the Wall
Long Live the Registry
Clean Machines
Windows Requires Work Which Hinders Use
How Windows is @#$%ing You
The Vista Screenshots
Bringing clarity to your world
Vapori$e M$
MS ActiveVapor Revisited
Five Minute Job
You cannot log on to Windows XP after you remove Wsaupdater.exe
That Scum Sucker Bill Gates
Windows Workshop
Bill Sucks
What's Wrong With SP2
The Rise and Fall of Windows
Shoulders of Giants
Of ThinkPads & Trojans
The Emperor's New Clothes
The Half-Life of Gates
No Flaw
iBook
Too Many Fish In The Sea
They Ain't Got It
Fatal Flaws I
Gates' War on Terrorism
At Last!
User Beware
Think About It
A Matter of Trust
The Myth of Market Share
High Hopes

Further Reading — Microsoft

Using a Least-Privileged User Account
Applying the Principle of Least Privilege to User Accounts on Windows XP
Services and Service Accounts Security Planning Guide
Make Me Admin
PrivBar
Browsing the Web and Reading E-mail Safely as an Administrator
DropMyRights
Running restricted What does the 'protect my computer' option mean?
Administrator Accounts Security Planning Guide
Developer Best Practices and Guidelines for Applications in a Least Privileged Environment
Developing Software in Visual Studio .NET with Non-Administrative Privileges
How to Troubleshoot Program Compatibility Issues in Windows XP

About | Buy | News | Products | Rants | Search | Security
Copyright © Radsoft. All rights reserved.