Re: URI handling woes in Acrobat Reader, Netscape, Miranda, Skype

["KJK::Hyperion" <hackbunny () s0ftpj org>]

Paul Szabo ha scritto:
> What I see as "root cause", is not what IE7 has changed. Windows was
> always confused about quoting, may parse and re-parse a command an
> unspecified number of times. Compared to Unix, it confuses system(3)
> with execl(3).

You cannot compare them, Windows doesn't have argc/argv, it passes
around a flat string command line. There is no confusion either, system
is ShellExecute and CreateProcess is exec - and programs are most likely
going to use ShellExecute to run external programs or URLs (ShellExecute
always invokes a single program - it's designed to launch documents - so
there is no "shell metacharacter" kind of vulnerability). That said,
another issue is that there is no standard algorithm to turn a Win32
command line into a C argc/argv. Visual C++'s libraries use this
(inferred from source code, not actually documented anywhere):
- a command line is a list of arguments alternating with whitespace
  - each argument goes into an argv element
  - the count of arguments goes in argc
- an argument is a list of tokens
- a token is either:
  - a list of characters that aren't space, tab or double quote
  - the contents of a quoted string. The syntax:
    - a double quote begins a quoted string
    - 2N backslashes + double quote = N backslashes + end of string
    - 2N + 1 backslashes + double quote = N backslashes + double quote
    - N backslashes + any other character = N backslashes + character
    - any other character = the character

(an interesting consequence being: 'command "arg"um"ent"' parses as {
"command", "argument" })

Not all compiler writers are that careful, though. I know for a fact
that Borland libraries have no way to handle double quotes embedded in
arguments (or, at least, not last time I checked). Oh, and Visual C++
libraries cannot handle a double quote in argv[0], by design. Thought
you'd like to know

In this particular case, I have to reluctantly agree with Microsoft, due
to my "output side bears the burden of validation" doctrine. We have a
by-the-books command injection issue here, not unlike a SQL injection or
an XSS. ShellExecute is not called ExecuteUri: like you presumably
filter out dangerous or unknown schemas (... you do, right?), you should
perform normalization or validation before passing a command string to a
function that is designed and documented to invoke arbitrary programs in
arbitrary ways, *not* safely execute an URI (if you use OLE's internet
support, on the other hand, you get to enjoy the same scheme/zone
policies as Internet Explorer. And naturally, it's a pain to use. The
Internet Explorer team must have a collective liver mass the size of Texas)

> A number of similar issues would be solved if Windows would respect the
> "command with one argument" setting, parsing the registry key just once.

Strings are the root of all evil. Whenever you pass structured data
around in a string, you are passing around _communism_. *Especially* if
the string is in some human-readable form. Think about it (incidentally,
it is precisely the reason why Internet Explorer 7 - specifically, OLE's
internet support - started passing URLs around as IUri objects, rather
than strings. Er, so that they are parsed only once, not the communism
thing)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/