Slashdot Mirror
New Remote Flaw In 64-Bit Windows 7
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."
Watch out!
SJW: Someone who has run out of real oppression, and has to fake it.
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...
http://www.h-online.com/security/news/item/Highly-critical-zero-day-vulnerability-in-Windows-discovered-1398625.html
Uh, Linux geek since 1999.
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'
Shouldn't the posting have the Apple graphic instead of 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.
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.
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.
"None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
just wow.. an iframe causes an attacker to get system level access.. wow again.
Wrong - it's a MS bug in windows, it's just that they triggered it through Safari. A bit like saving saving a file in safari causing the machine to explode - not really Safari's fault.
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.
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...
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 all 3 sites on the internet that might have deployed this exploit.
Sig Battery depleted. Reverting to safe mode.
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.
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.
Safari is the only attack vector. This by definition is not a remote flaw as it requires you to do something to exploit a web browser, thus it is a 'local exploit'.
The web page can be remote, and can presumably gain control. You, the user, need do nothing but click a link, and might possibly be unaware that anything had happened.
Letting someone talk you into installing Safari also constitutes a Social Engineering exploit. So you might be right after all.
Sig Battery depleted. Reverting to safe mode.
This is Microsoft buggy code causing issue, Safari problem is merely one way to cause rooting of machine, other softwares using this service will undoubtedly provide more cases.
a) Yes, this is a bug in Windows. No question. Windows isn't validating the input, and should just reject it or throw an exeption or whatever. Crashing is not acceptable and represents a bug in windows.
b) This is also a bug in safari. Safari is not validating its input either. Its just blindly passing a request to create an 18million pixel tall iframe down to the Windows API somewhere...
c) Yes, other softwares will likely be found. But so far only safari is known to be in the unique position of using that API, passing it arbitrary remote content while failing to validate its input.
A bit of malicious code that explicitly does use that API actually has to get onto the local system first. Local exploits are much less serious than remote ones.
So yes, this is a windows bug. But it is also a safari bug. Both should be fixed.
Missing the point. Point is that userland code (and the example uses Safari but what should it matter *what* program activates it - it shouldn't be possible and can probably be easily activated by any sort of direct code) creates a BSOD in Windows.
That shouldn't happen - that's the whole point of an OS.
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.
They just didn't as the right questions:
1) Does it affect other WebKit browsers (especially Chrome) as well?
2) If not, why should we give a shit?
Accidental funny mod.
(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!
Check your premises.
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.
Build it, and they will come^Hplain.
This is a common misconception on the use of DEP. DEP is a mitigation, not a solution.
There are dozens of ways to get around DEP protection. It helps sometime, but not when you execute already existing (and useful) code inside the kernel/app.
Well there's the problem!
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.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
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.
The Kruger Dunning explains most post on
1) Does it affect other WebKit browsers (especially Chrome) as well?
I am pondering this too.
because DEP is bug free?
The Kruger Dunning explains most post on
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.
Did you have more than 4GB of RAM on this system before you installed 64-bit Windows? I was running with 6GB of RAM and seeing all sorts of crashes and nasties in 64-bit Linux, but nothing untoward in Windows. It turned out I had memory errors in the upper regions where 32-bit Windows could not reach.
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.
10 PRINT "LOOK AROUND YOU ";
20 GOTO 10
So its microsofts fault that nvidia and creative wrote buggy drivers?
Letting someone talk you into installing Safari also constitutes a Social Engineering exploit. So you might be right after all.
Apple attempts this "exploit" every time someone installs or updates iTunes for Windows.
You insensitive clod.
Imagination drew in bold strokes, instantly serving hopes and fears, while knowledge advanced by slow increments...
For now it's unclear how bad is this, as the only concrete detail is Secunia's link to "original advisory"
From digging around bug submitter's twitter:
@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.
Because DEP induces morons to believe they're now secure and protected forever.
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.
Judging from your post and your sig, I'm gonna say you really shouldn't talk to yourself in the mirror like that, it's not healthy.
Which is it?
So how does Safari know whether Windows can support an 18 million pixel high window without requesting one?
Safari knows what the screen resolution is. A request for a screen element like an iframe 10,000 times the height of of the screen clearly fails any reasonable sanity check you might think of. Its clearly a broken page, and should be rejected at that point.
Just as if I'm Safari for the iPhone and the page tries to allocate a 2 billion cell html table, i don't care even if its "legal and well formed html", don't bother rendering it.
A request for a screen element like an iframe 10,000 times the height of of the screen clearly fails any reasonable sanity check you might think of.
And how am I supposed to look at this 30 gigapixel Longcat pic now? You insensitive clod!
A request for a screen element like an iframe 10,000 times the height of of the screen clearly fails any reasonable sanity check you might think of.
Never underestimated the size of a log file before opening it in an editor, huh? No, 0123456 is completely correct: it's the kernel's job to validate its function parameters. That doesn't mean Safari should be gratuitously throwing ridiculous values at it, but Safari should be able to without anything bad happening.
For example, you'll probably never need to printf("%1000000000000000s", &hugebuffer), but libc is required to tell you if you've asked it to do something dumb that it can't fulfill. It's right there in the spec. If it fails to ensure it can sanely execute your request, it's broken.
Dewey, what part of this looks like authorities should be involved?
You must be new here if you think no-one says anything bad about Apple.
Or better still use Chrome since Safari is a monstrous memory hog on OS X.
it's the kernel's job to validate its function parameters.
I never said otherwise.
That doesn't mean Safari should be gratuitously throwing ridiculous values at it, but Safari should be able to without anything bad happening.
And I agree with this too. Read the whole thread not just the last response. I said at least TWICE that I completely agreed it was a bug in windows ALSO.
My point here, is that EVEN if windows COULD fullfill this request, Safari should STILL be blocking it. My browser shouldn't open 18million pixel high iframes, simply because some random website asked it to, even if it were technically possible.
There is all sorts of perfectly legal html, css, etc one can write that browers should reject or at least constrain.
p { border-width:15000000000px; }
Perfectly legal and well formed. The CSS spec doesn't say where that I can find what the maximum border width in pixels should be. It doesn't say anywhere I could find what the largest integer should be. So15 billion pixels border width? Within spec.
My browser should still just ignore it.
It shouldn't even get passed onto the drawing APIs to try.
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 its own counters although the easiest so far is finding a binary that is loaded without ASLR enabled and its address is therefore known.) The most common purpose of a return-oriented program is to mark a section of memory executable (turn off the NX flag for that page, which essentially says "I want this piece of memory to prevent DEP is disabled" and has many legit purposes, so it can't be blocked).
Second, there are attacks that work even when DEP is enabled. Ever heard of "JIT spraying"? It's a pretty simple technique, actually - you use any program that has a JIT compiler, like Safari (or any other modern browser, or Flash, or a Java applet, or...) and have it load a script or bytecode containing a whole bunch of instructions like this that do things like add two 64-bit integers together. With each of these, you write 17 bytes of memory into the instruction stream. You have full control over 16 of them and you know what the other one is. Now, if the instruction pointer jumps to the start of the first instruction, it'll do a bunch of meaningless arithmatic on really big numbers. If it jumps into the stream in the middle of one of those huge instructions, though, it's now exeuting attacker controlled code, and can do pretty much anything at all (you can fit a lot of x86 instructions wholly within a 64-bit number, much less a bunch of them). You have to work around the actual arithmetic opcodes, but since you know what they are and you control the bits around them, you can make them be interpreted as part of the alternate instruction sequence.
Seriously, that's just two approaches off the top of my head that both completely defeat DEP. There are others, too. In general, if the attacker can write even a few bytes of arbitrary memory (sometimes as little as changing one bit is sufficient), you assume they can take over the program. If they've already got control of the instruction pointer (which is the point where DEP even becomes relevant) you *KNOW* you're hosed.
Also, the kernel-mode crash is certainly due to to a kernel bug. Hypothetically you can have a bug that doesn't involve memory corruption, like a syscall that takes a pair of parameters and divides them without checking whether the denominator is zero. However, any kernel entry point (be it in a driver or otherwise) is supposed to validate its input when the input is coming across the user/kernel boundary. If it's not doing that, or not doing it correctly is is a bug. Since we're discussing kernel-mode code here, it is specifically a kernel-mode bug. The fact that the bug is triggered by compromising a user-mode program doesn't change that at all; I could just as easily write a user-mode program that intentionally triggered the kernel bug, and get arbitrary privileges on the system.
There's no place I could be, since I've found Serenity...
If the OS allows Safari to run any arbitrary code, or ANY software for that matter, then there is an OS problem.
Safari isn't just a user mode application. The only reason it's on windows is part of an itunes installation, which includes several services which run in the background with SYSTEM privileges.
Since the flaw isn't clear yet, it's all speculation at this point.
If Apple wrote iTunes, then why does it suck so much?
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
WTF?
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
At about 100 pixels per inch, that's about 180,000 inches. That's almost 3 miles. Also, if the image is 200 pixels across, you have 3.6 billion pixels. At three bytes per pixel (RGB), that's over 10 billion bytes. That's more than most people have in RAM plus swap. Shouldn't something check to see if the computer can handle such a request
What if the only computer you have runs Microsoft Windows 7 64 bit, and you need to see how your web pages render in Safari?
Might as well check Lynx and AOLOnline for 95 browsers as well, too...
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
Shouldn't something check to see if the computer can handle such a request
Yes, the Operating System - the thing that manages the hardware of the computer.
Having said that, there's nothing wrong with user-mode programs also doing sanity checking - defense-in-depth and all.
*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 code migration? 7 will tide us over for another several years.
I am John Hurt.
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.
I am John Hurt.
According to this http://en.wikipedia.org/wiki/Usage_share_of_web_browsers, Safari has 11.2% usage share, and Other has only 3.5%.
win32k.sys is not an NVidia driver.
yeah, friends don't let friends install safari!
Wealth is the gift that keeps on giving.
Nvidia's crashes Firefox and Creative's kill my machine with IRQ errors.
Sorry. Slashdot had some wonderful UI changes again such that your parent post didn't show up at all (on the main comment page in TFS).
I would be very worried about any user mode code that can blue screen the system.
The bluescreen is simply an indication kernel mode state is horribly inconsistent. Whatever the code was able to do to corrupt OS state, there is a good chance this could be used as an attack vector.
Making an application crash is often the point of discovery of new exploits.
Admittedly, I don't know the security model too well. But how does Windows know that the instructions coming from Safari are Good or Evil?
Don't worry, he [thinks he] is one of God's Christian soldiers.
What ? How do you propose the OS know whether or not Safari is running "arbitrary" code ?
Intel or AMD?
There's nothing stopping media acceleration and OS's coexisting - they have forever. That's the best bit that I've seen of Windows 7: video driver crashes - no problem, reinitialise the hardware and start it again as if nothing had happened. That's *proper* isolation of userland code (we don't care what the hardware's doing, this is what we have on screen) from hardware (bugger, the videocard has crashed, okay, bung it back into VESA mode, reinitialise it, and when it's ready again I'll ask the software to redraw themselves). That's the whole point of an OS. What burdens the hardware takes off you are entirely inconsequential - if the OS has to rebuild the GL state, that's what it does, if it has to reupload the textures, that's what it does, if it has to do anything it ALL goes through the OS at some point and can be controlled and restarted at will, accelerated or not.
The OS is there to remove hardware from software. The software doesn't need to access the hardware directly in order to get its job done (and shouldn't be, either, hence why DirectX, OpenGL, device drivers, etc. exist as intermediate layers) and hasn't needed to since the DOS days (and even they were decades behind the Unixes of the day in that respect) and the OS doesn't need to bug out if there's a problem with a single item of non-critical hardware.
No userland code, no matter what it pokes, documented or not, when run as an ordinary user should cause the OS to stop working. It's not only stupid (that's WHY OS's were invented!) but dangerous (there's no telling what state you could get the OS into, what the side effects of that crash are, and whether it can be used to bypass the OS security).
The absolute worst is that the OS decides to terminate a program because it's being silly or things spin out of control because it gets into an infinite loop. EVEN THEN, the OS has control and can kill whatever the user needs to.
No userland program, ever, in the world, should be able to cause a kernel panic or BSOD when run as an ordinary user on a clean station. If it does, it's a poor / broken OS.
Nah, when it's a privilege escalation bug exploitable through a web browser in iOS we just call it "unlocking" the phone.
--Jeremy
Jesus was a liberal
More details now available:
http://pastebin.com/XTWnLF3p
https://twitter.com/#!/aionescu/status/149818580471517184
And how many of those 11% are 64 bit versions of Windows 7?
Browsing at +1 - no ACs, I ignore their posts. So refreshing!