"There is no standardized way to parse command lines, and no standardized way to escape them."
If that's the case, then windows is broken beyond repair.
Firefox does not chose how to parse the command line, that happens before main() is ever called. Firefox _does_ get argc and argv. So yet again, it's not Firefox's fault. It's just doing what it's told. Whatever it is between the exec()/spawn() (lauchyadayada()) and the child's main() must have _some_ specified behaviour. If MS do not specify that bahaviour then this is even more of an OS issue than I previously thought.
Or are you saying that firefox implements its own _setargv, to get around the above issue?
OK, I accept that the finger of blame could be pointed at Firefox for simply having too many features available on the command line. However, there must have been some (poorly thought out) reason why that was a desirable feature. Like executing javascript in e-mails... . Justify the removal of that feature to the satisfaction of the Firefox developers, and you'll have made your point. I'd even support you in this aim. Creaping featuritis is one of the biggest enemies of security.
It's *not* being called with _unsafe parameters_, it's being called with *paramters which aren't what the URL specified*.
You're right about the OS not doing the splitting of the string, that's the unix way. It's Firefox itself that splits the string int parameters, using conventions that are several decades old. However, that doesn't change where the responsibility for getting the command line correct lies. The fact that Firefox *must* interpret the string as being composed of several different parameters by following those old DOS conventions is because IE _created a sting which must be interpreted that way_.
Firefox has no choice, it's doing what IE told it.
If IE wants to pass spaces, quotes, piping, redirection, etc. in the command line, it should pass %20's etc. instead. If Firefox were to fail to interpret those in the URL, then that would be a firefox bug.
But the firefoxurl: schema is a red herring. Did you miss the gopher: demonstration last week?
It's the _same_ bug, just a different payload.
It's the application which creates the command line which is responsible for making sure it does exactly what was intended. That's IE, and Safari, and every other application which might want to have active links of these sorts. By the time Firefox sees the command line *it's already broken*.
*Wrong*. They do parse the information in their command line arguments _exactly_ as IE passes it to them. By the time Firefox sees the command line it is *already broken*.
IE constructs a command line that _cannot be parsed any other way_. It is IE's fault that it doesn't escape things like quote characters. No-one else can construct the string, only IE can, therefore it's only IE's responsibility. Of course, this goes all the way back to a Windows design issue whose roots are in DOS 1.0 - this is nothing to do with DDE or OLE, it's to do with process spawning and the parsing of command line arguments. Which is why Safari suffered from exactly the same flaw last week. You'd better check WinAmp and WMP, etc, as I'm sure they might be susceptible too.
What do you mean 'the handler'? The string in the registry or the program refered to in that string? If you think it's the string, then what's wrong with it, and what should be changed to fix it? (clue - nothing, anything you suggest I can provide an exploit for) Which makes you in the wrong. If you think it's the program, then you've completely misinterpreted what the problem is (see below). Which makes you in the wrong. If you think that it shouldn't even have added the new scheme and handler, then you've also missed the point - as demonstrated a week ago, it's nothing specific to this "firefoxurl:" scheme at all. Which also makes you in the wrong.
Conclusion: you're in the wrong.
This is a Windows OS design issue.
In particular you're wrong in your final comment, IE is *not* doing what you tell it, assuming that when a single string comes in from the user the user is telling the application to use that string as a single atomic unit. The aberrant application, in this case IE, but last week it was Safari, is ignoring common conventions about passing untrusted data to other applications. It makes no attempt to escape undesirable characters in the string. It lets the OS break that string into multiple strings. That is *only* IE's responsibility. Firefox *hasn't even seen* the original string by the time the error occurs, as it's the OS that parses that string into command line options.
Summary - for the n-th fucking time: IE gives an insecure string to the OS, OS calls firefox with the wrong parameters. Firefox does what it's told, having no choice, as it wasn't given a chance to know what the user actually wanted.
What do you mean by 'too powerful'? It's exactly as powerful as pretty much any other scheme handler. And amazingly, other scheme handlers are vulnerable too. See the exactly equivalenty Safari exploit from a week back. He used "gopher:" as the scheme, not "firefoxurl:". The error lies in the source browser to OS (i.e. the thing that actually spawns a process) interface. Windows specifies handler behaviour in terms of building a single string which is later parsed into individual arguments. Because of that, what should be a single parameter can break itself into many parameters, or even multiple commands separated by command separators or piping, or whatever.
You obviously don't understand how shells work. The bug is between IE and the shell. IE passes an untrusted string to the shell, the shell creates a command line to execute, and the shell executes it. There is _absolutely_nothing_ that firefox could do to prevent this exploit, apart from not registering such a scheme handler at all. All such registered scheme handlers are equally vulnerable from this IE bug, not just firefox.
Opera is perfectly capable of escaping characters that have meaning to the shell before passing the string to the shell to build the command line. Whether it does so is another matter. I don't have a windows machine on which to try. If it doesn't, then it's an Opera bug as well as an IE bug.
Yes, yes. This is an _IE_ bug, not a firefox bug. (I think you probably knew that though, but the people who wrote the summary and added tags certainly seem ignorant of that fact.)
Firefox just does what you tell it, and 'you' in this case is an IE which doesn't escape characters that have a meaning to the shell that is going to execute the command. So it's IE pwnx0ring (is that how you spell it?) the *shell* to get it to execute firefox with arbitrary parameters. I'd be willing to bet that there's a way to get it to execute arbitrary commands, not just firefox. I don't do WinDOS, but the unix equivalent would be something like
";/bin/arbitrary command ; echo "
At times I wish I actually had a windows machine to try these things out on.:-|
I've not read the full article, but I do remember that New Scientist ran an article almost identical to this in April 1987 or 1988. The year's not the important part of the date, if you follow my drift. They contructed NOT, NAND, NOR, etc. from ropes and ratchets.
It isn't. However, it's a rule that the English generally speak English. Which means that when you see English folk using English words you shouldn't pretend that they only mean what they mean in American.
The counter-arguments are already well publicised (upthread, probably half a dozen times), there's no need to repeat them again. Unless you think that microsoft PR sockpuppets are so stupid that they need stuff repeated to them vast numbers of times before it sinks in?
The US makes up <5% of the world's population. A distinction which may be common usage to USians may look like an arbitrary artifice to the other billion people who use the English language.
Straw poll here - UK: arbitrary artifice, DE: arbitrary artifice, FI: arbitrary artifice.
I was just about to call "STOP! AD HOMINEM!" As your argument isn't logically valid.
Then I followed this intersting line of reasoning:
His argument is not wrong _because_ he works for microsoft. I believe it to be wrong simply on the basis of raw facts. (I can remember seeing vastly more than 10 high severity issues in 6 months on Vista, and that includes the bundled packages that come in the default install such as internet exploder.) However, he's almost certainly deliberately misrepresenting the figures because he works for Microsoft. Therefore, major premise + minor premise => his argument is wrong _because_ he works for Microsoft.
Slashdot Mirror
"It choses to accept what gcc's startup code feeds it."
d _Prerequisites
I'm beginning to wonder if _anything_ you say can be taken as true now.
http://developer.mozilla.org/en/docs/Windows_Buil
Firefox builds with Visual Studio. So it accepts what MSVC's start-up code feeds it.
And no, it _should not_ change its command line parsing to make it different from the standard.
Some other program gave it a broken command line. End of story.
If the development tools provided by the OS vendor themself do not provide a de facto standard, I don't know what does.
"There is no standardized way to parse command lines, and no standardized way to escape them."
( VS.80).aspx
Microsoft seem to disagree with you:
http://msdn2.microsoft.com/en-us/library/a1y7w461
Of course, their system is braindead, but it *is* standardised.
What you say disagrees with what's in the analysis by the guy who found the bug:
0 day-exploit-in-2-hours/
http://larholm.com/2007/06/12/safari-for-windows-
He thinks that there's command line processing taking place. I have no ability to verify that,
I have no access to any windows machines.
Can you perform his "Fire up procexp, launch safari and watch the output." test and forward the pertinant output here?
And with IE rather than Safari?
"There is no standardized way to parse command lines, and no standardized way to escape them."
If that's the case, then windows is broken beyond repair.
Firefox does not chose how to parse the command line, that happens before main() is ever called. Firefox _does_ get argc and argv. So yet again, it's not Firefox's fault. It's just doing what it's told. Whatever it is between the exec()/spawn() (lauchyadayada()) and the child's main() must have _some_ specified behaviour. If MS do not specify that bahaviour then this is even more of an OS issue than I previously thought.
Or are you saying that firefox implements its own _setargv, to get around the above issue?
OK, I accept that the finger of blame could be pointed at Firefox for simply having too many features available on the command line. However, there must have been some (poorly thought out) reason why that was a desirable feature. Like executing javascript in e-mails... . Justify the removal of that feature to the satisfaction of the Firefox developers, and you'll have made your point. I'd even support you in this aim. Creaping featuritis is one of the biggest enemies of security.
It's *not* being called with _unsafe parameters_, it's being called with *paramters which aren't what the URL specified*.
You're right about the OS not doing the splitting of the string, that's the unix way. It's Firefox itself that splits the string int parameters, using conventions that are several decades old. However, that doesn't change where the responsibility for getting the command line correct lies. The fact that Firefox *must* interpret the string as being composed of several different parameters by following those old DOS conventions is because IE _created a sting which must be interpreted that way_.
Firefox has no choice, it's doing what IE told it.
If IE wants to pass spaces, quotes, piping, redirection, etc. in the command line, it should pass %20's etc. instead. If Firefox were to fail to interpret those in the URL, then that would be a firefox bug.
But the firefoxurl: schema is a red herring.
Did you miss the gopher: demonstration last week?
It's the _same_ bug, just a different payload.
It's the application which creates the command line which is responsible for making sure it does exactly what was intended. That's IE, and Safari, and every other application which might want to have active links of these sorts. By the time Firefox sees the command line *it's already broken*.
*Wrong*. They do parse the information in their command line arguments _exactly_ as IE passes it to them.
By the time Firefox sees the command line it is *already broken*.
IE constructs a command line that _cannot be parsed any other way_. It is IE's fault that it doesn't escape things like quote characters. No-one else can construct the string, only IE can, therefore it's only IE's responsibility. Of course, this goes all the way back to a Windows design issue whose roots are in DOS 1.0 - this is nothing to do with DDE or OLE, it's to do with process spawning and the parsing of command line arguments. Which is why Safari suffered from exactly the same flaw last week. You'd better check WinAmp and WMP, etc, as I'm sure they might be susceptible too.
What do you mean 'the handler'? The string in the registry or the program refered to in that string?
If you think it's the string, then what's wrong with it, and what should be changed to fix it? (clue - nothing, anything you suggest I can provide an exploit for) Which makes you in the wrong.
If you think it's the program, then you've completely misinterpreted what the problem is (see below). Which makes you in the wrong.
If you think that it shouldn't even have added the new scheme and handler, then you've also missed the point - as demonstrated a week ago, it's nothing specific to this "firefoxurl:" scheme at all. Which also makes you in the wrong.
Conclusion: you're in the wrong.
This is a Windows OS design issue.
In particular you're wrong in your final comment, IE is *not* doing what you tell it, assuming that when a single string comes in from the user the user is telling the application to use that string as a single atomic unit. The aberrant application, in this case IE, but last week it was Safari, is ignoring common conventions about passing untrusted data to other applications. It makes no attempt to escape undesirable characters in the string. It lets the OS break that string into multiple strings. That is *only* IE's responsibility. Firefox *hasn't even seen* the original string by the time the error occurs, as it's the OS that parses that string into command line options.
Summary - for the n-th fucking time:
IE gives an insecure string to the OS, OS calls firefox with the wrong parameters. Firefox does what it's told, having no choice, as it wasn't given a chance to know what the user actually wanted.
Exactly the same as the safari bug last week.
Notice where the guy with the 'Dell' logo placed his vote? Yup - tried to bury this story.
I wonder how many of the other demoters are shills or sock-puppets?
What do you mean by 'too powerful'? It's exactly as powerful as pretty much any other scheme handler. And amazingly, other scheme handlers are vulnerable too. See the exactly equivalenty Safari exploit from a week back. He used "gopher:" as the scheme, not "firefoxurl:". The error lies in the source browser to OS (i.e. the thing that actually spawns a process) interface. Windows specifies handler behaviour in terms of building a single string which is later parsed into individual arguments. Because of that, what should be a single parameter can break itself into many parameters, or even multiple commands separated by command separators or piping, or whatever.
You fucking idiot.
0 day-exploit-in-2-hours/
http://larholm.com/2007/06/12/safari-for-windows-
Same bug.
You obviously don't understand how shells work. The bug is between IE and the shell. IE passes an untrusted string to the shell, the shell creates a command line to execute, and the shell executes it. There is _absolutely_nothing_ that firefox could do to prevent this exploit, apart from not registering such a scheme handler at all. All such registered scheme handlers are equally vulnerable from this IE bug, not just firefox.
Opera is perfectly capable of escaping characters that have meaning to the shell before passing the string to the shell to build the command line. Whether it does so is another matter. I don't have a windows machine on which to try. If it doesn't, then it's an Opera bug as well as an IE bug.
"I guess I must be doing it wrong :D"
Is that smiley to demonstrate a new kind of "ooh, I'm so thick I can't follow simple instructions, and am proud of it" geek cred?
And why moderators up-modded the demonstration that you're too thick to follow instructions, I don't know.
Yes, yes. This is an _IE_ bug, not a firefox bug. (I think you probably knew that though, but the people who wrote the summary and added tags certainly seem ignorant of that fact.)
/bin/arbitrary command ; echo "
:-|
Firefox just does what you tell it, and 'you' in this case is an IE which doesn't escape characters that have a meaning to the shell that is going to execute the command. So it's IE pwnx0ring (is that how you spell it?) the *shell* to get it to execute firefox with arbitrary parameters. I'd be willing to bet that there's a way to get it to execute arbitrary commands, not just firefox. I don't do WinDOS, but the unix equivalent would be something like
";
At times I wish I actually had a windows machine to try these things out on.
Phil
I've not read the full article, but I do remember that New Scientist ran an article almost identical to this in April 1987 or 1988. The year's not the important part of the date, if you follow my drift. They contructed NOT, NAND, NOR, etc. from ropes and ratchets.
Did you miss the "in the x86 field" part a few posts back?
It isn't. However, it's a rule that the English generally speak English. Which means that when you see English folk using English words you shouldn't pretend that they only mean what they mean in American.
The counter-arguments are already well publicised (upthread, probably half a dozen times), there's no need to repeat them again. Unless you think that microsoft PR sockpuppets are so stupid that they need stuff repeated to them vast numbers of times before it sinks in?
The US makes up <5% of the world's population. A distinction which may be common usage to USians may look like an arbitrary artifice to the other billion people who use the English language.
Straw poll here - UK: arbitrary artifice, DE: arbitrary artifice, FI: arbitrary artifice.
Yes, I _question_ it, and I try to find an answer to it.
I do not assume a priori that he's wrong.
Last few places I lived in the UK, he'd have been right...
"Moreover, what does it mean?"
Often there are clues embedded in the letters:
People-ready business =
Purposely sees debian.
Reply "espouses debian".
Peruse a dope's bylines.
Depresses you, plebian.
So, when you're in jail, are you being imprisoned?
I was just about to call "STOP! AD HOMINEM!" As your argument isn't logically valid.
Then I followed this intersting line of reasoning:
His argument is not wrong _because_ he works for microsoft. I believe it to be wrong simply on the basis of raw facts. (I can remember seeing vastly more than 10 high severity issues in 6 months on Vista, and that includes the bundled packages that come in the default install such as internet exploder.) However, he's almost certainly deliberately misrepresenting the figures because he works for Microsoft. Therefore, major premise + minor premise => his argument is wrong _because_ he works for Microsoft.
Woh!