| Date: | May 9, 2006 / year-entry #160 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060509-30/?p=31263 |
| Comments: | 26 |
| Summary: | Last time, we left off with a promise to discuss ways your program can be Internet-facing without your even realizing it, and probably the most common place for this is the command line. Thanks to CIFS, files can be shared across the Internet and accessed via UNC notation. This means that anybody can set up... |
Last time, we left off with a promise to discuss ways your program can be Internet-facing without your even realizing it, and probably the most common place for this is the command line. Thanks to CIFS, files can be shared across the Internet and accessed via UNC notation. This means that anybody can set up a CIFS server and create files like And that's where the command line attack comes from. Suppose your program is a handler for a file association. Say, your program is
Notice that the attacker controls the path. This means that if you have a bug in your command line parser, the attacker can exploit it.
Note that this extends beyond merely extra-long file names. If you registered your verb incorrectly by forgetting to put quotation marks around the file name insertion
Your parser then breaks the command line up into words and interprets this command line as having three parts:
The program then tries to load the file Of course, the attacker also controls the contents of the file, so any vulnerabilities in your file parser can be exploited as well.
If you write a shell extension, your extension will run if the user activates it on the remote file. For example, if you have a context menu extension, it will be instantiated and initialized with the remote file as the data object. Many context menu extensions contain buffer overflow bugs in the way they mishandle the names of the files that the user right-clicked on. (Notice that I said "names"—plural. The user might multi-select files and right-click on them.) For example, a certain shareware file archival program responds to the
Just because your program doesn't contact the Internet explicitly doesn't mean it's safe from Internet-based attacks. |
Comments (26)
Comments are closed. |
Raymond,
How did the attacker (on a server over the internet) get the user to execute the verb.
You examples seem like special cases of the "if you can run a program in the context of the user, it’s not an elevation of privilege".
I see how this could be turned into an exploit by the right content (a .pif file downloaded from the internet) but there has to be user intervention involved somewhere.
You can (1) use deception, or (2) rely on users’ belief that "Oh, I’m not running an untrusted program, I’m just opening a document."
The ‘spaces in the file name’ trick is common in other operating systems, too, and surprisingly is better handled by most Windows developers than it is on other platforms! OS X ran into considerable problems when it came out, because most Unix script authors were unused to dealing with spaces in file names, but most Mac users loved to put spaces there.
One trick I use to increase my chance of catching these errors is to have a couple of directories called "Program" and "Documents" in the root of my C drive, and remove all my rights to them. Then I get an error any time a "C:Program Files" or "C:Documents and Settings" path gets executed incorrectly.
It’s not a 100% guarantee, but it does catch a few programs.
If you can use deception, what’s to say you can’t deceive a user into typing an arbitrary string into an arbitrary dialog causing a code injection? Like "To win many dollars, copy and paste this string into XYZ App’s options menu."
Just like visiting a "malicious webpage" by getting them to click a URL, you’re tricking a user to perform an action that does something malicious, unexpectedly.
Since when are programs combined with their uninstallers!?
Ok, I have seen malware do it, but I’m pretty sure I’ve NEVER seen an (legitimate) application that uninstalls on a command-line flag.
And anyway, this is Windows we’re talking about, it should be "/uninstall" not "-uninstall".
In fact "-uninstall" wouldn’t even be normal on a UNIX system, it’d be "-u" or "–unistall".
That was just a hypothetical "bad thing" you can do from the command line. I leave your imagination to come up with more likely "bad things". Fancy text editors for example are rich targets.
Why do something as uninteresting as uninstalling?
Why not pass the program the following file name:
&& del /q c:windowssystem32
Forget what I said — && only works in the context of cmd.exe.
For a nasty command line, how about xcopying a bunch of files together (cookies, SAM, *.doc) and tftp-ing the result to an internet server?
I’ve never understood why users have execute access to their own directories. It seems to me that only specified directories (like programs) should have execute rights. There is no reason why a user should be able to run a .exe in their own direcory. However, the execute and transvers rights are overlayed so it’s difficult to remove execute rights without blocking access to the directory (oddly the same is true on unix/linux).
Tuesday, May 09, 2006 10:33 AM by LarryOsterman
> How did the attacker (on a server over the
> internet) get the user to execute the verb.
[…]
> there has to be user intervention involved
> somewhere.
Maybe there has to be user intervention involved in configuring Outlook Express to display its preview pane, but historically the preview pane was on by default.
With Internet Explorer it still seems to be possible. A user might visit a trusted site that they’ve been visiting for years, and neither the user nor the site’s owner knows that either:
(1) the site was infected 5 minutes earlier or
(2) one of the Google advertisements on the site delivers infection to the user via the contents that the advertisement brings in from a third site.
Tuesday, May 09, 2006 12:14 PM by Stu
> Since when are programs combined with their
> uninstallers!?
You might be right on that, maybe only DLLs are combined with their uninstallers.
> And anyway, this is Windows we’re talking
> about, it should be "/uninstall" not
> "-uninstall".
This is Windows we’re talking about, where a ton of programs recognize hyphens as option flags and some programs are even documented as doing so.
The worst thing about geeks and nerds is their pedantry – some people are biologically incapable of recognising a hypothetical example if it slaps them in the face.
Also, oddly enough, it’s not unheard of for multiple minor security holes to add up to one big hole. Even if "maybe" the hole is only accessable to people who have already broken in, there’s still a reasonable chance that one other little hole will give them just enough access to attack the second hole and then have full control.
There’s nothing "special case" here. If I run a file server I can *not* run a program in the context of the user, but I can take advantage of flaws in the program that will allow me to inject code if they read data from my server. Therefoer I have had my priviledges elevated from "provide data" to "change the code that is being executed".
Besides, "click here to see the dancing bunnies" is a lot easier than persuading people to format their own hard drive. Although, having said that, people have been persuaded to delete an oddly named file with a funny looking icon, not realising that it’s an important system file. ;) It’s strange, but people who can’t follow instructions to "click on the start menu" when talking to tech support are still capable of deleting system files, as long as they shouldn’t. People are weird.
Raymond – your first comment is posted by ‘oldnewthing’, and your second by ‘Raymond Chen’. Any reason? Forgot you were logged into a that account, or is someone pretending to be you? Or are there two of you? :)
Iain — See the end of http://blogs.msdn.com/oldnewthing/archive/2006/04/13/575742.aspx
Specifically:
> When talking to the voicemail lady, be
> careful to enunciate clearly, because there
> are also a Raymond Cheng and a Ray Chen at
> Microsoft.
There are two of him… ;-)
"However, the execute and transvers rights are overlayed so it’s difficult to remove execute rights without blocking access to the directory"
You simply deny traverse/execute rights on *files* only for any directory which in turn will propagate to files in any subdirectory.
ken lubar, you are confused. Having "execute" rights to a directory does not make it legal to execute files in that directory. Only that file’s execute rights determine if it can be executed. Of course the owner of a file may freely change those rights, so there’s no reason I can’t put any file in any directory and just add execute rights to it.
Also, the "traverse" right on a directory usually doesn’t matter because by default everyone has the privilege that allows it to be ignored. This allows you to create a directory I don’t have access to with a child subdirectory that I can access.
@Stu:
-uninstall is often used for service binaries to (un)install themselves.
It is but just an example; maybe litware.exe only accepts one operand and discards %2 and higher?
@ken lubar:
use Software Restriction Policies in XP and later and only allow execution in %SystemRoot% and below and %ProgramFiles% and below.
Don’t forget to remove .lnk from the list of binaries, and add .swf and other notorious file extensions which may find their normal way into browser caches etc. and get "executed".
@Raymond:
when the executable is registed with it’s full path and detected as 32bit binary then Explorer quotes the %1 itself (you wrote once). SCNR.-)
Somebody would actually expose Windows File Sharing to the internet?
I can’t be the only person who snorted mightily when Microsoft renamed their hackable, wobbly, inefficient LAN file server protocol to be "Common *Internet* Filing System"
Wednesday, May 10, 2006 1:24 PM by Hayden
> Somebody would actually expose Windows File
> Sharing to the internet?
Millions do. I thought this infection vector was famous.
"Fancy text editors for example are rich targets."
Word!
So you’re saying that all programs are exposed to the Internet, because people can download files from the Internet and then open them in programs.
Why on earth would anyone open a random file from the Internet without first thinking about where they were getting it from?
Oh, right, Windows’s special "Internet sites look just like local files" security-hole-by-design which they advertised so heavily. :-P