Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Operating Systems Software Windows

Defeating XP SP2 Heap Protection 242

hobo2k writes "XP SP2 included canary values and hardware-implemented execution protection in order to avoid exploitable buffer overruns. Now Positive Technologies has released an article describing one way that protection could be bypassed. To solve the problem, they provide a program which disables the small allocation heap as described here. CNET reports that SP2 has been foiled."
This discussion has been archived. No new comments can be posted.

Defeating XP SP2 Heap Protection

Comments Filter:
  • by numike ( 726251 ) on Saturday January 29, 2005 @07:59PM (#11516501)
    firefox
  • by Rosco P. Coltrane ( 209368 ) on Saturday January 29, 2005 @08:01PM (#11516523)
    Now Positive Technologies has released an article describing one way that protection could be bypassed.

    A security problem in Windows? no way...
  • SP2 what? (Score:2, Funny)

    by warderz ( 839772 )
    Protection? What protection?
    • by A beautiful mind ( 821714 ) on Saturday January 29, 2005 @08:03PM (#11516532)
      it's like putting on a second condom AFTER sex when the first one proved to be leaking.
      • by ozbird ( 127571 ) on Saturday January 29, 2005 @08:26PM (#11516698)
        To take the analogy further, does that make Linux the morning-after pill?
        • by Anonymous Coward
          > > it's like putting on a second condom AFTER sex when the first one proved to be leaking.

          > To take the analogy further, does that make Linux the morning-after pill?

          No. Linux is like masturbation. And BSD is like necrophilia.
        • by wxjones ( 721556 )
          Actually, running Linux is like wearing a plaid hat with earflaps. Best birth control known to man! Come to think of it, its Saturday night and I'm posting on slashdot...using Linux. At least my ears are warm.
        • Yeah, so sorry about the AIDS you already contracted.

          Remember: the only safe computing is NO COMPUTING. If you feel like you have to use a computer, then staying off-line is the only sure way to stay disease-free. There's nothing shameful about it; you'll not go blind.

          Now, since I know you kids are going to want to play your Counter Strike anyway, it's best to make sure you only game with people you already know and trust. Don't deathmatch with that hussy you found at the airport bar, and never accept
      • "it's like putting on a second condom AFTER sex when the first one proved to be leaking."

        Oh....

        Er.. could we use metaphors that most of us could wrap our minds around?
  • by agent dero ( 680753 ) on Saturday January 29, 2005 @08:03PM (#11516537) Homepage
    C'mon, this has been known for a while ;)
  • NX bit? (Score:3, Interesting)

    by Anonymous Coward on Saturday January 29, 2005 @08:07PM (#11516570)
    I read the .PDF pretty carefully, but I still don't understand how DEP (data execution protection via the NX bit in the page tables) fails to prevent this exploit. The 1016 bytes of memory is on the heap, isn't it? So how is any code you put there going to be executed?
    • Re:NX bit? (Score:3, Insightful)

      by Anonymous Coward
      The program disables the small allocation heap (meaning that the 1016 bytes of exploit code would be loaded into some other heap), which leads me to believe that perhaps the NX bit was only set for the small allocation heap pages. This will probably get fixed pretty quickly.
      • Fixed Quickly? (Score:4, Interesting)

        by EventHorizon ( 41772 ) on Saturday January 29, 2005 @08:40PM (#11516782)
        The patch may be quick. It will still take a long time to deploy.

        Anyway you have to wonder about this kind of technical oversight. If you are implementing an NX heap, you obviously need to NX the WHOLE heap for it to be useful.

        Basically it looks like Microsoft is incapable of secure development at the core OS layer. I find that absolutely mind boggling given their resources.
        • Re:Fixed Quickly? (Score:3, Insightful)

          by peasleer ( 806038 )
          Don't make it sound like Linux is problem free either. Just this morning, *11* Linux kernel vulnerabilities were posted to security focus. Yes, the number of vulnerabilities in Linux have historically been fewer in number, but no operating system is perfect. Windows does what it does well: Providing a stable (yes, XP is stable,) operating environment for beginning to advanced users.
          • Re:Fixed Quickly? (Score:3, Insightful)

            by TelJanin ( 784836 )
            And how long will it take to fix the Linux problems, compared to the Windows problem descibed in the article?

            Linux way of fixing things:
            1) Discover there is a problem
            2) Send a patch to kernel maintainers
            3) Kernel is patched

            Windows way of fixing things:
            1) Discover problem
            2) Tell Microsoft
            3) Two months later, when Microsoft has done nothing, tell the world
            4) Get possibly sued by Microsoft (if MS can to a Russian company)
            5) After several viruses have exploited the vulnerability, Microsoft makes a patch that
        • Re:Fixed Quickly? (Score:3, Insightful)

          by Zeinfeld ( 263942 )
          Thanks to the abortion thread, this is the first comment that actually addresses the real issue.

          The patch may be quick. It will still take a long time to deploy.

          No, Windows has had automatic update for years now. Every machine I have is fully current with patches.

          What would be the proportion of Linux systems running with heap protection?

        • (...putting on my tinfoil hat...)

          Why wouldn't Microsoft parlay vulnerabilities
          in their core OS (and the long delays in their
          providing patches) into a big push to adopt
          their "Trusted Computing" initiative?

          With DRM in BIOS, and no ability to use any
          OS, application, or media file not explicitly
          approved by Microsoft, any/all of MSFT s/w
          vulnerabilities become a moot point. They will
          have no legal or moral compulsion to fix any
          of their s/w vulnerabilities, as all security
          concerns (and responsibility) will be pa
    • Re:NX bit? (Score:5, Informative)

      by YU Nicks NE Way ( 129084 ) on Saturday January 29, 2005 @08:32PM (#11516735)
      The article description is a bit deceptive. NX is independent of DEP here. The alleged exploit only works for the small heap on machines without NX, not for machines with NX. NX stops this exploit cold.
      • by js7a ( 579872 ) <james AT bovik DOT org> on Saturday January 29, 2005 @08:41PM (#11516786) Homepage Journal
        I don't think Windows users should lose too much sleep over this. How is an exploit supposed to unprotect the heap segment in order to execute the buffer overrun code -- before such code has been executed?
      • Re:NX bit? (Score:3, Insightful)

        by Deathlizard ( 115856 )
        I agree. After reading the PDF, it seems that they were focusing on the software DEP system rather then the hardware (NX) DEP.

        For those not in the know, XPSP2 has two forms of DEP. Hardware and Software. If your Processor supports it, WinXP uses Hardware DEP in the form of the NX bit to protect your PC. If the NX bit is not available on your CPU (Most CPU's fall under this category) then it defaultes to the Software DEP, or "sandboxing" as they put it.

        If anyone wants to try and exploit this on an NX capab
      • Re:NX bit? (Score:3, Informative)

        by hobo2k ( 626482 )
        I don't have the hardware to actually test it, but I believe the 2nd code sample is supposed to deal with NX. The stack/heap never get executed. Instead it modifies the stack such that when the function returns the C library function 'system' is called with an arbitrary command line to execute.
  • Netcraft confirms it, it's official
  • Slightly unrelated: What about NX under Linux on the amd64 architecture. Anyone know if/when it is supported?
  • Is that link that says 'here' to microsoft.com correct? It points to something for Windows NT4.0 w/SP4
    • by DarkMantle ( 784415 ) on Saturday January 29, 2005 @08:14PM (#11516625) Homepage
      You expect the links and the article to be related?

      You expect too much from the editors.
    • The website offers the program PTmsHORP, but the I found description of it to be cryptic:

      allows restriction of lookaside list creation, governed by a special global flag.

      Using regmon and filemon, I found that PTmsHORP simply modifies the DisableHeapLookaside registry value. That old KB article was the most authoritative source I could find which describes what that registry setting does.

      Also I found it interesting that a performance improvement made back in the NT4.0 days, which at the time caused so

  • This is way wrong. (Score:5, Interesting)

    by A beautiful mind ( 821714 ) on Saturday January 29, 2005 @08:11PM (#11516596)
    "Published 28th January 2005."

    And

    "In October 2004 it was discovered by MaxPatrol team that it is possible to defeat Microsoft® Windows® XP SP2 Heap protection and Data Execution Prevention mechanism."

    This is too much time to fix something. I can agree with some delayed disclosure but not anything above a month.
    • by jschottm ( 317343 ) on Saturday January 29, 2005 @08:35PM (#11516755)
      This is too much time to fix something. I can agree with some delayed disclosure but not anything above a month.

      The CNET article states that they didn't report it to Microsoft until Dec 22. Which is close enough to the holidays that a substantial part of many businesses staff are out until the 1st of Jan.

      Anything that modifies core memory access/rights such as this needs extensive testing. It's most likely an easy fix, but you should be well aware of the outrage that would occur if they released a fix that ended up breaking things. Recall the rushed fix to OpenSSH that was distributed only to be replaced days later with a proper fix, leading to all manner of confusion as to which versions were vulnerable and not?

      Given that this is a relatively minor problem - the attacker would have to have another sucessful attack vector to be able to use this, I'm glad Microsoft is [theoretically] taking the time to do this right. If you're really that worried about it, you can run the software provided by a mostly unknown Russian company that they freely admit will affect the system negatively. And pray that there's no bugs in their code and that it's not malicious...
      • Still the question surfaces, why did the people who discovered the flaw sit on the vulnerability for two months without notifying security@microsoft.com? Well, either this or they DID notify Microsoft way before dec 22 which Microsoft fails to mention. MS did this before( put the notified date to a later time) to doctor their statistics before and get more time. I don't trust neither companies tbh.
      • Anything that modifies core memory access/rights such as this needs extensive testing. It's most likely an easy fix, but you should be well aware of the outrage that would occur if they released a fix that ended up breaking things.

        Sure, that's why if anything breaks Linux kernel memory protection it takes at least a month for Linux developers to release a fix. Oh wait, it doesn't.
        • A better comparison would be the length of time it takes for the fix to make it into, e.g., the mainline Red Hat release. I don't know how long that usually is, but the reality is that testing takes time, so if Red Hat do extensive testing before releasing patches, there will be a significant gap.

          No there won't. Security fixes are fast tracked and available here [redhat.com] essentially on the same time frame as patch releases to the general public.
  • In hardware? (Score:1, Interesting)

    by MrLint ( 519792 )
    Is it just me or is relying on hardware to protect your application heaps seem to be a bad idea. Not just because its non-portable (not that this matters for windows) but it basically offloads the work on HW that may or may not be up to the task.

    We know that unix, its variants and progeny, have memory protection. How many of these rely on the hardware to protect them? Certainly 'legacy' *nixes didnt run on HW that had these features.

    I guess what im saying is i dont like it as a long term strategy.
    • Didn't the Alphas have NX? Or was that something else...something did I think.
    • Re:In hardware? (Score:5, Informative)

      by Anonymous Coward on Saturday January 29, 2005 @08:21PM (#11516665)
      How many of these rely on the hardware to protect them?

      Ummm... all of them?

      Memory protection requires hardware support to work, and every version of UNIX, Linux, NT (right from the beginning) and Win9x all use hardware support to implement memory protection.

      It seems that you have hardware memory protection mixed up with the NX (no execute) bit. All that the NX bit does is nothing more than mark memory allocated on the heap as non executable. The application is completely free to allocate executable memory, just that a normal malloc() does not cut it for this purpose.

      This is a very good feature. The reason is that 99.99% of apps never need to execute code created on the heap. The only exceptions are things that JIT code like the Java VM.

      Many buffer overruns that result in exploits rely on heap memory being executable. By requiring a very small set of programs to be fixed, you can eliminate a whole type of security flaw. Is it the be all and end all? No its not. But it sure helps.

      • Win9x uses HW memory protection? [everything2.com]
      • Many buffer overruns that result in exploits rely on heap memory being executable. By requiring a very small set of programs to be fixed, you can eliminate a whole type of security flaw. Is it the be all and end all? No its not. But it sure helps.

        Not as simple as that.

        YOu don't eliminate a whole class of attacks, you just make them harder. An attacker may still be able to subvert a program using a buffer overrun, but this requires a better knowledge of the heap structure surrounding the buffer and it re
      • Um. you don't need hardware [grsecurity.net]. And java JIT does not need an executable heap [google.com], as I've shown. Realtime emulators like Qemu and VMWare need one. You need to add good, high-entropy ASLR to NX to seal it, otherwise it's evadable.
    • Even the first PDP-11 to run Unix had a form of hardware memory protection (basically segmented memory, a program was incapable of addressing other than the 64K assigned to it). There is no way for the most carefully written Unix kernel to prevent an arbitrary program from writing all over memory unless there is hardware to prevent it.

      It appears most of the problem is the lack of this NX bit on Intel processors. If it had been there initially both Windows and Linux would be using it and nobody would think
  • by TeeJS ( 618313 ) on Saturday January 29, 2005 @08:12PM (#11516601) Homepage
    that it's easier to bypass a patch over a hole, than get through a barrier that was built solidly from the beginning. I have a mental image of a steel door with a big piece of cardboard taped to it....

    • Taking your analogy to its extreme, it seems like you're suggesting rewriting the entire piece of software every time a bug is found.

      I think I'd prefer a different analogy.

      It's much harder to get through a barrier that's been tested and reinforced appropriately than one that's never been tried out - no matter what the skill is of the person who constructed it.

      Software has bugs. Software gets fixed. Software is stronger for it. This is true of Windows, Linux, OpenSSL, and any other piece of software you c
      • Hmmm...IMHO the software cycle goes more like: software has bugs. Software gets patched. Software gets fixed and lots more features added in the next version. Software has more bugs....

        Generally software does not get stronger. People keep adding (more code) to it before it can get there.

        And yes, I'm talking about all software here, not just MS.
      • When a serious bug is found that affects the whole design - the best solution is to do a redesign and rewrite.

        Every expert programmer knows that. Those that write agile software are highly aware of that.

        Sadly companies often wants to get a fast fix out and that fix very seldom are 100% correct.

        • by ZorbaTHut ( 126196 ) on Saturday January 29, 2005 @09:51PM (#11517123) Homepage
          I disagree. Refactoring sounds like a much better solution. And I highly doubt this is a serious bug that affects the whole design - why would the introduction of a new CPU flag require the complete reconstruction of an entire OS kernel? Or more?

          I don't see how you could possibly suggest a full redesign and rewrite and then, in the same post, complain that fast fixes are rarely 100% correct. As if the rewrite won't be a thousand times worse!
        • Well that's fine if people who really know what they are doing do the redesign and rewrite.

          If it's the same people who didn't spot the serious bug that affects the _whole_ design, the odds are much worse that starting again would actually help much.

          Ask a crappy team to redesign and rewrite and they'll just come up with more crap. Let's be nice and say the team is good only the politics/process is broken, whatever, you still end up with more crap.

          So far the evidence is that more often than not the same pe
    • I have a mental image of a steel door with a big piece of cardboard taped to it....

      Are you saying that taping a piece of cardboard to a steel door makes it easy to bypass? Wow, I'm gonna get me to a bank...

  • I've never though of why my Windows with *all* patches and a positive Microsoft Windows Baseline Security Analyzer check doesn't produce those annoying "are you sure" questions. Can't say that I miss them though because I know my system is up to date :)
  • I wonder.... (Score:4, Insightful)

    by futuresheep ( 531366 ) on Saturday January 29, 2005 @08:14PM (#11516620) Journal
    I wonder what Nick McGrath's [slashdot.org] opinion on this is, and who is HE holding accountable?
  • And yet (Score:3, Funny)

    by HackNack ( 853020 ) <jas@nOspAm.emilswenson.com> on Saturday January 29, 2005 @08:23PM (#11516681) Homepage
    When asked about the problem Steve Ballmer said that Linux sucks.
  • foiled? (Score:4, Funny)

    by gardyloo ( 512791 ) on Saturday January 29, 2005 @08:24PM (#11516684)
    CNET reports that SP2 has been foiled.

    Shouldn't that read tin-foiled? C'mon, slashdot, standards?
  • by auzy ( 680819 ) on Saturday January 29, 2005 @08:42PM (#11516798)
    This is probably a good thing, because it proves that even with stackguarding, etc.. Treating your system as if they dont exist is the best thing you can do. Microsoft unfortunately chooses to use stackguarding as a first line of defence to allow them to take their time patching software, which is a terrible idea.

    So basically, nothing has changed in the security world in the past year. The only thing is that the attitude of programmers have in some cases, become slacker because of technologies like this, believing they can get away with it now.

    If you ask me though personally, I'm betting Microsoft didn't run major tests on the security of DEP anyway, only simpler ones
  • by bluefoxlucid ( 723572 ) on Saturday January 29, 2005 @08:50PM (#11516839) Homepage Journal

    I did blog on another way using only a stack overflow on my blog [blogspot.com]. My way was more "all existing exploits work as-is after just a little extra step" than "exploits still exist that get around DEP" though.

    My way was to just slap DEP in the face by using a ret2libc with a constructed stack frame that gave the shellcode a nice, clean, executable area of memory to execute in, then copied the memory there, then returned to it. This is done by 1) Return to VirtualAlloc(), 2) Return to memcpy(), 3) return to shellcode.

    They noticed this in October; it took me until January and I'm not a security expert.

  • For the geeks... (Score:4, Interesting)

    by Jugalator ( 259273 ) on Saturday January 29, 2005 @08:55PM (#11516858) Journal
    ... the juicy bits are here [maxpatrol.com]. Scroll down to the bottom for the appendices where there are C code examples on how to bypass these measures.
  • by cvd6262 ( 180823 ) on Saturday January 29, 2005 @08:59PM (#11516880)
    Since MS claims Linux companies can't be held responsible for Linux security, will MS claim responsibility for this?
  • Err... Anyone else notice something funny here?

    During the first execution this program shows the list of applications which already have this flag set.

    I have DEP set to protect "essential Windows programs and services only"...

    Yet, running this util, the list of programs looks nothing like a list of "essential" Windows programs. In fact, I honestly don't recognize any of the programs listed, and I say that as someone that knows what a normal Windows XP SP2 install "should" have running, even down to
  • What the shit? (Score:2, Interesting)

    by Anonymous Coward
    Okay, so in order to disable the heap protection either the user has to execute arbitrary code while running under the context of a user with sufficient permissions, or be enticed to follow a fairly obscure set of instructions to edit the registry.

    How the shit is this a vulnerability exactly? The only way to exploit it is to have already 0wned the machine so there would be no need to disable memory protection at any scope.

    Also, as mentioned, this doesn't work correctly on hardware that supports NX. Ther
  • The method of attack for most stack buffer-overflows is to write enough data into a stack-allocated object to clobber the return pointer, which is allocated above it.

    So why not make the stack grow upwards instead of downwards?
    • This decision was made long ago, when there was only a single address space and it was convenient to have the program at a fixed address at the beginning of memory, and the stack fixed at the end.

      The "stack grows down" has been embedded in the hardware design and now it cannot be changed easily.
  • Microsoft and the hackers are just playing CoreWars [sourceforge.net], for real, on our systems. Isn't that great?

    In fact, Windows XP's heap boundary checking sounds like little more than the old RADAR-X [ociw.edu] REDCODE program...

  • A better way to defeat this class of attack is to move the metadata (in this case the link table) elsewhere to another, noncontiguous page. You could still induce a buffer overflow, but such an overflow would not corrupt the whole allocation mechanism.

    For extra security you could put it in kernel space and give the library a new system call to do memory allocation, but that would increase memory allocation overhead, likely unacceptably.

    Analysis and solution depend heavily on what attack you wish to defen

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...