Vista vs. Viruses

Microsoft’s latest development, Windows Vista, is positioned as a system with enhanced security. The official release data is scheduled for 30th January 2007. However, questions as to how realistic the claims of enhanced security are were being raised by the computing community long before a beta version was made available for download. What exactly are the functions which are designed to offer the user security? And how effective will they really be? Is it true that once Vista is released an antivirus won’t be necessary? This article is designed to address some of these issues.

We can’t help but be glad that the developer/vendor of the most widespread operating system for PCs has taken a serious look at user security. In installing Vista, you can be certain at least that the product’s developers made a concerted effort to integrate protection against cyber threats, and that they will continue to do so. However, the security functions currently implemented in Vista are not so all encompassing that the user can wave goodbye to other security software. (For more on this topic, read Natalya Kaspersky’s “Security from Microsoft – the door to a brave new world?”.)

The major innovation in security in Vista is User Account Control (which restricts user rights), PatchGuard (a system designed to protect the kernel) and Internet Explorer 7 security features. Other, less significant, security features, which include Address Space Layer Randomization (ASLR), Network Access Protection, Windows Service Handling, and protection against buffer overruns will not be examined in this article. Nor will we look at additional components, such as Windows Defender, the integrated firewall and antispyware solution – these are standard solutions, and how useful they are in terms of ensuring system security is a question of comparing them to similar solutions from other vendors.

User Account Control (UAC)

User Account Control, as the name suggests, restricts user rights. It functions according to the following principles:

1. Any user (including the Administrator) logging on to the system will have minimal rights, i.e. those given to a “Standard User”.
2. The “Standard User” account has slightly more extensive rights in comparison with those in preceding versions of Windows.
3. If a user, or an application launched by a user attempts to perform an action not listed in the rights for the “Standard User” account, the system will ask the user either to confirm this action (if the user is logged in as “Administrator”) or to provide the Administrator password (if the user is logged in as “Standard”).

Among the actions not included in the “Standard user” rights are the installation of applications and drivers, creating files in system directories, modifying system configuration etc.

Any developer involved in developing protection against malicious code will have encountered the situation where an action is certainly suspicious, but it’s impossible to tell if it’s malicious. The action may be malicious within a specific context, and should therefore be blocked or the user should be notified. However, in a different context, it may be that the action is performed by a legitimate application. Such situations are frequent: there is a reasonably large number of harmless applications which perform actions that can, from a security point of view, be regarded as suspicious. If the user were to be notified about every one of these actions with a request for confirmation, or a request to enter a password, the user will either go crazy, or disable the security feature.

From this point of view, I can’t take User Account Control seriously as a security measure against malicious programs. There is a high probability that a function which irritates the user will be disabled. Either the user will click on “allow” or s/he will enter the administrator password without a second thought.

On the other hand, User Account Control does provide a certain additional level of security for users logging in under the “Administrator” account. Specifically, if an application does not require high privileges, then it will be launched with minimal privileges, even under the “Administrator” account. A vulnerability detected in such an application will be less critical than a vulnerability detected in an application with high level privileges.

One other thing in favour of User Account Control. There is a small number of viruses which intercept firewall or other security solution warnings about suspicious behaviour. These malicious programs will ‘click’ on the appropriate button, causing the security solution to allow such actions. The window will be displayed on screen so quickly that the user hardly has time to notice it. Microsoft has included protection against such threats in the form of Secure Desktop: a window requesting increased rights will only accept a password entered by the user as confirmation that such an action should be allowed.

We should remember that any type of protection can be evaded, and because of this, the advantages provided by this new layer of defence are conditional, and, as practice shows, temporary. There are some very obvious and fairly dangerous ideas for evading User Account Control, which of course we won’t detail here, in order not to fuel the arms race.

Vista Kernel Protection

1. PatchGuard

The Vista kernel (only for 64 bit platforms) is allegedly protected against modification. This is highly relevant given the fact that kernel mode rootkits are becoming more and more widespread.

A kernel mode rootkit is a malicious program which hides its presence in the system by modifying kernel data, or a collection of utilities which makes it possible to mask the presence of another program.

The PatchGuard function monitors modifications to the service table, and the kernel descriptor table. At first glance, this would seem to solve the issue of Trojans which mask their presence in the system. However, PatchGuard can hardly be viewed as providing serious protection against rootkits. It is, by its very nature, vulnerable, as is demonstrated by the existence of documented methods for disabling protection. The major vulnerability within PatchGuard is architectural: the code which ensures protection is executed at the same level as code which it is both designed to protect, and to protect against. This protection has the same rights as a potential attacker, and can be evaded or disabled. Ways in which PatchGuard can be exploited or disabled are already known.

In addition to the fact that PatchGuard provides questionable protection against rootkits which modify the kernel, it should also be noted that there are other types of rootkit which this type of security does not offer protection against. PatchGuard monitoring applies to the static structures of the kernel which have known contents (SST, IDT, and GDT) but it cannot protect dynamic structures, i.e. everything which is not at kernel level. One example of such a rootkit, which functions by modifying dynamic structures, is the well known FU rootkit. Rootkits which utilize virtual technology will be located “deeper” than kernel level, and will not therefore be inaccessible by the kernel.

The fundamental vulnerability of PatchGuard is due to the fact that it functions at the same level it is designed to protect. This means that if a malicious application has succeeded in loading its driver, it will be able to disable PatchGuard. Of course, this assumes the location of the relevant monitoring function is known – but it’s been clear for a long time that obscurity has little to do with security.

Undoubtedly, preventing modifications to the kernel is useful in that legitimate software won’t be able to modify the kernel for its own ends. This will have a positive effect on the stability and overall security of the system.

It should be noted that Microsoft’s attempts to increase system stability overall has had side effects. By making it impossible for anyone/ anything to access the kernel, Microsoft has made it impossible for security solution vendors to implement certain functionality within their products. As a result, it’s currently not possible to use the full range of effective tools developed by antivirus vendors in the security area. This applies not only to technologies designed to combat rootkits, but also proactive protection technologies used to detect unknown threats, which have been implemented in products for previous operating system versions. Virus writers are now in some senses in a better position – they’re not required to tackle PatchGuard head on, and rootkits will simply be able to disable it.

In talking about Vista kernel protection, we should stress again that both PatchGuard and driver signing are functions which are only available on 64 bit equipment. Some time will have to pass before this platform becomes as widespread as 32 bit. Vista x86 does not have dedicated protection against rootkits.

2. Mandatory Kernel Mode and Driver Signing

The second component of Windows Vista kernel security for 64 bit platforms is a mandatory digital signature for any module or driver at kernel level.

There are several documented methods for disabling signature checking, among them methods which are designed to simplify the driver development and testing process. This is because the issue of how to develop drivers is real – it’s impossible to ask for a digital signature for every build prior to testing – which is why there are several ways to disable signature checking:

1. Connecting a system debugger
2. Choosing a mode from the boot menu which does not control/ monitor drivers (includes modifying boot.ini)
3. Enabling support for test signatures in the security configuration. A utility for creating test signatures is provided.

These three documented ways of disabling protection in themselves provide great opportunities for experiment. In addition to this, of course, relevant vulnerabilities are being searched for. Six months ago Joanna Rutkowska demonstrated her variant of an exploit. In Vista RC2 this vulnerability was fixed, but a precedent has already been created.

We anticipate a multitude of methods designed to get around kernel mode protection by loading unsigned components. Exploiting documented methods of disabling protection, developing exploits similar to the one mentioned above, gaining kernel level privileges without using a driver and finally, using a signed driver from a legitimate product with malicious intent (in a similar way to how some viruses use components of legitimate password retrieval utilities to steal confidential information).

Once again, the verdict is the same: yes, this function protects the operating system against malicious code, but it is not as effective as the developers claim.

IE7 security features

The IE7 security features should, in theory, protect the computer against exploits placed on web sites which then execute malicious code or install a Trojan to the system.

1. In Protected Mode, browser code is launched with the lowest level of privileges, limited access to the file system, registry etc.

Protected mode can be enabled or disabled by the user for each separate zone. By default, it is enabled for nodes which are included in the Trusted Zone list. In addition to this, Microsoft offers a Protected Mode API to create management tools which are compatible with Protected Mode. This is a brand new function which has not been tested under fire, as it were, making it highly likely that this function is also very vulnerable.

2. ActiveX Opt-in is a function which blocks all ActiveX management tools apart from those which are explicitly allowed by the users.

It’s hard to see where the advantage of this function lies. The ability to disable ActiveX has always been present in IE. The only difference is that in IE7 this feature is automatically enabled. Additionally, experience of previous versions of IE show that users are reluctant to disable ActiveX. Why? Because if they do, they will either be unable to view flash clips on web pages, or they will have to put up with tiresome pop-up windows from the security system each time such a clip is viewed. It’s easy to come to the conclusion that IE7 has suffered from the point of view of usability. And as for executing unknown ActiveX components – it’s been permitted before, and it will continue to be permitted.

3. The Cross-Domain Scripting Attack Prevention is designed to prevent scripts working with each other across domains, and, in doing so, to protect against phishing attacks.

It should be stressed here that phishing attacks which use cross-domain scripting comprise only a small percentage of attacks known to us.

The security functions in IE7 are not limited to the three described above, and also include the Phishing Filter, the Security Status Bar and others.

How are security features such as UAC, PatchGuard, and IE Protected Mode inadequate?

Let’s take a hypothetical firewall, which is the most obvious example of barrier protection. Of course, it’s an ‘intelligent’ firewall; it doesn’t only use lists of permitted and blocked programs, but also works with system events.

