Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Microsoft Safari Security IT

New Remote Flaw In 64-Bit Windows 7 284

Posted by samzenpus
from the hole-in-the-wall dept.
Trailrunner7 writes "Researchers are warning about a new remotely exploitable vulnerability in 64-bit Windows 7 that can be used by an attacker to run arbitrary code on a vulnerable machine. The bug was first reported a couple of days ago by an independent researcher and confirmed by Secunia. In a message on Twitter, a researcher named w3bd3vil said that he had found a method for exploiting the vulnerability by simply feeding an iframe with an overly large height to Safari. The exploit gives the attacker the ability to run arbitrary code on the victim's machine."
This discussion has been archived. No new comments can be posted.

New Remote Flaw In 64-Bit Windows 7

Comments Filter:
  • by elrous0 (869638) * on Wednesday December 21, 2011 @03:27PM (#38452580)

    Watch out!

    • by lgw (121541) on Wednesday December 21, 2011 @03:29PM (#38452596) Journal

      So, wait, is this a Win7 exploit or a Safari exploit?

      • by SirBitBucket (1292924) on Wednesday December 21, 2011 @03:31PM (#38452626)
        Sounds like it is an exploit of an issue with a windows component, but it is currently only known to be exploitable through Safari. Kind of like you could hotwire a car (windows) if you happen to have replaced your windows with Saran wrap (Safari), and can get right through them.
        • Re: (Score:3, Informative)

          by Moryath (553296)

          Sounds like it is an exploit of an issue with a windows component, but it is currently only known to be exploitable through Safari.

          If it's something only exploitable through Safari, then it's probably a Safari bug! Let's take a look at the original security advisory:

          The vulnerability is caused due to an error in win32k.sys and can be exploited to corrupt memory via e.g. a specially crafted web page containing an IFRAME with an overly large "height" attribute viewed using the Apple Safari browser.

          So, they bl

          • by Guy Harris (3803) <guy@alum.mit.edu> on Wednesday December 21, 2011 @04:08PM (#38453106)

            The vulnerability is caused due to an error in win32k.sys and can be exploited to corrupt memory via e.g. a specially crafted web page containing an IFRAME with an overly large "height" attribute viewed using the Apple Safari browser.

            So, they blame win32k.sys - but apparently the actual bug is that you can cause something resembling a buffer overflow by feeding Safari a ridiculously large bit of data as an iFrame.

            Could go either way.

            Should go both ways.

            Apple should fix the Safari bug so it doesn't mishandle IFRAMEs with "overly large" "height" attributes.

            Microsoft should fix the in-kernel graphics code so you can't use it to break into the system.

            • by cgenman (325138) on Wednesday December 21, 2011 @11:49PM (#38456542) Homepage

              Microsoft should fix the in-kernel graphics code so you can't use it to break into the system.

              As a game developer, I need graphics code to be low level, fast, and insecure. There are times I just need it to be a rocketship without handrails.

              If there is a way to secure it without sacrificing speed, that's great! But doing a great deal of error checking on that level? Leave me some insecure route to blitting billions of bits to the screen without guardrails please.

              • by Guy Harris (3803) <guy@alum.mit.edu> on Wednesday December 21, 2011 @11:58PM (#38456590)

                Microsoft should fix the in-kernel graphics code so you can't use it to break into the system.

                As a game developer, I need graphics code to be low level, fast, and insecure. There are times I just need it to be a rocketship without handrails.

                If there is a way to secure it without sacrificing speed, that's great! But doing a great deal of error checking on that level? Leave me some insecure route to blitting billions of bits to the screen without guardrails please.

                Sure, as long as 1) only the applications that absolutely positively need this do their graphics through that API and other apps can't even get at that API under any circumstances (so if the app has a bug nobody can inject code to enable it) and 2) applications that do can be marked as "DANGER DANGER WILL ROBINSON IF THIS APP HAS A BUG YOU MIGHT BE SERIOUSLY PWNED". There might be a tradeoff between your requirements and the requirements of security, and the best resolution for that tradeoff might not be in your favor....

          • by hairyfeet (841228) <bassbeast1968 AT gmail DOT com> on Wednesday December 21, 2011 @04:21PM (#38453250) Journal

            Well I'd be worried about Firefox as well, because the malware guys have figured out how to get around their XSS by using a hidden iFrame, which is why if you have any porn watching friends or relatives that use Yahoo Mail + FF you may have been getting spam from them lately. Don't know if it works on FF 9 and since I'm officially on vacation until the middle of next week I'm not gonna be loading a spare box with it and surfing porn vid sites to find out as I got a ton of games and a 6 core and intend to enjoy them! Just to be safe though be sure anybody you know with FF upgrades to the latest.

            Since we are on security allow me to say why I wouldn't consider either Safari OR Firefox a suitable browser for Widows 7: Lack of low rights mode. I bet the reason you aren't seeing this on IE nor on the Chromium based (Chrome, Chromium, Dragon, SWIron) is that they support the browser running in low rights mode and that is in fact their default behavior. Now considering that low rights mode has been around for nearly 5 years now there really is no excuse for a modern browser not to support it, especially when as we all know running with least permissions is just good security practice.

            So I would say if you are on Safari or Firefox or any other browser other than the Chromium based above look to see if your browser is running in low rights mode. If it is not switch browsers and be sure to drop the developers a line and tell them WHY you are switching away from their browser. It seems like doing the switch for the right reasons (increasing the user's security) will never happen so maybe if enough folks tell them "we won't use your browser because" then they will get off their asses and support this common sense feature.

            • by EdIII (1114411)

              I'm not gonna be loading a spare box with it and surfing porn vid sites

              Well you get right on that. Let us know how the security "research" turns out Wally.

          • by AC-x (735297) on Wednesday December 21, 2011 @06:31PM (#38454680)

            There are 2 exploits here, one is in Safari which allows someone to at least crash the machine, the other is in win32k.sys which allows a user space program to take over the kernel (privilege escalation bug)

            The win32k.sys bug is far more serious as it would give any program even run under a limited user account complete access to the system

          • by Hentes (2461350)

            If a program can get unlimited privileges then it's a bug in Windows. If Safari can do it, any piece of malware can too.

      • by kvvbassboy (2010962) on Wednesday December 21, 2011 @03:34PM (#38452678)

        Quote from Secunia advisory:

        A vulnerability has been discovered in Microsoft Windows, which can be exploited by malicious people to potentially compromise a user's system. The vulnerability is caused due to an error in win32k.sys and can be exploited to corrupt memory via e.g. a specially crafted web page containing an IFRAME with an overly large "height" attribute viewed using the Apple Safari browser. Successful exploitation may allow execution of arbitrary code with kernel-mode privileges

        Safari is apparently the only currently known browser where this attack could be vectored from.

        • by tgd (2822) on Wednesday December 21, 2011 @03:41PM (#38452768)

          64-bit windows requires no-execute on data pages (DEP), so there's no route you can cause data corruption and end up with executable code unless you have code running in the kernel to change the flags on the pages in memory.

          If this is a theoretical exploit, the authors of it may not be that familiar with 64-bit Windows 7, or are running on a developer machine they explicitly disabled DEP.

          • Re: (Score:2, Interesting)

            by lgw (121541)

            Well, there may be some Safari bug that allows an oversize iframe to be insterpreted as a script and interpreted, giving the place where the code can run, followed by some unrelated local priviledge escalation bug in Win7 for it to take advantage of.

            Heck, security advisories come in "tweets" now? We're supposed to guess the problem from the first 140 characters of explanation, I suppose.

          • by pclminion (145572) on Wednesday December 21, 2011 @04:03PM (#38453052)
            Modern exploit techniques provide multiple ways around DEP. Obviously DEP is something that should always be used if the hardware supports it (and the lack of support in older processors can in some sense be considered a design flaw) but it's no panacea against exploits. For example see return-to-libc attacks and the return-oriented programming techniques which generalize it. Even then, those techniques are based on stack smashing attacks, which are not the only kind of attack possible.
          • by Anonymous Coward on Wednesday December 21, 2011 @04:12PM (#38453158)

            DEP is regularly beaten. The key is called "return oriented programming" (http://en.wikipedia.org/wiki/Return-oriented_programming), essentially oldschool "return to libc" on speed. It's a lot of painful work, but that's what it takes these days.

          • by the_B0fh (208483)

            You are shitting me right? DEP can be trivially disabled - google for more information.

            I think you're drank too much koolaid, much like the Microsoft security guy who told us "Windows 2008R2 64 bit will not load unsigned drivers, and will check itself every 15 minutes and bluescreen if it finds one".

            Bull fucking shit - we found a very nasty little one that even Symantec couldn't find.

          • The problem is that DEP by default is not enabled on all applications. It's only enabled on apps that specifically request it. Safari/Firefox/Acrobat/Flash do not enable it fully.

            In order to do so, you need to change the DEP behavior to enable it for all programs except those specifically excluded. I did this when I installed Win7 and have had little to no issues with DEP except for a game written for Win95.

      • by MikeyO (99577) on Wednesday December 21, 2011 @03:34PM (#38452680) Homepage

        Perhaps both, definitely a bug in win7. If something the unprivileged safari process does crashes the kernel, we know there must be a bug in win7.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        FTFA:

        "A vulnerability has been discovered in MicrosWindows 7oft Windows, which can be exploited by malicious people to potentially compromise a user's system. The vulnerability is caused due to an error in win32k.sys and can be exploited to corrupt memory via e.g. a specially crafted web page containing an IFRAME with an overly large "height" attribute viewed using the Apple Safari browser. Successful exploitation may allow execution of arbitrary code with kernel-mode privileges," the Secunia advisory said.

      • by OverlordQ (264228) on Wednesday December 21, 2011 @03:39PM (#38452752) Journal

        The vulnerability is caused due to an error in win32k.sys and can be exploited to corrupt memory via e.g. a specially crafted web page containing an IFRAME with an overly large "height" attribute viewed using the Apple Safari browser.

        No matter what Safari does, it shouldn't cause a crash in win32k.sys, so I'd go with Windows error via Safari error since there's probably other vectors that can also cause a crash in the same place.

        • Re: (Score:2, Insightful)

          by icebike (68054) *

          It didn't cause a crash, it allowed the execution of arbitrary code, which is probably worse.

          We don't even know if the exploit occurred in the windows API, or some of the crapware that Safari drags along with it.
          None of the other WebKit browsers can cause the same exploit so it may well not be in the core of safari at all, but rather in one of the helper drivers that get installed when you install Safari and iTunes, like Bonjour or ipod helper processes. Some of those things can't be easily sandboxed becaus

          • by Dog-Cow (21281)

            Neither the iTunes Helper nor Bonjour are drivers.

            • Re: (Score:2, Insightful)

              by Anonymous Coward
              You're right, they're malware.
            • by Kalriath (849904)

              But they are services running with system privileges. That makes them almost as dangerous as drivers if they are poorly coded.

          • by Gutboy (587531)

            It didn't cause a crash, it allowed the execution of arbitrary code,

            No it didn't. Read the advisory again and note the part that says (emphasis mine)
            "... Successful exploitation may allow execution of arbitrary code with kernel-mode privileges"

      • by geekoid (135745)

        Any exploit that gives control to an unauthorized user so the can run arbitrary code is a OS exploit.

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          Depends on the context that that code runs in. If the arbitrary code is running under the same context as the app, then it's an app exploit. If the exploit is able to run something in an Administrator or kernel context, then that's an OS exploit.

    • Re: (Score:3, Interesting)

      by hAckz0r (989977)
      5 people? Unfortunately there are a LOT of people who have to run iTunes for their iPod/iPad/iPhone in order to get updates. Those updates usually try to install Safari along with the rest of the patches. Whether the user ever actually uses Safari is another question all together. I know I have not, but I often get tired of trying to unclick the selection boxes to not have it install every time there are updates. Most people will likely just give up and let Safari install even though it takes more download
      • by Culture20 (968837)

        there are a LOT of people who have to run iTunes for their iPod/iPad/iPhone in order to get updates. Those updates usually try to install Safari along with the rest of the patches.

        It actually installed Safari once without asking, IIRC.

  • by SirBitBucket (1292924) on Wednesday December 21, 2011 @03:28PM (#38452594)
    So far you must use Safari under Win7 64bit to exploit this. But we would never want to say anything bad about Apple, only about Microsoft...
    • TFA suggests it allows kernel privileges, so it is certainly a Windows exploit. But it may also be a Safari bug too, it depends whether or not the data it is passing to the Windows API calls that are causing the exploit would be considered reasonable or not.
      • by tgd (2822)

        TFA suggests it allows kernel privileges, so it is certainly a Windows exploit. But it may also be a Safari bug too, it depends whether or not the data it is passing to the Windows API calls that are causing the exploit would be considered reasonable or not.

        I wouldn't make that blanket assumption -- Apple installs a MASSIVE amount of crap into the system. A kernel exploit in Windows code is NOT the same as a kernel exploit in Apple code. A service, a device driver, a process running with admin rights without appropriate protections from user-space could all be a vector for a kernel exploit.

        • by geekoid (135745)

          If the OS allows Safari to run any arbitrary code, or ANY software for that matter, then there is an OS problem.

          Should Safari accept overlarge iFrame? no. That is also the problem.

          Since Window is used far more then safari, and is a core componant of many systems, then putting it as a MS exploit is the responsible thing to do.

      • Addendum: <iframe height='18082563'></iframe> causes a BSoD by the Windows kernel so it is certainly a Windows bug. It would be trivial of Apple to hotfix it to prevent exploitation via Safari but any other application could theoretically exploit it and elevate their code. Of course it doesn't appear anyone else has actually gotten it to execute arbitrary code yet, despite the summary claim...

        • Re: (Score:2, Informative)

          by tgd (2822)

          Addendum: <iframe height='18082563'></iframe> causes a BSoD by the Windows kernel so it is certainly a Windows bug. It would be trivial of Apple to hotfix it to prevent exploitation via Safari but any other application could theoretically exploit it and elevate their code. Of course it doesn't appear anyone else has actually gotten it to execute arbitrary code yet, despite the summary claim...

          And likely won't -- Win7 64-bit requires DEP, so you can't corrupt a data page and end up executing code unless there's a defect in the CPU *or* you have code in the kernel to change the page type. And if you have code already in the kernel, you don't really need an exploit.

          Its also not clear from the article if its corrupting kernel memory, or corrupting user memory. The driver crashing doesn't necessarily imply data in kernel space was corrupted, it just means the driver crashed for some reason.

          • by geekoid (135745)

            because DEP is bug free?

          • by cbhacking (979169)

            Ugh... man, I hate to break it to you, but your "understanding" of the security technologies is *way* off.

            First, DEP is trivial to bypass. Go research "return-oriented programming" and you'll find not only working exploits but even entire toolchains that can compile an arbitrary C program into a return-oriented stack that executes by controlling the program counter and stack frame (including local variables) to make a binary execute completely different instructions. (The mitigation here is ASLR, which has

        • *grumble grumble*

          Of course it does. It's part of MS's plan to bring the "bang" back into C++. All this nonsense about buffer overflows and what not, that's just the managed code people trying to keep good programmers from realizing the speed and efficiency of a good, tightly written C++ program, which can compromise your machine in 10 seconds flat.

          I have frequent, unkind thoughts for a company that scuttled a good migration to a nicer programming experience.

          How about, instead of Windows 8, you finish the co

      • by icebike (68054) *

        It seems unlikely this was found by accident, more likely by someone knowing about how the iframe would
        be handled in windows and designing something purpose made to break that.

        Not knowing how Safari is interfacing with windows, I can't guess if this is a problem in a windows API call or some tool-set used only by Safari. If none of the other Webkit browsers can trigger this bug it would seem more likely to be some safari specific middleware.

        All 6 people using Safari on Win7 64bit should definitely avoid al

        • 7 people.

          I've been working on a (God help me) PHP implementation of a CalDav client for Davical, and Safari is one of the five or so browsers I've been testing it on.

      • by rabbit994 (686936) on Wednesday December 21, 2011 @03:46PM (#38452840)

        The only confirmed anything I've seen is someone can BSOD the computer. Which while a bug, not Remote Code Execute, just Denial of Service attack.

        Since this problem only exists in Safari, either Chrome/IE/Firefox are sanitizing those inputs to prevent that from reaching Windows kernel.

        Furthermore, since this x64 bug only, my guess is this issue was patched in 32 but for some reason, WOW64 isn't seeing it or catching it.

    • by Baloroth (2370816) on Wednesday December 21, 2011 @03:35PM (#38452698)

      The flaw seems to be in a call to a Windows API.

      It is possible to trigger a memory error in the system file win32k.sys by accessing a crafted HTML file in Safari....According to webDEViL, the source of the vulnerability is the function NtGdiDrawStream.

      So it is possible other programs could be affected. It is also possible that Safari itself handles the function in a broken manner. Note that Firefox appears to also have crashes related to that function (on x86 Windows, though, it's like the second Google result for that function). So, really impossible to say at this point. Also, they could only cause Windows to crash, not to run arbitrary code or anything. So far anyways.

      • Accidental funny mod.
      • The prototype for the NtGdiDrawStream is as such:

        BOOL NtGdiDrawStream(IN HDC hdcDst, IN ULONG cjIn, IN VOID* pvI);
        So, simply speculating, this may be something like a ULONG going in, but it gets cast to a signed integer.
    • You must be new here if you think no-one says anything bad about Apple.

  • by mrflash818 (226638) on Wednesday December 21, 2011 @03:29PM (#38452608) Homepage Journal

    20 December 2011, 13:21
    Highly critical zero day vulnerability in Windows discovered

    http://www.h-online.com/security/news/item/Highly-critical-zero-day-vulnerability-in-Windows-discovered-1398625.html [h-online.com]

  • Wait... (Score:5, Funny)

    by SJHillman (1966756) on Wednesday December 21, 2011 @03:31PM (#38452628)
    Safari runs on Windows? Any time I've tried running Apple software (iTunes, Safari, Quicktime) on Windows, it just takes forever to load, wants to spend all day updating, chews up my memory and craps on my processor. If someone is running Safari on Windows intentionally then they might be masochistic enough to welcome this 'feature'
    • by geekoid (135745)

      I think you should have an actually professional look at your machine.
      I run iTunes without any [problem on window7, x64. I also ran Safari for a while to check it out. It wasn't as good as Chrome so I ditched it.

      And there is nothing special about the box I run them on.

  • by whatthef*ck (215929) on Wednesday December 21, 2011 @03:31PM (#38452636) Homepage

    Shouldn't the posting have the Apple graphic instead of Microsoft?

  • by sqlrob (173498) on Wednesday December 21, 2011 @03:35PM (#38452690)

    Remote to me means "it's connected, you're vulnerable". This requires the user to take an action, getting some local data. From the description, you could have the same files on the file system and it would work.

    Bad? Yeah. But not "plug it in, computer is pwned" bad.

  • by forkfail (228161) on Wednesday December 21, 2011 @04:04PM (#38453066)

    (check one)

    [ ] Microsoft products are far less secure than Apple. Because everyone knows that Safari is completely safe always on Apple machines, and only fails on Windows.

    [ ] Apple products are far less secure than Microsoft. Because obviously the hole in Microsoft security here is introduced through an Apple product, and really doesn't occur otherwise.

    [ ] If people were just running Linux, they wouldn't be having these problems.

    [ ] This is gonna be good. Ima gettin' my popcorn now!

  • It used to be that if my Mac crashed, I was in an MS program (word, powerpoint, IE back in the day) ... and now the roles have reversed.

  • by Fred Or Alive (738779) on Wednesday December 21, 2011 @04:46PM (#38453602)

    After a bit bit of playing "let's intentionally crash Windows", it seems that using the Windows Classic skin fixes the bug, and the page renders fine (if a little uninteresting, it's basically a long page with a box on it). It BSODs on Windows Basic and Aero. I haven't a clue if this is a real fix, or if it's just that the magic number needed to crash the system is different with Windows Classic compared with Basic / Aero. Windows XP (32 bit) is fine as well (again page renders fine, no crashes of anything).

    I personally think it's largely a Windows bug, even if Safari has a bug (that oddly only does anything on one version of Windows, and even then only with certain conditions), a programme doing something stupid should not crash the entire OS.

  • by anonymov (1768712) on Wednesday December 21, 2011 @05:07PM (#38453856)

    For now it's unclear how bad is this, as the only concrete detail is Secunia's link to "original advisory" [twitter.com]

    From digging around bug submitter's twitter [twitter.com]:

    @igursev @therealsaumil not really an integer overflow. Otherwise 18082564 would have also worked ;-)
    4 hours ago

    w3bd3vil webDEViL @
    @igursev It probably is, but not theoretically. In simpler terms, I can't build an exploit for it.
    12 hours ago

    @kernelpool yeah I tried with some help to get code execution but was beyond me...
    19 Dec

    @r3dsm0k3 Yeah. It's the NtGdiDrawStream which is being called multiple times...leading to a not so interesting crash.
    18 Dec

    <iframe height='18082563'></iframe> causes a BSoD on win 7 x64 via Safari. Lol!
    18 Dec

    So a) there's a bug in win32k.sys, tickled by Safari's (allegedly) incorrect API usage, so there's possibility of other exploits, b) "may lead to arbitrary code execution" means "we don't know yet, but we're playing safe", the only confirmed effect is BSoD by memory corruption.

    Why the fuck there's so little about it, did nobody research yet what kind of memory corruption it actually does? The tweet's from 4 days ago, FFS.

  • Has anyone done any proper debugging on this? NtGdiDrawStream doesn't look like public API... I can't find any reference to it in msdn. Does Safari access this function directly or indirectly through another public API? If they are directly calling an undocumented API then shame on Apple (especially so considering their response to iphone app authors use of undocument API). If it is public then shame on MS.
    • The Nt prefix seem to indicate it's part of Windows' Native (kernel) API. It isn't that well documented. Safari is probably going via the public Win32 API, which calls the Native API when kernel services are needed. It's a bit (kinda, sorta) like on Linux where a user programme won't usually directly call the kernel, but libc will call it when needed.

      • Since noone has published a stack frame dump or anything to draw the line between the OS and the application you can't really tell where the problem lies
        • by yuhong (1378501)

          FYI I remember debugging a crashdump from this BSoD, and Safari was calling uxtheme which in turn calls this function that causes the BSoD.

Are you having fun yet?

Working...