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

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 Synerg1y ( 2169962 ) on Wednesday December 21, 2011 @04:31PM (#38452632)

    An iframe is interpreted by the safari browser which has trust obviously (it's an .exe), so it's a safari vulnerability, article is mislabeled, or author never took sec 101.

    Also 5 users is very generous, I have yet to see one, and I've seen my share. Most web developers make their salt without ever having to test on this browser for example.

  • by Baloroth ( 2370816 ) on Wednesday December 21, 2011 @04: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.

  • by hAckz0r ( 989977 ) on Wednesday December 21, 2011 @04:37PM (#38452726)
    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 time. So, I bet its at least 6 people.
  • by tgd ( 2822 ) on Wednesday December 21, 2011 @04: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.

  • by rabbit994 ( 686936 ) on Wednesday December 21, 2011 @04: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 lgw ( 121541 ) on Wednesday December 21, 2011 @04:55PM (#38452966) Journal

    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.

  • Really? (Score:1, Interesting)

    by Nicros ( 531081 ) on Wednesday December 21, 2011 @05:03PM (#38453040)
    For some reason I have a false sense of security now- if this is the kind of 'exploit' that gets reported and /.ed and that I need to worry about, life is good! I mean really- you have to have Win7 x64, with Safari AND then navigate to a site that serves up a bogus iframe height, AND uses the exploit to make bad on your machine. I can't imagine this affects too many people. Also, why is this a 'Windows Remote' exploit? Safari would seem to not handle the iframe exception, whereas IE, Firefox, Chrome, Opera DO? If this were a true windows exploit I would expect it to occur regardless of the browser. And what other kind of exploit (as it's defined ITA) is there besides a remote one? A local exploit, where someone turns off my machine? I read 'remote' and think RDP... which is not the case here at all.
  • by 0123456 ( 636235 ) on Wednesday December 21, 2011 @05:33PM (#38453420)

    So yes, this is a windows bug. But it is also a safari bug. Both should be fixed.

    So how does Safari know whether Windows can support an 18 million pixel high window without requesting one? If it's a valid value for the request, then an application should be able to assume that the OS will either fulfil the request or return an error, not execute arbitrary code.

  • by Fred Or Alive ( 738779 ) on Wednesday December 21, 2011 @05: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 cgenman ( 325138 ) on Thursday December 22, 2011 @12:49AM (#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.

If you have a procedure with 10 parameters, you probably missed some.

Working...