Exploitation is Still Possible as Third-Parties Neglect to Implement Vista Security Features

Exploitation is Still Possible as Third-Parties Neglect to Implement Vista Security Features

Summary: Consider this, Microsoft spends huge amounts of dollars and manpower creating protections for the Vista operating system, yet we still have old school vulnerabilities. Why?

SHARE:
21

Consider this, Microsoft spends huge amounts of dollars and manpower creating protections for the Vista operating system, yet we still have old school vulnerabilities. Why? The answer is simple really, third-party created code is not stepping up and taking advantage of these powerful protection mechanisms.

I'm not the first to talk about this, certainly, but I feel it is very important to continue to bring to light until we see more widespread usage of these protections. In fact, I've seen a few really great discussions on the subject of these protections and where they succeed and fail just recently.

There's a number of protections that Vista has built-in, but for the purpose of this article, we're going to focus on DEP and ASLR.

  • Data Execution Prevention (DEP) attempts to prevent execution of code from a non-executable memory region. There's two ways it's achieved, hardware-based and software-based, which are described below:

    • Hardware-based DEP enables the No eXecutable (NX) bit on capable CPUs. Vista handles hardware DEP by marking certain areas of memory as being intended only to hold data which is interpreted by NX capable CPUs as being non-executable.
    • Software-based DEP is also called Safe Structured Exception Handling (SafeSEH) by Microsoft and attempts to prevent the corruption of addresses of exception handling code, which resides in the applications stack frame and could therefore be vulnerable to hijacking.

  • Address Space Layout Randomization (ASLR) is the process of randomizing the location of useful to attacker data areas, such as the base of executables and position of libraries, the heap, and the stack. This effectively means that if you can find a workable exploit, you may not be able to write exploit code as the key addresses used would change.

Unfortunately, the usage of DEP has caused some compatibility issues for applications that have self-modifying code, or perform just-in-time compilation, such as in the Java world; therefore, the usage of DEP is an opt-in protection. This means, we may not even have DEP protection in certain instances.  Case in point, have a look at John Heasman's blog where he describes an attack against a Java applet through the use of an attacker crafted TrueType font that could execute native code when run from the applet.

On top of this, DEP does not provide any ASLR by itself, and ASLR is also an opt-in protection. Because of this, even if DEP is enabled, a vulnerable piece of code could still be exploitable as it may be possible to perform a return-to-libc type of attack. Return-to-libc attacks make use of existing functions to inject malicious code into a program by first preparing the stack to provide proper arguments to the function, and then overwriting the return address on the stack with the location of this instruction.

Additionally, DEP may be disabled altogether if ASLR is not in use, as is demonstrated by skape and Skywing (aka geniuses) in the "Bypassing Windows Hardware-Enforced DEP" paper on the Uninformed site.

What's really important to gather from all of this, is that while Windows has made major improvements to it's security, the components that we add to our OS are leaving those great security enhancements out, and that's a big problem. As Maynor mentions on his blog:

"Turning on the ASLR flag in all products will undoubtedly cause (or expose) a few bugs, but most software will run just fine. There is no reason for software companies to continue to ignore this issue. Among the companies/products currently ignoring these features are: Mozilla’s Firefox, Google’s toolbar, Apple’s iTunes, Adobe’s PDF reader, Roxio’s media creation tools, and Divx’s player. Actually, we haven’t found any company that turns on ASLR consistently."

Hopefully this will change sooner rather than later. 

-Nate

Topics: Security, Microsoft, Windows

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

Talkback

