In a story about antivirus programs today, news of a common hole, allowing circumvention of protection is shown to be present in 35 different programs, one of which you probably use right now.

The description of how the problem occurs is given in detail, and for once, it looks as though Microsoft may have had a better idea, but did not stick to its guns on a certain decision.

[PC Magazine]

A new attack technique has been described by (a project of Different Internet Experience Ltd.) which could allow a program to bypass the host intrusion detection and certain other protections provided by common Windows security software. Their report lists 35 security products on which they tested the technique; it worked on all of them.

The technique is unrelated to the actual scanning functions of anti-malware programs. Such programs also attempt to block live attacks by software running on the system. In order to perform this monitoring on Windows security software “hooks” entries in the SSDT (System Service Descriptor Table), a table of handles for operating system calls. Calls to those operating system calls are dispatched to the security software which hooks it; that software examines the caller and parameters, looking for whatever problems it’s looking for and dealing with them as need be; then it directly calls the operating system service that the application attempted to call.

By using multiple threads, the matousec technique can modify the parameters to the system call while the hooked process is executing, thus causing it to allow execution of a call with parameters different from those it tested. The nature of the attack is such that it can be executed purely from user-mode code, lowering the bar for getting running the attack on the system.

This is a time when UAC does not seem to help one small bit, so those turning it off need not be overly concerned.

What is odd is that, since Microsoft has not had many problems with the breaking of many programs, in the name of security versus backwards compatibility, why have they not plugged this?  Of course it will make the antivirus vendors upset, but should our safety, as users (and the ones who pay for the software) not be the first concern?

This sort of bug, not uncommon in multithreaded programming, is called a race condition, in which two threads contend for access to a shared resource and program logic breaks down as a result. Because the attack is sensitive to the execution state of the SSDT hooks, it doesn’t work all the time. But the authors say that it often does work the first time and will work after a few tries in any event. They also say it is more reliable on multi-core processors.

The list of products found vulnerable is as follows:

  • 3D EQSecure Professional Edition 4.2
  • avast! Internet Security 5.0.462
  • AVG Internet Security 9.0.791
  • Avira Premium Security Suite
  • BitDefender Total Security 2010
  • Blink Professional 4.6.1
  • CA Internet Security Suite Plus 2010
  • Comodo Internet Security Free 4.0.138377.779
  • DefenseWall Personal Firewall 3.00
  • Dr.Web Security Space Pro
  • ESET Smart Security
  • F-Secure Internet Security 2010 10.00 build 246
  • G DATA TotalCare 2010
  • Kaspersky Internet Security 2010
  • KingSoft Personal Firewall 9 Plus 2009.05.07.70
  • Malware Defender 2.6.0
  • McAfee Total Protection 2010 10.0.580
  • Norman Security Suite PRO 8.0
  • Norton Internet Security 2010
  • Online Armor Premium
  • Online Solutions Security Suite 1.5.14905.0
  • Outpost Security Suite Pro
  • Outpost Security Suite Pro 7.0.3330.505.1221 BETA VERSION
  • Panda Internet Security 2010 15.01.00
  • PC Tools Firewall Plus
  • PrivateFirewall
  • Security Shield 2010
  • Sophos Endpoint Security and Control 9.0.5
  • ThreatFire
  • Trend Micro Internet Security Pro 2010 17.50.1647.0000
  • Vba32 Personal
  • VIPRE Antivirus Premium 4.0.3272
  • VirusBuster Internet Security Suite 3.2
  • Webroot Internet Security Essentials
  • ZoneAlarm Extreme Security 9.1.507.000

Perhaps Microsoft had problems like this in mind when they attempted to ban all kernel patching in 64-bit versions of Windows several years ago. The feature which enforces this rule, called Kernel Patch Protection or PatchGuard, was objected to strongly by security software vendors, so Microsoft developed undocumented APIs to allow ISVs to get past PatchGuard and a policy for releasing the documentation.

Should this not be something that could be traced, so that people using the undocumented APIs would be easily found, and then prosecuted for their part in the distribution of malware?

The document casually asserts that 64-bit Windows shouldn’t be any different. This isn’t clear to me. They say that security products may just disable PatchGuard before installing, but Microsoft insists there is no way to disable PatchGuard. It’s possible that Microsoft’s undocumented APIs work in such a way that the attack technique would work just as it does on 32-bit Windows, but no testing or descriptions were provided to support this.

It’s also worth noting that the attack code itself has to be running on the system in order to perform the attack, and so it could be found by conventional scanning techniques. But this is a poor substitute for an actual fix.

Hat tip to The Register.

Something else that makes me think as I write this…    What if this was an effort in a roundabout way from Microsoft to get people to not only drop Windows XP, but also to move to 64 bit Windows, allowing Microsoft to leave that part of the code base behind.

Another thing – you’ll notice that Windows Security Essentials is not on the list above.

Stranger things have happened; just because you’re paranoid doesn’t mean that the things you speak of are not happening.


I will not eat oysters. I want my food dead. Not sick, not wounded, dead.Woody Allen

Opera, the fastest and most secure web browser

≡≡≡≡≡≡≡≡≡≡ Ḟᴵᴺᴵ ≡≡≡≡≡≡≡≡≡≡