Is Microsoft not patching Windows 7 for problems it patches in Windows 8?

Is Microsoft not patching Windows 7 for problems it patches in Windows 8?

Summary: Researchers have found that Windows 8 code contains security check code absent in Windows 7. This is not the same as not patching.

TOPICS: Security

Researchers studying and comparing Microsoft code in Windows 7 and Windows 8 have found that there is security code in Windows 8 that is not present in Windows 7. Fundamentally, this is a dog-bites-man story; new versions of software come with new features, sometimes even security features. Is it unreasonable for Microsoft to leave these changes out of Windows 7?

The paper was presented at the TROOPERS14 conference in Germany in March, and the presentation is on YouTube.

Then last week The Register ran a story entitled "Redmond is patching Windows 8 but NOT Windows 7, say security bods." This is not a fair way to describe the findings, although the researchers themselves are very happy to snipe at Microsoft. But the research is interesting and raises some useful questions that users and buyers might find informative.

We have asked Microsoft for comment and will update the story when we get it.

Microsoft began instituting rules to ensure secure programming practices over ten years ago. These practices became the SDL (Security Development Lifecycle), and are documented for everyone to use. It's not a static document; over time, new rules have been added and some have become more strict.

The calls which the researchers, Moti Joseph and Marion Marschalek, focused on were related to these practices. Many of the "standard" C language runtime libraries are poorly-implemented, and SDL requires programmers to use "safe" alternatives, such as the Strsafe functions for strings. These versions do security checks, such as ensuring that no buffers are overrun.

These are the calls that Joseph's and Marschalek's research looked for. They are not "patches," and the distinction is a significant one. Patches address a known problem. These calls protect against potential problems. They are proactive measures added to make the product more resistant to attack. It's likely that many of them are unnecessary, that the code being protected is not, as a practical matter, exploitable, assuming that there are even problems in the code being protected with the safe functions. But over time, the standards for these things become stricter, and it's not surprising to find more used in Windows 8 than Windows 7.

So it's the way of the world that newer versions get new security features, as when Microsoft added ASLR (Address Space Layout Randomization) to Windows Vista and did not back-port it to Windows XP. But is it fair for Microsoft always to withhold new security features from shipping version X and save them for the upcoming version X+1?

In fact, this isn't a hard-and-fast rule at Microsoft. Just last month Microsoft released KB2871997: Update to improve credentials protection and management. In a blog last week, Joe Bialek, an engineer with the Microsoft Security Response Center, explained the update and how it also applies to Windows 7. The updates remove some use of plain-text passwords and adds support for some newer security features.

But this sort of change is a far cry from adding to Windows 7 all the safe function usage of Windows 8. Doing that would have the potential to change a large percentage of the program files in Windows, leading to hundreds of MB of updates.

It's also interesting that Microsoft's Support Lifecycle documents don't obligate them to provide new features to shipping products, even those, such as Windows 7, that are still in the Mainstream Support period. Customers can request new features.

There's a line in there somewhere between reasonable and unreasonable. Microsoft has chosen not to give it a hard definition, and perhaps that's for the best. I certainly don't know how to define it.