21 comments
Log in or register to join the discussion
  • "Exploitation is Still Possible..."

    "What?s really important to gather from all of this, is that while Windows has made major improvements to it?s security..."

    its

    Obsessive-compuslsive or not, it's "its".
    --Glenn
    oregonnerd13
    • Yes . . .

      My OCD brain raised the same red flag! It's is a contraction of it is. Its is the possessive. As in, it's clear its name is IT.
      Gray Hawk
      • What a waste of space

        Come on people; it's just a fricking typo that most people (who incidentally DO know the difference between "its" and "it's") have done at least once.

        Stop wasting time and space and stick to the subject.
        OldGuru
        • And thus we see the acceptance and

          embrace of mediocrity.
          frgough
    • RE: Exploitation is Still Possible...

      Yeah, thanks Glenn. I really appreciate it. Obviously I'm a tech person and I focus on the tech aspect of these articles. I'd like to think the people here are more focused on that. I will keep its vs. it's in mind for future articles.

      -Nate
      nmcfeters
  • RE: Exploitation is Still Possible as Third-Parties Neglect to Implement Vista Security Features

    Vista has 12 major inbred security flaws. How do you expect third party vendors to do Microsoft's work for them? Microsoft is responsible for closing the exploits.
    dv8Cowboy
    • Name them...

      ...discuss them, how they can be mitigated and what impact they have.
      Sleeper Service
  • Why do companies not adopt security policies?

    Has anyone looked into why these security features are not implemented? Is there a compelling business reason for them not to implement?

    It is easy to babble on and cry out that people are not playing fair in the sandbox (pun intended) but it is another to find out what motivates companies to adopt or not adopt policies and find methods to develop consensus for implementation.

    I would much rather read a technical article that delineates the reasons why companies do not adopt security policies and what can be done about it.
    dl65
  • RE: Exploitation is Still Possible as Third-Parties Neglect to Implement Vista Security Features

    >> Vista has 12 major inbred security flaws.
    Only 12?

    >>How do you expect third party vendors to do >>Microsoft's work for them?
    I'm not. Third-party vendors are responsible for securing their own code. If there's a buffer overflow in product XYZ developed by company ABC, that's not Microsoft's problem to fix. What Microsoft has done is provide third-parties with capable protections that they can opt-in to use. If used effectively, these protections can prevent common issues from being exploitable, NOT from existing, but from being exploitable with current understanding.

    >>Microsoft is responsible for closing the >>exploits.

    Microsoft, like anybody else, is responsible for taking care of themselves. Careful that you don't confuse the line between Microsoft and the companies that develop applications for their operating system.

    -Nate
    nmcfeters
  • The biggest exploitation danger in Vista....

    Is from Microsoft, the RIAA, MPAA,
    and their ilk. Activation, WGA, and
    DRM, anyone? Spyware, Rootkit,
    Trojan, and Virus, too?
    Ole Man
    • RE: The biggest exploitation danger in Vista

      That is a pretty big blanket statement. Can you offer some specifics of how these are related to what Nate is talking about.

      I don't have any problem with what Nate is discussing, I just think there is more to the story. Why don't companies enact security features that are already available?
      dl65
  • RE: Exploitation is Still Possible as Third-Parties Neglect to Implement Vi

    Any built-in security is pointless if its use is not enforced by the OS itself. What is the point of having security built into the OS if its implementation is not mandatory? Shouldn't the OS be managing address space allocation and blocking execution of data addresses? The OS should have the capability of knowing what blocks of memory were allocated as program instructions versus data storage.
    JJQ1000
    • RE: JJQ1000

      >>Shouldn't the OS be managing address space >>allocation and blocking execution of data >>addresses? The OS should have the capability >>of knowing what blocks of memory were >>allocated as program instructions versus >>data storage.

      This is exactly what they are doing with DEP, but the prevention is not effective without ASLR. Also, you can't blanket use DEP on EVERYTHING. The reason is that some pieces of code (such as JIT code or compilers, etc.) need to make use of features that cannot work with DEP. If you look up the wiki page on DEP, there are some examples of this.

      The thing is, you have to keep in mind that Microsoft Windows is a platform for running applications, you can't just blanket implement something that will prevent certain applications from working.
      nmcfeters
  • RE: Exploitation is Still Possible as Third-Parties Neglect to Implement Vista Security Features

    If you have that information I'd be greatful if you'd share. Problem here is, companies aren't necessarily forthcoming about why they have or haven't done something in security. The key point is to show that they SHOULD be doing this. As Maynor mentions on his blog posting, his testing has showed that turning the appropriate bits on does not negatively affect most of the products that aren't using it.
    nmcfeters
  • And why is that?

    Vista blows chunks!
    mikifinaz1@...
    • RE: And why is that?...

      Wow, talk about completely and I mean COMPLETELY missing the point of the article. Vista does, in fact, NOT blow chunks. What I'm saying in this article is that Vista has made dramatic improvements to help protect third-party apps from allowing us to get pwned.

      At the end of the day, Vista cannot force opt-in to these applications, at least not with breaking some pretty important apps. Since the third-parties are not opting in consistently, the protections that Microsoft put into Vista are not being put to good use.

      So for those of you still struggling with who to point the finger at after reading this article:

      Third-party = bad
      Microsoft = good

      Again, this was a feature that Microsoft put in to help prevent a vulnerable third-party app from being exploited. It's the third-party developers who are chosing not to use it. We should be thanking Microsoft and complaining about the third-party apps not using these features.

      -Nate
      nmcfeters
  • It seems to me....

    when I look at how Microsoft does security on Windows and How the Unix/Linux world does security, that Microsoft builds ever more complex, and ultimately more fragile, mousetraps that eventually require lots of programming investment from anyone developing for Windows, while the Linux Unix world opts for simplicity and elegance, such that no extra effort is required of anyone developing for Unix/Linux.

    As a third party developer on both platforms my preference is most definitely Unix/Linux
    tracy anne
    • RE: It seems to me...

      The key is that these are two very different worlds. It's difficult to compare the security of each operating system directly as you are trying to complish.

      More importantly, the *Nix has similarly complex systems. Take a look at the linux grsecurity stuff.

      It's not really necessary to point the finger at one OS or another though, the point is that the third-party apps aren't using the security features available to them.
      nmcfeters
  • Let me get this straight

    DEP breaks certain kinds of applications because of the way
    DEP works, but it's the application's fault that it doesn't use
    DEP.
    frgough
    • You're perfectly correct

      and the coders at REALTEK are a prime example. They churn-out a new version of their High Definition Audio Drivers each week, most of which will not install without hardware DEP exceptions.
      Monsieur_Henri