When a program tries to transmit information to a network, this is a security threat. A firewall can react in one of two ways: it can block this action in accordance with its security policy (which may have been configured by the user) or it can ask the user whether this action is allowed. In the first case it is inevitable that legitimate programs will be blocked, which will be inconvenient. The user will have to work out why the program isn’t working and add it to the firewall’s white list. In the second case, it’s inevitable that a large number (after all, it’s a high quality firewall) of windows will pop up, which the user will have to react to. It’s not clear which is the lesser of these two evils.

In the case of a firewall which tracks application activity, it is possible to reduce the number of alerts by increasing the white lists over time. However, from a security point of view this is ineffective. Threats are both numerous and unpredictable, and the reaction to them shouldn’t be overly strict, as we then find ourselves back at step one, with enforced restrictions. But if the reaction isn’t stringent, then it will be irritating.

Enforcing restrictions does ensure security, but damages usability.

So what will happen to viruses?

Vista for 64 bit platforms does strike a blow, first and foremost, against Trojans which use drivers and modify kernel data. However, this is only until the authors of these Trojans start to find ways to evade such restrictions. This particular class of Trojans is not particularly large, and comprises probably less than 5% of all Windows viruses. Vista for the more popular 32 bit platform does not have Kernel Protection Mode and consequently, offers no specific protection against this class of Trojans.

User Account Control is built into Vista regardless of the platform. It will hinder to some extent a significant percentage of those Trojans which require administrator level privileges (such as creating files in the system directory, modifying the registry, configuring auto-launch etc.). I say ‘to some extent’ firstly because I do not regard User Account Control as providing serious protection against viruses (see above) and secondly because malicious programs can always cause a certain amount of damage, no matter how restricted the environment within which they are operating. For instance, a worm which spreads via P2P networks does not perform any “illegal” actions: it simply creates a copy of itself in directories which are used for file sharing. One example of a simple, but dangerous virus is Virus.Win32.Gpcode, which attracted a lot of attention due to its payload: it encrypted user documents and then demanded a ransom for their decryption.

It is difficult to predict how IE7 security features will affect viruses which install themselves via web pages. It’s likely that there will be no effect at all, particularly if we take the long view, and also take into account that very few users will find it convenient to use a browser where every action is forbidden or blocked.

To summarize: is Vista secure?

Is Vista really as secure as the advertisements claim? Vista is undoubtedly more secure than previous operating systems from Microsoft. And a system which is configured in such a way that everything is blocked except for access to designated sites could be regarded as being absolutely secure.

However, the majority of users will find the significant restrictions on actions which effectively sterilize the system unacceptable, just as the constant requests to confirm or enter a password for an action which the system defines as being ‘potentially dangerous’. And it is at this point that the ‘almost totally secure’ system is transformed into a ‘more vulnerable’ system.

We should also remember that people are the weakest link in any security system. Email worms are still in existence, and they continue to spread, in spite of the insistent warnings of security professionals not to open attachments to suspicious emails. Given that these pronouncements don’t seem to prevent the majority of users from launching attachments, will alerts from the security system – for instance, requiring the user to enter the administrator’s password – really help? And as I stated above, multiple pop-ups will probably irritate the user to such an extent that s/he will either disable the feature, or simply refuse to take it seriously.

Given that Microsoft systems are very popular, cyber criminals will always be interested in finding vulnerabilities. We’ll take an incurably optimistic approach, and not take Microsoft’s previous security record, established over many years, into account. The fact is that neither the quality nor the quantity of barriers intended to protect against hackers play a significant role. In fact, the opposite is true: they simply stimulate the interest of a particular subsection of the computer underground. The only significant factor is that hackers and virus writers will search for vulnerabilities – that much is clear. And if they are searching for vulnerabilities they will find them.

A philosophical conclusion

Security which is built on any principle except openness is always a double-edged sword. Security which is built around restrictions will always have a negative side: the restrictions themselves, which may make a system effectively unusable.

Which is better – a ‘fundamentally secure’ system, which doesn’t allow the user to do what s/he wants, or a vulnerable but functional system which includes specific services targeting concrete types of threat?

Freedom itself creates threats, whereas restrictions reduce flexibility. The more restrictions, the less user friendly the system will be.

In other words, if you are jealous of your partner, you may forbid him/ her to go out alone, or you may even lock him/ her up. Of course, the greater the restrictions, the less likelihood there is of someone else entering into a relationship with your partner. But the more restrictions, the less happy your partner will be. Ultimately, the question is do you really want an unhappy partner?

Even if an ideal balance can be found between restrictions and usability, the history of security shows that any protective barrier can eventually be overcome or evaded in some way, as long as someone, somewhere, is interested in doing so.

When too much importance is placed on the role restrictions play within a security system, we get the following picture: a lot of headaches and alert windows for the ‘good guys’, such as users and developers, and a lot of malware related puzzles and relatively few headaches for the hackers and virus writers. At least for now.

References

1. Authentium blog, Microsoft Patchguard
2. Joanna Rutkowska, “Introducing Stealth Malware Taxonomy”
3. Joanna Rutkowska, “Subverting Vista Kernel for Fun and Profit”
4. Windows Vista Security Guide