Topic: Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Backward compatability

    I think a more important reason not to just change all API calls everywhere is backward compatibility. It is reasonable that between OS releases some software breaks and the new version is just mostly compatible with the old version. For updates however the standard of compatibility should (and I believe is) be much higher. Unless it's an exploitable security hole why would Microsoft risk breaking existing software from update to update.
  • If it ain't broke.

    Don't fix it. Windows 7 is out and in use. To go back, even in the name of security, and replace sizable chunks of it because NOW there is a better (or maybe just different) way to do something is ludicrous.

    Case in VERY VISIBLE point - OpenSSL. The "change" that let to Heartbleed was not really needed, but was a "nice to have" performance enhancement. So they changed it and then, instead of making it available in a newer version they advised replacing EVERY occurrence of it. BAM!

    And we wonder why those who have to run this stuff day after day are hesitant to jump on the latest patch. Sure, patching all Windows versions would be nice to do, but what if what you are introducing breaks APIs, or worse, interprocess parts of the host code itself. And we all know EVERY part of a complex piece of software is tested...don't we.

    Right now, we are treating the OS wars (and betcha this is what this is, as well as modern yellow journalism (if you don't know this, check history). It also shows how much time, resources and MONEY are there to be spent and made on "security" these days. Who was paying these guys to sit there and compare the code for Windows versions (and hey, how did third parties get the source code for this anyway - or were they disassembling)? And wanna bet if these guys are doing it the bad guys already did that and moved on to lower-hanging fruit?

    That may also explain why a newer version of Windows takes as long as it does. Introducing a new rule like this (or several, as these claims say) has to break compiles. So stuff needs to be rebuilt. Then it needs to be retested. And for what - an internal standards change. Been there, done that.

    So, if you get the warm fuzzies by this, UPGRADE. If not, go on until something does break. And these people really need a life. Or a good salary!
  • "Researchers" doing code compare ???

    Don't they have anything better to do...LOL.
    • Owl:Net: "Don't they have anything better to do..."

      Better ... like writing trolling at ZDNet?
      Rabid Howler Monkey
      • Hmmm.

        Rabid Howler Monkey making a jab at Owl:Net for trolling.....

        Wow. this whole "trolling" label has gotten way out of hand.

        When Rabid Howler Monkey tells Owl:net hes a troll you might just as well have the Joker tell the Penguin hes a crook.

        This really is getting laughable. You could make a sitcom out of the nonsense that goes on around here.
        • What's laughable ...

          are your long, long, LONG diatribes at ZDNet that have little to no information content.
          Rabid Howler Monkey
          • says the pot

            callling the kettle...
  • Windows XP and ASLR

    There are two products that provide ASLR protection on Windows XP:

    1. Microsoft' EMET provides SEHOP and Bottom ASLR (it's weak)
    2. WehnTrust (at Microsoft' CodePlex) provides SEHOP and ASLR:

    Just note that there is a conflict with SEHOP between EMET and WehnTrust, so disable EMET SEHOP for all applications protected. In addition, there is an unpatched vulnerability with WehnTrust that is exploitable if one runs as the Administrator. It's best to run in a limited user account on Windows XP anyway.

    Both EMET and WehnTrust can be considered as 3rd party ASLR backports to Windows XP.
    Rabid Howler Monkey
    • Note: If I could edit out my use of 'backports' in my last line, I would

      My point is that ASLR protection, including SEHOP, has been available to Windows XP since approximately 2006.
      Rabid Howler Monkey
  • Sane reporting

    for a change. Thank you.

    As far as I understand it, the calls just provide a pre-defined way of what any programmer should be doing anyway. I.e. any half competent programmer has been doing these checks themselves for the last n years and MS have now included a prototype for doing it automatically for them, making their job easier in the future.

    As you say, new versions get new security features.

    Guess what, the new model of my car has more security features than the one I have. Toyota haven't offered to retro fit those either.

    Looking at some of the forums, you'd think the world was ending. That Linux, OS X, iOS, Android etc. all do this as well doesn't seem to interest those chasing a good headline, evil Microsoft, a month after abandoning Win XP they are now abandoning W7!! Oh noes!!!

    All it does is show that the "researchers" took a very long time to get around to comparing those libraries...
  • Why do "researchers" feel the need to do something so childish?

    "This is not a fair way to describe the findings, although the researchers themselves are very happy to snipe at Microsoft."
    • nah,,, just a really slow summer for "researchers"

      I am not sure why the author calls them "researchers". They call themselves "TROOPERS". If only the author stayed with the "troopers" in the summary and the text ... well you can finish the sentence yourself.
    • The point of research is to gain information about things

      it is up to the user to determine whether the information imparts any useful knowledge, or whether the researchers were too impartial to usefully contribute to the pool of knowledge about a technology.

      Personally, I would always prefer research be done than not done.
  • Researchers surprised to see different code?

    It looks like researchers were surprised to see different code in win7 and win8. Maybe they believed that all windows versions from 95 up to windows 8 had the same code and only bitmaps and icons were different?
  • I wouldn't do that....

    Do so at your own risk Microsoft. You alienate Windows 7 users, and you have BIG problems on your hands.
    • Do you really think....

      that the average Win7 user knows or cares about this? This is not going to "alienate" anyone. Most people I know don't update the system and can't figure out that you have to empty the trash can every so often!
      Thomas Kolakowski
      • So you hang with a bunch of boobs

        So your justification for Microsoft not upgrading the security code in Windows 7 is based upon the assumption that "most people are dumb". LOL. Nice theory there.
    • They've already alienated tens if not hundreds of millions of XP users

      what's a few more tens or hundreds of millions? They're going to passive aggressively coerce everyone they can onto windows 8.x, rather than put resources into improving a win7 stripped of the touch stuff that is useless in the commercial area. Nothing wrong with maintaining two forks, one for people who use computers for work and people who use computers for entertainment. Each is used differently, why not develop for each?
      • What?

        Why would they continue to update Windows 7 indefinitely?

        What is in it for them, the company? Or do you expect them to do it out of the kindness of their hearts?

        Also, how did they alienate hundreds of millions of XP users? I can't think of a single vendor that has supported a single release for as long as Microsoft has supported XP.
        Michael Alan Goff
        • I've pointed it out

          but the situation, while rare, is not wholly unheard of. You can, to this day, obtain a form of paid support for OS/2 from IBM. Sun/Oracle supported SunOS 4.1 for longer. Irix also had a comparably lengthy support life.

          By no means am I being critical of Microsoft, they did well here, especially given people only paid the $40 OEM license cost. But it isn't unheard of benevolence either.