| Date: | July 6, 2007 / year-entry #244 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070706-00/?p=26123 |
| Comments: | 24 |
| Summary: | Some people can't get over the initial burst of adrenaline when they think they've found a security vulnerability and rush to file a report with Microsoft so they can get credit for it and add it to their "security vulnerability portfolio" to show that they are so wicked cool. Learning that what they found isn't... |
Some people can't get over the initial burst of adrenaline when they think they've found a security vulnerability and rush to file a report with Microsoft so they can get credit for it and add it to their "security vulnerability portfolio" to show that they are so wicked cool. Learning that what they found isn't a security vulnerability isn't going to stop them. "The — Um, no, the "Snap to default button" feature doesn't work that way. It only snaps when the dialog first appears. "Okay, well, then I can write a dialog box that hides and shows itself while it's changing its default button. That way, each time it shows, it yanks the mouse to the dialog's default button." — That doesn't work either. It's on the first show that the mouse moves. "Oh, okay, then I'll create and destroy the dialog in a tight loop. Each time the dialog box appears, it will yank the mouse. Aha, gotcha!" — Well, sure, you can do that, but if your goal is to write an annoying program that yanks the mouse around, then this is an awfully inefficient way of doing it. Your annoying program should just call You shouldn't be surprised that allowing people to run code lets them run code. (Episode 1.) |
Comments (24)
Comments are closed. |
Talk like that is only emboldening the terrorists.
I, for one, am quite emboldened.
A noble spirit embiggens the smallest man.
Hmm… so how about this one: In troubleshooting why UAC elevations were taking several seconds to run, I found consent.exe (the process that displays the prompt) was loading my own shell extension (presumably to retrieve shell icon overlays). Some call in my DLL was failing, and consent.exe reloaded my DLL and retried the call three times before displaying the UAC prompt. Fixing the bug in my shell extension fixed the issue, but left me with a bad taste in my mouth–what is my own code doing inside consent.exe anyway? If I crash, I prevent UAC elevation from working at all, crippling the machine and requiring a reboot into safe mode to uninstall the extension and restore normal functionality. I can conceivably poke around in the consent.exe’s memory space and prevent the prompt from showing up at all. (FWIW, I couldn’t just send a message to push the "Allow" button because my thread was not on the secure desktop.)
So is this a security vulnerability? One the one hand, I needed admin privileges to install the shell extension in the first place–but on the other hand, I can interfere with admin escalation later on…
If you already have administrator privileges, it would probably be easier to create an account in the Administrators group give TS access to it, create a service running as LocalSystem to do your bidding, install a device driver that intercepts and tweaks all sorts of user mode calls, or just disable UAC altogether.
DriverDude: Well, you can just provide a hook that will prevent Ctrl-Alt-Del. You see the question about "how do I do this" all the freaking time in programming forums. (from "I want to make a security program and keep people from end-tasking it" to "ctrl and alt have meaning in my game, and pressing ctrl+del and alt+del do special things, and I want ctrl+alt+del to do something else")
One thing I was wondering was if plugin dlls (like in 3d studio max, or Half Life (2)) could be a security vulnerability. Granted they don’t run in an elevated security context (one would hope), but it seems like impersonating a plugin could be an initial delivery system.
Err… if someone does SetCursorPos() to me I’d just unplug the mouse. No mouse, no cursor that moves. Then I kill the bastard with a (steel reinforced) keyboard. End of story.
PingBack from http://doubt.pernick.org/2007/07/06/WindowsSecurityBoundaries.aspx
Igor: That will only work if you start up the computer without a mouse plugged in (I unplug my PS/2 mouse, still have a cursor. Unplug my USB mouse, still have a cursor). You might as well start in safe mode if you’re going to restart your computer anyway.
Hahaha, wonderful "security problems".
I’d myself use IOTCL’s with some known (or not so known) device(s), go straight to ntdll, or even do my own software interrupts just to display (intentionally spelled like a child) "leetness". Now *there* we have food for privilege escalation.
That said, SetCursorPos can in fact make it effectively impossible for a user to even kill that process using the T(a)skM(ug)g(e)r. Add DirectX into the equation, not to mention third-party vendors’s drivers, and you have created something you sometimes can’t get out of without a hardware reset.
Though, there are easier way to DoS oneself. I just the other week screwed up myself – I wrote a little MineSweeper starter program, just as an experimental hack, that clicked the corners. Then I, just for kicks, added some more "pads" it clicked, and some more, and some more. If it failed (sad face) it just restarted. As you might imagine, given a bad enough random seed it could run for *minutes*, having full control of both the mouse and the active window. There simply is no way to stop such a runaway program.
Need I say I felt like an idiot for effectively DoSing myself, and have since fixed this? :-)
Lancelot, Galahad and I wait until nightfall, and then leap out of the rabbit…
I don’t have any malware handy to test with, but I think Ctrl-Alt-Del will bring up the "secure desktop", from where you can log off (and kill the offensive program) or switch to a Admin user and End Task the offender.
If Ctrl-Alt-Del does not allow you to regain some measure of control, then *that* is a bug.
PingBack from http://www.andrewgrant.org/2007/07/06/links-for-2007-07-07.html
The irrepressible Raymond Chen recently mused about "security holes" that aren’t &endash; that is to say, features which may be misused but don’t actually cause security vulnerabilities. While Raymond’s blog is always worth reading, this is more about
"Igor: That will only work…"
You see, that is exactly the problem with Windows. If there is no physical mouse it should not respond to SetCursorPos().
I know that there is a mouse emulation mode using a keyboard but unless I turned it on, no mouse cursor should be visible let alone moving around.
Igor:
I don’t see – when all my mouse devices are disconnected, the cursor is hidden. Something else must be going on.
Running Vista, made a quick C# program with the following:
private void button1_Click(object sender, EventArgs e)
{
//CurPos is defined as a member of the form
CurPos.X += 5;
CurPos.Y += 5;
Cursor.Position = CurPos;
}
I then unplugged my mouse (the only one attached to my desktop) and pressed spacebar (with button1 being the only button on the form it was “click”ed). The cursor kept moving diagonally across the screen.
So I don’t see what you mean about the cursor being hidden, it certainly isn’t on my version of Vista Ultimate.
igor –
What precisely is a "physical mouse"?
I worked for a manufacturer of digitizers that connected to a system via bluetooth; they worked marvelously as a mouse, but they probably wouldn’t meet any definition that you come up with. Heck, these worked great as a mouse without loading a driver or a service!
I have a Logitech wireless mouse, and a MoGo bluetooth mouse, "connected" to my laptop. Do they meet your definition of a "physical mouse"?
Are you familiar with all of the cursor-movement devices used by the handicapped, and the ways they connect to the PC? Does your definition of "physical mouse" include all of them?
My Windows MCE box has an infrared remote that can be used as a mouse; does that meet your definition?
Would you modify the Windows API to require that all "Physical Mouse" devices register as such before they were allowed to move the cursor? Would you require that Microsoft sign the software so that no unauthorized cursor movement could occur on your system?
I think I’ve beaten this point into the ground…
Raymond: That’s exactly my point. If you have to restart anyway, why not start in safe mode to delete the program that’s doing what you describe in the article?
There’s stuff that any regular user can do – like move the cursor – and stuff that only an Admin user can do.
Can a regular users’ programs trap Ctrl-Alt-Del or otherwise mess with it? I would be surprised if it could. Obviously Admins can do nasty things like replace the kybd driver to do anything at all – moving the cursor is the least of the problems!
Unfortunately this is moot because we all know everybody is an Admin…
Back when Netscape was growing up, I was surprised that viewing a web page allowed me to run other people’s code.
SetCursorPos is nothing compared to endless windows opening at random locations.
Reminds me of some application using ClipCursor, then crashing, leaving the mouse cursor confined to a small segment of the screen where the window used to be. Very annoying. Moreso than the SetCursorPos trick.
"What precisely is a "physical mouse"?"
It is a pointing device which registers in the system under "Mice and other pointing devices" and/or under "Human Interface Devices" in Device Manager.
Therefore it already has its own class.
I am just saying that unless such a device is connected mouse pointer should not move spuriously around the screen in very much the same way your TV shouldn’t be able to change channels on its own when you are not touching the remote.