☆ Is Windows to blame for viruses?

Bug engaged in exploitA historical post, for a change. A comment on a mailing list tonight – that something was “rather like blaming Windows for getting viruses” –  sent me exploring my recollections of CPU security on Intel chips from my days at IBM. I went scurrying to find a half-remembered explanation from the past of why, in addition to the larger user base making the target much more tempting, Windows has suffered from virus attacks much more than anyone else to date. I couldn’t find it straight away so this post is the result.

Before you add a comment, note I am NOT saying that the only explanation for Windows viruses is this technical one; obviously the huge attack surface of the giant user base attracts attackers. I AM saying, however, that leaving the door open for a decade hasn’t helped and is a major reason why the dominant form of malware on Windows is the virus and not the trojan.


All operating systems have bugs, and I suspect (although haven’t found any data tonight to confirm) that they occur at approximately the same frequency in all mature released operating systems. All operating systems that respect Shaw’s Law are also vulnerable to malware. Malware depends on identifying exploits – defects of some sort in system security that can be “exploited” to permit infestation by the malware.

Not all bugs turn into security exploits, though. In particular, in Unix-like operating systems like OS X, Linux and Solaris, it’s unusual for bugs to lead directly to security exploits; instead, most malware depends on user error or social engineering.  For an exploit to exist, there has to be a way to use knowledge of the bug to gain access to a resource that would otherwise be forbidden.  It certainly happens on *ix systems, but the operating system has checks in place to prevent the most common way of turning bugs into exploits.

Unauthorised Pokes

The most common way for this to happen (although there are many others) is for the operating system to fail to differentiate between data and program code. By treating code and data  as the same thing, a path is opened for malware to use a bug to push some data into a memory location (a “buffer over-run” or a “stack overflow” are examples of this) and then tell the computer to execute it. Hey presto – exploit. All an attacker has to do is push code for a virus (or a virus bootstrap) into memory and ask for it to be executed, and your computer is compromised.

Windows could have prevented this sort of thing from happening by exploiting ring protection offered by Intel x86 architecture from the 80186 chip onwards. A feature of Intel’s x86 architecture makes it possible to prohibit execution of data unless the program in question is privileged (“at ring 0”), usually by being part of the operating system. Application code at ring 3 can be forbidden from executing data.

Indeed, Windows did use ring 0/ring 3 differentiation for some jobs (skipping rings 1 and 2 for cross-platform technical reasons). But access to ring 0 – “able to execute anything you want” – was never prohibited. Doing so would have prevented legacy DOS code from running, so as I remember being told, Microsoft chose not to implement ring 0/ring 3 protection in Windows NT until it was completely sure that deprecating DOS legacy support would no longer be a marketing issue. That was in Windows 8…

Credit Where Due

So actually it’s somewhat appropriate to blame Windows versions prior to Windows 8 for being vulnerable to many viruses which exploited bugs in this way. The existence of the vulnerability was a conscious choice and a marketing decision; in OS/2, which had no legacy to accommodate, the ring 0 separation was enforced.

Yes, Windows also offers a larger attack “surface” because of its wide adoption, and yes, there are other exploit mechanisms. But this tolerated technical vulnerability is the root cause of a large number of exploits. So while it’s true that malware authors are directly to blame for malware, there’s also a culpability for Microsoft that can’t be ignored. Thank goodness Windows 8 has addressed this particular issue.


9 Responses

  1. Interesting, but it would also be interesting to know what proportion of actual exploits use this particular path.

    • Stack overflow/buffer over-run errors are, as far as I am aware, the dominant form of exploit on pre-8 Windows systems. They are made impossible by locking down ring zero. I’ve added a note about them, thanks.

      • It’s not that simple to separate data and code with our current computer models (based on the von Neumann model or Princeton architecture). Yes, it can be made harder to execute any code and modern hardware (and operating systems) have technologies in place to do so, but it cannot be avoided completely.

        By the way: There are also Buffer-Overruns and Stack-Overflows in the *nix world ;).

        I would agree that the people from Microsoft have made some really dumb decisions in the past – mainly for legacy support stuff – but I think with their current patch model they have quite a good infrastructure in place.

        After all we can’t blame them when people deliberately turn off the auto update featueres without a reason (or the reason being that their copy of Windows isn’t legal), can we?

        I in no way want to protect Microsoft, but my guess would be that the problems they a confronted with in these days are more or less normal, when considering that they have a immensely complex system with many hundreds of million users and some of them are poking the system all the time.

        Unfortunately we haven’t come up with a practical solution to get secure system this complex, so until then the only practical solution will be: Patching/Updating our systems as often as possible.

        And I think Microsoft is arguably providing patches for known vulnerabilities “in-time” (meaning 1-2 months).

        I never would have thought of me saying that Microsoft is doing something right. However I still think the design of the Windows operating system is the worst and crappiest one ever ;).

        • > By the way: There are also
          > Buffer-Overruns and Stack-
          > Overflows in the *nix world

          Well yes, of course! But they simply make the program in which they happen malfunction. They don’t usually allow injection of a virus on *ix. As I say, all software has bugs, but not all bugs are exploits.

          > I in no way want to protect
          > Microsoft, but my guess would be that
          > the problems they a confronted
          > with in these days are more or less
          > normal

          I’m not considering Microsoft today; rather, I’m explaining an amazingly long-running and apparently intentional defect that exposed customers to malware and which appears to have been left in place for a decade for marketing reasons.

  2. This is -I believe- slightly inaccurate. Windows NT was modelled after the Mach kernel and it did have Kernel Ring protection, and applications up until Windows 2000 did more or less honour the same approach followed by similar kernels, ( the NeXT kernel that lives on in Mac OS X is also a Mach kernel,called XNU)

    However, for reasons I fail to comprehend, some of these kernel protection rules were lifted sometime around the time Windows XP was about to be released.

    Microsoft needed to allow for better graphics performance, so they made it possible for hardware vendors to do funky things with the kernel.
    So the best they could do, apparently, was to void some of the protections that applied to Ring protection up to that point.

    I even remember having seen a Microsoft presentation on this issue, they were touting the great benefits of this approach at the time, and you can imagine my surprise, as in “What the hell are they doing”.

    I have since lost respect for anything Microsoft say or do, so I don’t really know what they have done after that, or if this applies to their ‘server OS’ offerings.

    So, they used to do it more or less right, until they stopped making any sense, and it’s anyone’s guess whether they’re back to sanity yet, or if they’re seriously interested in security at all.

  3. I seem to remember makers of security software throwing a stink over Microsoft locking their kernel down or something. They were complaining that they couldn’t get access to the OS that they needed. My thought was “well, then neither could virus makers… duh!” Politics, politics, politics…

  4. […] https://webmink.com/2012/02/27/is-windows-to-blame-for-viruses/ […]

Comments are closed.

%d bloggers like this: