It is partly right, but this is a vulnerability just like being able to write a Javascript that alters files on your HD is a vulnerability. Javascript is even Turing complete (WMF isn't), but the important point is the domain you are executing in. There are plenty of GDI functions that you CAN'T call from a WMF, like setting an abort proc in another manner than the one used here, or getting a device context to draw in another window in the same session. In fact, I think you are not supposed, or allowed, to draw in another device context at all.
WMF is not supposed to be any kind of code affecting the display and certainly not arbitrary x86 code. Therefore, this is a bug, but the bug was caused by the format design omission to allow the specific escape code used.
While technically right, it's more like "they allow access to most of GDI, including one devastating method that allows you to feed a pointer to a callback proc if rendering fails".
It's more complicated than WMF just being able to call anything inside GDI32.dll. This is demonstrated by the fact that SetAbortProc was never allowed, the way to do it in WMF was using the Escape function, which has an obsolete escape code for adding an abort proc in the context where it makes sense, for printer spooling.
So the oversight is that an escape code was included for setting an abort proc, and there were valid uses for escape codes in WMF. The explicit and current way to set an abort proc was never allowed.
Nice story, but it's wrong. A Windows meta file is a spooled set of GDI commands, nothing more, nothing less. That said, some high-level picture libraries will look for several types of image headers in the files they're fed, no matter the extension. The LoadBitmap API in GDI will not. You can load a BMP, JPG or PNG that way in any recent Windows release.
Get your facts straight or stop feeding the trolls.
No, the Win32 version is (mostly) just calling down to the Win32K.sys file in the kernel. This isn't present in WINE. There are also other issues, but this single fact is the killer that makes it totally impossible to work. (aside from licensing issues:-)
Well, if you run as the same user as your normal home directory, it can be devastating enough. It's not like you need to be root to send out a thousand mails with your "personal" pictures transformed into virus vectors.
The DLL in question is a common library used to load and view image files. The real WMF parsing is going on in GDI32 and Win32K.sys (GDI32 relies on Win32k, which is generally not called directly), though. So, you can't run explorer.exe from XP to get fancy thumbnails, but you CAN open an exploiting WMF file in several programs, and get the exploit all for free. As I noted in another comment, it's unlikely that a WMF effective on XP would also be effective on WINE, as it will probably be relying on the specific address space layout, though.
You add a configuration flag, defaulting it to OFF.
I would also guess that it's quite uncommon that the same exploting code actually works, as many addresses will be different from a normal XP system. The same vector, i.e. a malformed WMF file resuling in a call to the abort proc of choice, is still possible, though.
Just don't expect this to solve everything. The point of DoktorFuture was that people hardwire their exploits to existing code addresses, so hard that even a simple DLL relocation may break them. Even if all writable address space is no execute, you can get a buffer overflow to overwrite the RET pointer on the stack. In its place, you can write the address to a carefully chosen routine, and if you're really mean (and depending on the calling convention used), you might even get the possibility to tell what parameters it should use. Imagine that the call in question is good old POSIX "system" and the data is a pointer to a malign string on the stack. This assumes that you know the system so well that you know for sure the specific stack address used, but that's not impossible if the design is consisting of a bunch of worker processes that serve each request from a rather "clean" state of almost empty stack, for example.
In fact, this gets me thinking that just a rotating use of stack base pointer in new processes would force exploits to be more clever... That, and arbitrary code relocation, is far easier than actually mangling the code.
"Canaries" as safeguards on the stack and no execute of writable memory combined might give you a pretty good improvement, but they are still vulnerable. The SetAbortProc exploit here could, even with DEP, possibly be targeted against a suitable API address and attack the system.
It goes back to Windows 3.0. You know, the one which relied on DOS software for network access, without sockets. You know, the one where using any memory protection at all was an OPTION (kind of mandatory in 3.1 and up, even if it was far from complete).
If you, or someone else, might add all the numbers together later on, and you want them to get the right sum. Randomizing is the only way to do this if, for example, you have a list of identical numbers and you don't want to create any simulated 010101010101 pattern by alternating instead of randomizing.
That's what's sometimes done, and it's mentioned in TFA. But, what kind of logical constructs would you use to define the expected output for any input, in a logical manner, instead of just lining them up? Hey, that's the program itself. If you can define exactly what you want in a concise manner, with a way to verify it, then the only remaining problem in the resulting code is performance. (Of course, in practice many of these systems have a realtime requirement to a varying degree.)
You might be able to simulate the system as a whole and instead define "forbidden" states. You might also be able to test individual parts, where you think the set of inputs/outputs is more limited (unit testing, more or less). You might organize your code in a logical manner, suiting the problem at hand, limiting the number of things that you need to keep in mind while writing code, instead making it the task of the compiler or other tools to check them for you. But what very many bugs boil down to, when not typos (which is surprisingly common) is: "Hey, I didn't think about that ever happening, and that it would have those consequences.".
"Just" testing might cause you to think, but to think about That Thing That Is The Big Bug is the problem. If it eluded you while writing the code, it might elude you while writing the test.
It's working against a magnetic field. We have both fluctuations and reversions in the history of the Earth magnetic field, so any attempt to say that a traditional magnetic compass is really measuring a gravity field seems a little premature, to say the least.
I'm not so sure about that. Yes, some picture loading libraries provided in Windows will do this. No, LoadBitmap won't (it's not a bitmap!). IIRC, Firefox doesn't use the same high-level libraries, as they are rolling their own code on all platforms. So, no, it won't happen. You can easily try this if you have a valid WMF file lying around. Rename it to JPG and open in FF. It won't render, complaining about an invalid header. Rename a valid PNG to JPG or a valid JPG to PNG, though, and it renders just fine. Firefox does auto-detection of image type, but not autodetection of WMF.
Only if the real fix is such a "shut the thing off" workaround as both the unregistering and real unofficial GDI disabling patch was, which both disabled a lot of valid cases.
For an out-in-the-wild exploit, I would agree. For one that is currently, to their knowledge, not known among the script kiddies of the world, I'm not so sure. Releasing a patch will, generally, make those who are not yet prepared to implement it more vulnerable, if it means that knowledge of details is more wide-spread.
I think that some corporate users (especially) are quite thankful for patch Tuesdays; especially those that have been bitten by some compatibility issue previously and can't just run autoupdate of all desktops at night, but rather want to roll it out manually.
Again, this is not the case here, this exploit was discovered in the wild and it's spreading right now.
The eletric toothbrush that charges through USB and can also modulate your favorit songs (if properly DRMed) while you hold it against your teeth. Heck, we can even put a BlueTooth transmitter in it, with headset functionality. Never miss another call while cleaning your teeth!
A photon is huge only in the sense that its location is unpredictable along the axis of movement (when the wave-length is well defined, as the wave length is directly related to momentum and Heisenberg applies to each dimension). It is not huge in the sense "can't get into an atom", as you can excite or ionize inner electrons with "just" UV or gamma, which are still far above the distance between atoms in a molecule (which is in the same order of magnitude as 0.1 Nm; 1 Ångström).
You can't peek into the eye of a needle by throwing bowling balls at it, but you can very well thread a long thread through it, even if the volyme of the thread is far larger than the volume of the eye of the needle. You just need a coherent light source exactly perpendicular to the surface. Then your only problem is diffraction, which is already better mentioned by other posts.
Better not tell the photons that just about any orbital they excite during absorption is much smaller than the wavelength, then. A single molecule of a substance will of course absorb some light, even if the wavelength is much higher. If that's the only thing in the path of the beam, you will even be able to make out a spectrum, theoretically.
I can't say that I really understand this yet, though...
Yeah, like opening any document and its macros automagically inside the Firefox window! We could even call this cool component technology something, like OpenX.
Part of the WMF handling is in Win32K in current Windows versions, so it is in ring 0, yes. It's not in the kernel, though. The current exploit is not in kernel mode, it's about running arbitrary code in user mode, so it is still not a kernel issue. It's an issue in Vista, but not in the Vista kernel. It is about as relevant as checking if the stupid "64 k" notepad limit was still present in WinME as a way to determine if there was any 16-bit stuff left in the kernel of that OS.
The OS/2 heritage is far more complicated. There are similarities, but the kernel is quite unlike what you found in OS/2 2.x, while NT at some point could have been OS/2 3.x. It's almost as dissimilar to OS/2 as it is to Win 3.1. It was a new kernel that was supposed to be able to run both Win 3.1 and OS/2 user mode apps, so the kernel provides services suitable for that purpose. The OS/2 support was of course never fully developed, but HPFS was supported until a few years ago and NTFS also shares some ideas with it, while not in the actual disk layout.
If your DX(2?)/66 didn't perform well with NT, I would think about memory rather than CPU. Just the fact that NT is all-UNICODE in the kernel, means that every single string is longer than in, for example. OS/2 and 9x. If all you have is 4 or 8 MB, that alone can be quite significant (especially when you're running Win16 and ANSI Win32 apps and every string needs copying and conversion before really being used in the APIs).
Slashdot Mirror
WMF is not supposed to be any kind of code affecting the display and certainly not arbitrary x86 code. Therefore, this is a bug, but the bug was caused by the format design omission to allow the specific escape code used.
It's more complicated than WMF just being able to call anything inside GDI32.dll. This is demonstrated by the fact that SetAbortProc was never allowed, the way to do it in WMF was using the Escape function, which has an obsolete escape code for adding an abort proc in the context where it makes sense, for printer spooling.
So the oversight is that an escape code was included for setting an abort proc, and there were valid uses for escape codes in WMF. The explicit and current way to set an abort proc was never allowed.
Get your facts straight or stop feeding the trolls.
No, there is no malicious intent in posting a story once. The editor posting the first DUPE, though, that should clearly qualify.
No, the Win32 version is (mostly) just calling down to the Win32K.sys file in the kernel. This isn't present in WINE. There are also other issues, but this single fact is the killer that makes it totally impossible to work. (aside from licensing issues :-)
Well, if you run as the same user as your normal home directory, it can be devastating enough. It's not like you need to be root to send out a thousand mails with your "personal" pictures transformed into virus vectors.
The DLL in question is a common library used to load and view image files. The real WMF parsing is going on in GDI32 and Win32K.sys (GDI32 relies on Win32k, which is generally not called directly), though. So, you can't run explorer.exe from XP to get fancy thumbnails, but you CAN open an exploiting WMF file in several programs, and get the exploit all for free. As I noted in another comment, it's unlikely that a WMF effective on XP would also be effective on WINE, as it will probably be relying on the specific address space layout, though.
I would also guess that it's quite uncommon that the same exploting code actually works, as many addresses will be different from a normal XP system. The same vector, i.e. a malformed WMF file resuling in a call to the abort proc of choice, is still possible, though.
In fact, this gets me thinking that just a rotating use of stack base pointer in new processes would force exploits to be more clever... That, and arbitrary code relocation, is far easier than actually mangling the code.
"Canaries" as safeguards on the stack and no execute of writable memory combined might give you a pretty good improvement, but they are still vulnerable. The SetAbortProc exploit here could, even with DEP, possibly be targeted against a suitable API address and attack the system.
It goes back to Windows 3.0. You know, the one which relied on DOS software for network access, without sockets. You know, the one where using any memory protection at all was an OPTION (kind of mandatory in 3.1 and up, even if it was far from complete).
Like C++, which was hinted by the assumption of a reference in the parent.
If you, or someone else, might add all the numbers together later on, and you want them to get the right sum. Randomizing is the only way to do this if, for example, you have a list of identical numbers and you don't want to create any simulated 010101010101 pattern by alternating instead of randomizing.
You might be able to simulate the system as a whole and instead define "forbidden" states. You might also be able to test individual parts, where you think the set of inputs/outputs is more limited (unit testing, more or less). You might organize your code in a logical manner, suiting the problem at hand, limiting the number of things that you need to keep in mind while writing code, instead making it the task of the compiler or other tools to check them for you. But what very many bugs boil down to, when not typos (which is surprisingly common) is: "Hey, I didn't think about that ever happening, and that it would have those consequences.".
"Just" testing might cause you to think, but to think about That Thing That Is The Big Bug is the problem. If it eluded you while writing the code, it might elude you while writing the test.
It's working against a magnetic field. We have both fluctuations and reversions in the history of the Earth magnetic field, so any attempt to say that a traditional magnetic compass is really measuring a gravity field seems a little premature, to say the least.
I'm not so sure about that. Yes, some picture loading libraries provided in Windows will do this. No, LoadBitmap won't (it's not a bitmap!). IIRC, Firefox doesn't use the same high-level libraries, as they are rolling their own code on all platforms. So, no, it won't happen. You can easily try this if you have a valid WMF file lying around. Rename it to JPG and open in FF. It won't render, complaining about an invalid header. Rename a valid PNG to JPG or a valid JPG to PNG, though, and it renders just fine. Firefox does auto-detection of image type, but not autodetection of WMF.
A few days earlier than they were notified about it, and before even the first /. duping? Nah, then Zonk and Taco couldn't outpost each other...
Only if the real fix is such a "shut the thing off" workaround as both the unregistering and real unofficial GDI disabling patch was, which both disabled a lot of valid cases.
I think that some corporate users (especially) are quite thankful for patch Tuesdays; especially those that have been bitten by some compatibility issue previously and can't just run autoupdate of all desktops at night, but rather want to roll it out manually.
Again, this is not the case here, this exploit was discovered in the wild and it's spreading right now.
The eletric toothbrush that charges through USB and can also modulate your favorit songs (if properly DRMed) while you hold it against your teeth. Heck, we can even put a BlueTooth transmitter in it, with headset functionality. Never miss another call while cleaning your teeth!
You can't peek into the eye of a needle by throwing bowling balls at it, but you can very well thread a long thread through it, even if the volyme of the thread is far larger than the volume of the eye of the needle. You just need a coherent light source exactly perpendicular to the surface. Then your only problem is diffraction, which is already better mentioned by other posts.
I can't say that I really understand this yet, though...
Yeah, like opening any document and its macros automagically inside the Firefox window! We could even call this cool component technology something, like OpenX.
Part of the WMF handling is in Win32K in current Windows versions, so it is in ring 0, yes. It's not in the kernel, though. The current exploit is not in kernel mode, it's about running arbitrary code in user mode, so it is still not a kernel issue. It's an issue in Vista, but not in the Vista kernel. It is about as relevant as checking if the stupid "64 k" notepad limit was still present in WinME as a way to determine if there was any 16-bit stuff left in the kernel of that OS.
The OS/2 heritage is far more complicated. There are similarities, but the kernel is quite unlike what you found in OS/2 2.x, while NT at some point could have been OS/2 3.x. It's almost as dissimilar to OS/2 as it is to Win 3.1. It was a new kernel that was supposed to be able to run both Win 3.1 and OS/2 user mode apps, so the kernel provides services suitable for that purpose. The OS/2 support was of course never fully developed, but HPFS was supported until a few years ago and NTFS also shares some ideas with it, while not in the actual disk layout.
If your DX(2?)/66 didn't perform well with NT, I would think about memory rather than CPU. Just the fact that NT is all-UNICODE in the kernel, means that every single string is longer than in, for example. OS/2 and 9x. If all you have is 4 or 8 MB, that alone can be quite significant (especially when you're running Win16 and ANSI Win32 apps and every string needs copying and conversion before really being used in the APIs).