Antimalware provider Prevx has sounded the alarm about a serious vulnerability in fully patched versions of Microsoft Windows. It allows attackers to execute malware, even in versions designed to withstand such exploits. Technical details have already been published on a Chinese forum, leading to speculation that it won't be …
so, another critical major vulnerability that makes a system that has already been taken over insecure?
well at least by exploiting this bug they only need to trick a user in to downloading and running something, reducing the number of security prompts they need to ignore by 1, saving the victim precious seconds of their time that would otherwise be wasted blindly clicking allow to that annoying UAC prompt that comes up every time they try to install another cursor tool bar emoticon set
For those who don't surf as admin, privilege escalation attacks are a little more serious than you make out. It's not just "saving a click". It makes possible something that is otherwise not possible.
That said, those of us who don't execute random attachments are still safe, so I'm not losing any sleep over it. At least, not yet. Combine it with some "autorun" vulnerability in IE or Outlook and put a rootkit on the back and *then* you'll have something to frighten the children with.
>Combine it with some "autorun" vulnerability in IE or Outlook
so, only a problem on systems already running malware?
It's kind of awe inspiring just how many security flaws a large chunk of code can hold. You'd think we'd run out eventually, but it's like some sort of magic perpetual motion machine.
... and there is oxygen in the air, and there are chuck norris jokes in Barrens Chat in World of Warcraft. (Along with the cross roads being under attack)
Don't forget the bears!
for bundling UI code in the kernel.
Repeat after me: I shall not incorporate UI/Shell/Explorer/other unneeded code in the kernel. Damn thing is hard enough to write securely as it is.
Tux, for getting this right from the start.
This is a stack overflow bug in NtGdiEnableEUDC // some kindov syscall...
Why do you suggest that this is a UI-in-kernel issue ?
Not sure what the function does but GDI is the graphics system in Windows. Not exactly the UI but it still shouldn't be in the kernel.
but to me, the GDI part of this API call sort of suggests UI.
Starting from NT4, Windows graphics drivers live in kernel space. Hence, calls to GDI functions end up being handled in the kernel with kernel level privileges.
Windows NT 3.5 was a solid kernel that had poor performance in graphic apps and games. NT4 moved the graphic card drivers in kernel space to provide decent performance.
This is a design trade off. Other decisions made in the name of ease of use, for example having loads of useless services enabled by default in later Windows versions, have exposed other security holes.
It comes down to what security experts call "attack surface". The higher the number of things you expose, the higher the chance of someone discovering security holes in them.
Until Microsoft shifted its focus to security a few years ago, Windows design always leaned towards anything but security. And the backward compatibility ball chain means that some of those decisions are simply impossible to fix.
... before a Linux fanboy took the bait. Can fishermen comment on whether that's a reasonable waiting time for a catch? And both can take a worm as a bait.
Possibly because of the letters 'Gdi' in the name of the function. and because 'The flaw resides in the win32k.sys part of the Windows kernel'.
Probably because the article says that the code in question seems to respond to user input and runs with KERNEL priviledges. This is a bit like the first internet worm that was so bad because everyone ran the finger deamon with root priviledges, so the worm automatically had root priviledge.
To be slightly fair to the programmers, you loose a lot of processor cycles switching between different privilage modes, part of the reason that the graphics system also moved (unless Intel has changed that).
In a perfect world, the only thing that would run with kernel privileges is the code that needs them to look after everything else; task handling. Everything else should really just run with a lower priority so it cannot crap over everything.
One is led to assume that this is a part of the Windows UI because with Microsoft, NT usually means "Any windows based on the Windows NT/OS2, i.e. any Windows version after W2K", GDI is "Graphics Device Interface" and EUDC is "End User Defined Characters".
in vista and 7, so it probably shouldn't be in the kernel in those 2. XP is understandable.
...GDI stands for Graphics Device Interface?
"you loose a lot of processor cycles switching between different privilage modes"
I know spelling flames are cheap, but the above actually made me cringe. A sign that it is time for very strong coffee (feeling somewhat fragile today, suffice it to say..)
Yeah, but the only other graphical APIs are DirectX, GDI+, and some managed crud. The former has no text output, GDI+ is built on top of GDI and DirectX, and all managed code runs on top of native code.
Deprecate all you like, but until you provide an alternative no-one is going to stop using it.
Tux may be many things but it is not a microkernel and it has not made much effort to minimise the amount of code running with elevated privileges. Minix was different and Linus made a conscious decision in that regard, for performance reasons, so your Tux remark is about as wrong as it can be.
Not to mention the 3 different spellings of privilege. Thankfully one was actually correct.
the clue is in the syscall name.....
So, information about the vulnerability has been published, microsoft have been made aware of it, and some time later (guessing > 0 days) we will have exploits in the wild.
How on earth is this then a 0-day vulnerability?
Perhaps you think like a quantum particle, you know, everything exists in all possible states at all times etc.
How do you know there aren't already exploits in the wild? Also, the Gdi in NtGdiEnableEUDC puts the UI in KERNEL.
... an exploit will be out by tonight :p
Oops, I take that back about the GDI comment.
Same old digs from the penguins.
The answer is YOU need to persuade your company to switch it's entire estate to something non-MS, and you need to persuade the staff to switch their home PCs also.
NOT GOING TO HAPPEN
(just before some smug BOFH replies, yes, I know a few of you have already acheved this. Well done, have a sweetie)
So move along and stop bitching just because you think you are safe. If Linux had >90% penetration on the desktop, we'd be seeing a lot more incidents related to it. Look at it from the criminal aspect - what's the point in spending £100,000 to break into a vault to steal £1,000
For the record, I have no allegiance to any OS. I use and like MS and Linux. But I put my business hat on and I know which is cheapest to use in my business environment (TCO).
Same old tired excuses from the 'softie fanboys, with same old >90% bullshit and 'I'm not homophobic, I have gay friends, but...' type rhetoric.
Can't you security weenies come up with a better term than 0-day. Also, why are security flaws in Windows newsworthy. This is a standard feature of Windows.
...is that you sacrifice performance, and the fault happens to reside in a GRAPHICAL routine. Guess what's one of the most demanding things a computer can do? Graphics (especially 3D graphics) is such a demanding job that programmers have a devil of a time finding the fine line between making it universal and taking it close to the metal for maximum performance.
If it *really* is a problem, fire up oprofile and look at the problematic routines. Selectively remove array guards where it makes sense and a review team approves of it.
98% of the time array guards pose a negligible performance problem.
"This is a stack overflow bug in NtGdiEnableEUDC // some kindov syscall...
Why do you suggest that this is a UI-in-kernel issue ?"
Well, it's right in the name of the system call: "GDI". That is graphics device interface. I googled and EUDC involves adding user-defined characters to a (non-unicode , since they mention code pages) font. You've got this whole state machine to handle lines, points, fills, paintbrushes, clipping, even bitmaps, metafiles, and fonts -- IN THE KERNEL. Sorry, but this way lies madness, it's no wonder there's so many exploits turning up.
how about 'built in feck up from the start done by a fucktard that should never have been allowed anywhere near operating system code and done in an 'software enginering culture' that wasn't up to the job ?'
0day much less typing...
Maybe "one of these 5 million f*tackards" who earn lots of money by C++ programming or contribute to major Open Source projects. Firefox recently had a buffer oveflow in the main JS method.
How long will it take Microsoft to make the updates and allow all to update their systems? Will they give it to XP as well?
Could happen to anybody. And what's the big-picture impact of a buffer overflow in user mode code ? And the big picture impact of a buffer overflow in kernel mode code? How much code should be running in kernel mode? How explicit should the kernel mode design/code guidelines be? How experienced should a kernel mode coder be? How closely should kernel mode code be reviewed?
Now, what was your point again?
C++ combines the worst of two other languages I'm reasonably familiar with. It has the complexity, obscureness, and massiveness of Ada with much of the unsafeness of K+R C. It should have been strangled at birth. But we are where we are; the world has moved on from K+R, and not necessarily in a good way.
Too much kernel mode code, inadequate management, and C++. A recipe for disaster.
There's a rumour that RR's Trent 900 engine control (as seen on TV) was programmed in C++ (most of RR's other modern stuff is Ada, which is in more general use in that sector of the industry). That's not just kernel mode, that's life threatening.
What is especially good is that NtGdiEnableEUDC is an undocumented function in Windows.
Keep it hidden -> only the bad guys will find out.
All of this arises because Billco and his friends in the meeja didn't understand (or care about) the difference between performance and productivity.
Back in the days when 16bit Windows was still around and NT3.x was new fangled, my self-supported NT3.x laptop enabled me to be more productive than my IT-supported Win3.x/Win9x colleagues with allegedly more powerful IT-provided desktops.
On any given performance benchmark, mine was usually slower by a little bit. But on a typical working day I got more done than they did, sometimes lots more, because theirs were constantly refusing to process something because they were out of memory, and I'd do it for them in a flash. Or maybe some app had hung and they'd lost their work. Stuff that NT largely made history.
Billco and his media friends meanwhile were reporting that NT was (say) 20% slower in some game-oriented benchmark, so Gates said to Cutler "never mind this partioning for security, it's making us look stupid, why is it slower than 16bit Windows, 32 bit should be twice as fast. Get rid of that security stuff.", and the rest is history.
Biting the hand that feeds IT © 1998–2018