Internet Explorer vs. Firefox: Which Security Is Higher?

You may want to take a look at the recent Security Insight newsletter for November (http://www.agnitum.com/news/securityinsight/issues/november2006) where I tried to shed some light on the two leading Internet browsers’ latest security features added with the release. I basically enumerated them there and accompanied with my own experience where possible.

Igor Pankov,
Product Marketing Manager at Agnitum

The Top Six 64-bit Windows Kernel Patch Protection Myths - Dispelled

There’s a lot of debate about Microsoft’s latest Kernel Patch Protection (KPP) initiative. A move to protect the Windows core has sparked many controversial opinions and suggestions. As an independent security vendor (ISV), Agnitum is seriously affected by the moves made by Microsoft, and Agnitum cannot stay quietly on the sidelines. Here’s our take on the situation.

First off, it’s quite understandable that Microsoft has decided to implement KPP in its new generation of operating systems. Windows security clearly needs improvement. We also agree that due to the surge in malware activity and the arrival of new threats, such as rootkits and blended attacks, there’s an acute need to do something to counter the escalating danger. We believe that protecting the kernel is a beneficial step in the right direction; the kernel is the core of the OS and it should be reliably protected from tampering before anything else.

However, by isolating the kernel from outside access, Microsoft has prevented us, and prevented other ISVs, from being able to monitor and control critical areas and objects on a PC. As a consequence, this reduces protection for users who confront more aggravating and elaborate hack techniques. By denying close integration to the kernel, we can no longer enforce total protection against abnormal or unlawful program behavior on a PC, nor can we properly protect our own products from sabotage.

Having said this, a logical argument like: “you cannot any longer provide the full scope of protection, while others can, so people would just switch to another provider” might seem a reasonable response. However, reality intrudes. Neither Microsoft nor other vendors can protect users of 64-bit systems as reliably as they are doing it for x32 environments. Microsoft can’t, even when it delivers basic security offerings such as the firewall built into Windows. ISVs can’t, because they are unable to integrate tightly into the system – an inability that prevents them from adding functionality that bans sophisticated malware operations.

For example, Agnitum is the winner of the Firewall Termination Tests (http://www.firewallleaktester.com/termination.php) – but cannot extend this level of protection to 64-bit Windows because of KPP limitations. This is just one of many examples of the impact caused by kernel isolation hurdles.

Specifically, there are six KPP myths that argue that the Microsoft decision to shield the kernel is totally beneficial to users. We have a different opinion:

Thesis 1: Microsoft has always discouraged and objected to the use of undocumented kernel modifications and always called on the ISVs to abandon the practice of kernel access and use other development tools designed by Microsoft instead.

In its move to equip Windows x64 with KPP, Microsoft has forgotten to negotiate and harmonize with its partners the exact mechanism of PatchGuard implementation. ISVs that historically relied on Microsoft for proper and informed rollout of new features, this time, instead, were given a cold shower, with MS failing to provide any feasible alternative to proven approaches that have boosted Windows defenses.

While MS may discourage and object to the use of undocumented APIs, the fact is, “undocumented and unsupported system hooks” do exist in every iteration of Windows.

After some current debate, Microsoft now offers to address KPP by providing ISVs with supplemental APIs. This is an amusing proposal because, firstly, we’ve never had a chance to look at the APIs – because they do not yet exist.

And, presuming we do get a look at these promised APIs, which Microsoft says it will deliver – maybe in 18 months, as part of the first service pack for Windows Vista -- we believe that the APIs will not allow Agnitum and other ISVs to properly secure Windows to the degree that users have come to expect.

From what we hear, these promised APIs will not permit the level of control that ISVs have had for direct kernel access. Broadly, if history is any indication, Microsoft has a very different opinion of what security vendors need to have to protect Windows users, vs. what ISVs know from experience we need if we are to provide the levels of protection that Windows users truly deserve. In this light, we believe Microsoft should have worked with ISVs prior to making a unilateral decision to withdraw kernel access.

What will it take to align our products with the proposed APIs? We don’t know. Microsoft has yet to announce the APIs and provide details. We’re waiting for that first service pack, which is slated for release no earlier than 2008. If Microsoft chooses to, it might delay that delivery by another half-year or year, distributing only interim weekly patches.

Thesis 2: Microsoft is offering ISVs all necessary instruments; it never wanted to stifle competition. Besides, KPP in not new, and is meant to lock the kernel from bad guys’ access only.

Yes, it’s true. KPP existed since the release of the first x64 Windows, but it was largely weak and unprotected compared to what Microsoft now proffers with Vista x64.

Microsoft keeps telling us that security vendors don’t need to interact with the kernel itself in order to provide robust security. However, we know from our research and testing that this far from reality.

Specifically, with Outpost, we will not be able to provide the same level of defense for x64-bit Windows, as we did for 32-bit version in two features:

• Self protection, which ensures that malware can’t shut down Outpost. Self-protection will rely on KPP in x64 environment. If some malware will pass KPP and install itself on the kernel level, then the whole system will be compromised, no matter what security utilities a user has.
• AntiLeak mechanisms that control the behavior of applications on a PC, preventing Outpost from ensuring that program interaction and OS communication is legitimate. In 32-bit Windows, the AntiLeak module is installed at the kernel level to give 100 percent protection against known information leakage techniques. In contrast, in the x64 environment, this protection won’t be that powerful, since it is impossible to install drivers at the kernel level -- and no alternatives are offered by Microsoft.

These security tools already protect x32 Windows users of Outpost against advanced malware techniques that steal data. Outpost is the only firewall that passes all independent x32 leaktests (http://www.agnitum.com/download/pr/Outpost_vs_leaktests.pdf) – yet Microsoft would leave x64 Windows users naked and exposed.

Let’s also remember that Microsoft is the author of the OS. Where MS can build in its own proprietary hooks and APIs for its own monitoring and control functions, ISVs have to write auxiliary code if they are to add protective capabilities by interacting with program calls and intercept hostile commands at the kernel level before they are executed by malware. Since Microsoft is the author of the kernel, it can substitute kernel-specific functions with its proprietary code – code that is not known to outsiders, not made available to outsiders, code that potentially escapes the need to access the kernel directly in order to provide protection. Simply, MS in this regard doesn’t need to bother with inserting system hooks and interceptors; instead; it can incorporate all necessary filters directly into its own code. Hooks are needed by third-party components from ISVs who are not permitted by Microsoft to modify the code.

Thesis 3: Vista with KPP is already more secure than any other version of Windows; even if kernel access were to be granted to the selected ISVs, this won’t improve the situation and could well worsen it. We’ll provide all necessary support through the provision of other tools such as APIs and mini-filters.

The APIs are broadly advertised, yet seen by few. We have not seen them. Secondly, as already noted, Microsoft will not make the APIs available until the first Service Pack 1 for Vista Timeframe. Historically, this takes 12 to 18 months, and will prolong the period during which Vista is naked to attack, and users are exposed to Microsoft failures. During this period, Microsoft monopolizes all the security choices available to users.

Equally significant, with KPP, if kernel modification is detected in 64-bit Windows, the system “commits suicide” by triggering the BSoD (Blue Screen of Death) emergency shutdown. These shutdowns are initiated on an attempt by Windows to verify the integrity of the kernel, which does not coincide with the time the actual attempt to write to the kernel is made. Thus, once activated, the KPP would lead to users losing unsaved data and, in worse cases, put Windows at risk of not being operable again on subsequent start-ups.

In that light, imagine Vista performing a scheduled defrag operation at the same time that KPP activates. This will bring Windows to collapse. It will be amazing if Windows manages to bootup again.

This doesn’t look like user protection. Instead, it looks more and more like a method to avenge for kernel tampering by blowing up Windows; how’s that for customer service?

Most importantly, it doesn’t bolster protection, since malware would have comfortably existed and operated between shutdown phases, doing whatever it’s programmed to, including sending spam or communicating confidential information.

Thesis 4 “KPP is flawless, it will kill malware at the core! KPP is meant to reinforce all 64-bit Windows at once”

This is a joke, right? Does anyone seriously expect “flawless” software from Microsoft?

The fact is, published reports document that security researchers have broken KPP already -- before x64 Windows ships. Think about how this telegraphs to hackers how vulnerable KPP is. It seems pretty obvious that this system will be broken quite soon – and not by the good guys. Microsoft has to be aware it is erecting one large target.

As soon as unlawful ways to bypass the KPP are found, any credible malware writer will utilize them in his/her work to open the road for propagation and harming users. And if Microsoft continues to release updates to KPP the way it schedules patches, malware is going to exist on a system for many months into the future.

Security vendors, on the other hand, cannot afford this luxury. Our products cannot be incompatible or unstable on patched versions of Windows. We cannot be the cause of blue screens as Microsoft struggles to fix and fix KPP again and again while we tweak our products to accommodate for KPP updates. Microsoft is confining us to fighting known types of malware only through “authorized” mini-filters. Potentially, we won’t even be able to protect our own products against tampering by malware while waiting for Microsoft to do something about the latest-discovered holes in KPP.

Thesis 5:“Microsoft doesn’t resort to kernel patching, it uses documented solutions to protect its customers”

Microsoft can implement code modification on its own, adding necessary functionality as it needs. It does not need to modify the kernel, because Microsoft posits that kernel modification is meant for those who are not satisfied with the standard functionality. That’s great if you want a kernel that is already broken and vulnerable to hackers breaking it again. We don’t.

Thesis 6 “Microsoft cannot provide exceptions to Kernel Patch Protection for known good software. Besides, the process of distinguishing the good from the bad is too burdensome to MS”

In reality, KPP can be switched off when needed. This for example happens to Windows running in Safe Mode.

Unfortunately, by not distinguishing between the good and the bad, Microsoft has on one hand saved a lot of time for itself in testing, auditing and granting KPP exclusions to itself. At the same time, by creating these conveniences for itself, Microsoft also establishes new hurdles that limit third-party security vendors in a market that Microsoft targets for its own revenue growth.

Igor Pankov,
Product Marketing Manager at Agnitum

One more Windows exploit found!

eWEEK reports (http://www.eweek.com/article2/0,1895,2048204,00.asp) that “detailed exploit code for a Windows XP security vulnerability has been published on the Internet, offering a roadmap for hackers to disable the firewall embedeed in the operating system.”

This does NOT affect users of Outpost Firewall Pro. We tested. The exploit fails to shut down Outpost, and Outpost continues to protect users of Windows XP.

Here’s the irony. This new vulnerability does not really make Windows users any less secure, because anyone depending on the firewall built into XP is already vulnerable.

The firewall built into XP does not provide outbound protection. With no outbound protection, users relying on the firewall built into XP have no way to prevent adware, Spyware, Trojans, phishing exploits and malware from stealing personal information from a PC.

The Windows XP firewall fails all 18 independent leak tests, documented here: www.firewallleaktester.com

Most third-party firewalls can block at least half the leak tests. On the other hand, Outpost Firewall PRO 4.0 is the only firewall that blocked every leak test from the list.

Also relevant, these tests provide independent confirmation that Outpost is the software firewall best able to defend itself from the type of direct and brutal attacks that can cripple, disable and shut down less robust firewalls.

We build self-protection technologies into Outpost that prevent Outpost from being deactivated by viruses, Trojans or Spyware. Outpost continuously monitors its own files on the hard drive, as well as registry entries, memory status and running services, and blocks any attempted changes by malicious applications.

To learn more about how Outpost Firewall Pro 4.0 passes security leak-tests please refer to our white-paper "Outpost Firewall Pro vs. Leak tests".

Igor Pankov,
Product Marketing Manager at Agnitum