Comments on: Handling URL protocol handlers http://larholm.com/2007/07/25/handling-url-protocol-handlers/ Me, myself and I Thu, 11 Mar 2010 03:37:53 +0000 http://wordpress.org/?v=2.6.2 By: Thor Larholm http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1106 Thor Larholm Thu, 26 Jul 2007 01:11:54 +0000 http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1106 Aaron, I linked to them in my previous comment, but approved your comment as well to better point them out :) Regards Thor Larholm Aaron, I linked to them in my previous comment, but approved your comment as well to better point them out :)

Regards
Thor Larholm

]]> By: Aaron Margosis http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1105 Aaron Margosis Wed, 25 Jul 2007 23:55:07 +0000 http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1105 In your reply to Alun's comment, it sounds as though you're arguing for breaking compatibility with existing ("outdated") protocol handlers by changing what urlmon.dll passes to them, even though all of them not written by Mozilla may be correct the way they are. This won't help security -- if handlers are not validating their input, the URI provider will have innumerable ways to exploit them, whether urlmon.dll encodes spaces or not. In your reply to Alun’s comment, it sounds as though you’re arguing for breaking compatibility with existing (”outdated”) protocol handlers by changing what urlmon.dll passes to them, even though all of them not written by Mozilla may be correct the way they are. This won’t help security — if handlers are not validating their input, the URI provider will have innumerable ways to exploit them, whether urlmon.dll encodes spaces or not.

]]> By: Aaron Margosis http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1099 Aaron Margosis Wed, 25 Jul 2007 22:52:28 +0000 http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1099 You should link to Alun Jones' insightful posts as well: http://msmvps.com/blogs/alunj/archive/2007/07/22/firefoxurl-url-vulnerability.aspx http://msmvps.com/blogs/alunj/archive/2007/07/23/firefoxurl-part-ii.aspx You should link to Alun Jones’ insightful posts as well:
http://msmvps.com/blogs/alunj/archive/2007/07/22/firefoxurl-url-vulnerability.aspx
http://msmvps.com/blogs/alunj/archive/2007/07/23/firefoxurl-part-ii.aspx

]]> By: Thor Larholm http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1097 Thor Larholm Wed, 25 Jul 2007 22:26:03 +0000 http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1097 Alun, I don't attribute the parsing to some theorized process, but I do believe that IE should implement some form of minimally invasive data encoding before handing off the string to the protocol handler. (For the other readers here, go read Aluns <a href="http://msmvps.com/blogs/alunj/archive/2007/07/22/firefoxurl-url-vulnerability.aspx" rel="nofollow">nice </a> <a href="http://msmvps.com/blogs/alunj/archive/2007/07/23/firefoxurl-part-ii.aspx" rel="nofollow">posts</a>.) I'm not suggesting that you take the route of Safari and indiscriminately URL encode the entire input string, which brings down the data delivery from 100% to some 25% (take a look at it, it's horrible). I just really think that we will have to settle for some minor inconvenience by accommodating a few outdated protocol handlers through some minor data encoding changes. Even outlook gets this wrong. Standards and recommendations change over time and it's time for us to be more specific about what we sent to all of those random protocol handlers that are present on a system. We have long since disabled SMTP relaying even though it was part of the standard and we just have to face the fact that most protocol handlers are not parsing their input correctly, but instead parsing the input as if it were a console command line. Regards Thor Larholm Alun, I don’t attribute the parsing to some theorized process, but I do believe that IE should implement some form of minimally invasive data encoding before handing off the string to the protocol handler. (For the other readers here, go read Aluns nice posts.)

I’m not suggesting that you take the route of Safari and indiscriminately URL encode the entire input string, which brings down the data delivery from 100% to some 25% (take a look at it, it’s horrible).

I just really think that we will have to settle for some minor inconvenience by accommodating a few outdated protocol handlers through some minor data encoding changes. Even outlook gets this wrong.

Standards and recommendations change over time and it’s time for us to be more specific about what we sent to all of those random protocol handlers that are present on a system. We have long since disabled SMTP relaying even though it was part of the standard and we just have to face the fact that most protocol handlers are not parsing their input correctly, but instead parsing the input as if it were a console command line.

Regards
Thor Larholm

]]> By: Alun Jones http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1096 Alun Jones Wed, 25 Jul 2007 22:10:38 +0000 http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1096 "Ideally the protocol handler should receive the input 100% unaltered," you say, and on this I agree with that same 100%. However, you are clinging to the notion that "Quotes have a special meaning on the command line and can be used to separate arguments". This is incorrect. Quotes have a special meaning to batch files, and to C/C++ console-mode programs, and possibly a number of others. That is a side-effect of the language chosen, not of the 'command line'. Go look at stdargv.c in the C RTL - it parses a monolithic command line into an array of strings to hand it to the C main() function. If you're writing a Win32 application, its WinMain() function receives a single, monolithic command line - unprocessed, uninterpreted, for the program to parse as it sees fit - even to completely ignore common argument separation syntax. It is therefore the choice of the protocol handler's author whether to submit to the run-time library's command line parser, or to treat the command line as a single string. Look at the definition of WinMain. http://msdn2.microsoft.com/en-us/library/ms633559.aspx - a single LPSTR, null-terminated (yeah, play with that) If you're writing a C/C++ program and want different command line parsing semantics, write your own _setargv routine, as described in http://msdn2.microsoft.com/en-us/library/ms857738.aspx If you read my blog, you wouldn't have attributed the parsing of arguments to some process that you theorise to exist between Internet Explorer's call of ShellExecute and the loading of the executable's code. :) “Ideally the protocol handler should receive the input 100% unaltered,” you say, and on this I agree with that same 100%. However, you are clinging to the notion that “Quotes have a special meaning on the command line and can be used to separate arguments”. This is incorrect. Quotes have a special meaning to batch files, and to C/C++ console-mode programs, and possibly a number of others. That is a side-effect of the language chosen, not of the ‘command line’. Go look at stdargv.c in the C RTL - it parses a monolithic command line into an array of strings to hand it to the C main() function. If you’re writing a Win32 application, its WinMain() function receives a single, monolithic command line - unprocessed, uninterpreted, for the program to parse as it sees fit - even to completely ignore common argument separation syntax.
It is therefore the choice of the protocol handler’s author whether to submit to the run-time library’s command line parser, or to treat the command line as a single string.
Look at the definition of WinMain. http://msdn2.microsoft.com/en-us/library/ms633559.aspx - a single LPSTR, null-terminated (yeah, play with that)
If you’re writing a C/C++ program and want different command line parsing semantics, write your own _setargv routine, as described in http://msdn2.microsoft.com/en-us/library/ms857738.aspx
If you read my blog, you wouldn’t have attributed the parsing of arguments to some process that you theorise to exist between Internet Explorer’s call of ShellExecute and the loading of the executable’s code. :)

]]> By: Thor Larholm http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1093 Thor Larholm Wed, 25 Jul 2007 19:55:22 +0000 http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1093 Ideally the protocol handler should receive the input 100% unaltered. The problem is that IE and Firefox do not encode that input properly for the transport channel, which in this case is the command line, and therefor the input data alters the operation of the transport channel. This is no different than HTTP Response Splitting where a literal line break would alter the operation of the transport channel (HTTP) and where the receiving party would get 100% unaltered input if the line break was properly escaped for the transport channel (%0A%0D). Quotes have a special meaning on the command line and can be used to separate arguments, which is why you have escape characters such as \ or ^. something.exe "test^" -arg ^"value" would hand off a single argument to something.exe, and that argument would be the literal string test" -arg "value Regards Thor Larholm Ideally the protocol handler should receive the input 100% unaltered. The problem is that IE and Firefox do not encode that input properly for the transport channel, which in this case is the command line, and therefor the input data alters the operation of the transport channel.

This is no different than HTTP Response Splitting where a literal line break would alter the operation of the transport channel (HTTP) and where the receiving party would get 100% unaltered input if the line break was properly escaped for the transport channel (%0A%0D).

Quotes have a special meaning on the command line and can be used to separate arguments, which is why you have escape characters such as \ or ^.

something.exe “test^” -arg ^”value”

would hand off a single argument to something.exe, and that argument would be the literal string

test” -arg “value

Regards
Thor Larholm

]]> By: Aviv Raff http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1091 Aviv Raff Wed, 25 Jul 2007 19:20:33 +0000 http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1091 Skype also registers itself under the "skype:" protocol handler. One of the things you can do with this is to shutdown user's Skype from remote. I've published a proof of concept on my blog: http://aviv.raffon.net/2007/07/10/CrossApplicationScriptingWhoseFaultIsIt.aspx Skype also registers itself under the “skype:” protocol handler.
One of the things you can do with this is to shutdown user’s Skype from remote.
I’ve published a proof of concept on my blog: http://aviv.raffon.net/2007/07/10/CrossApplicationScriptingWhoseFaultIsIt.aspx

]]> By: Larholm.com - Me, myself and I » Mozilla Protocol Abuse http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1088 Larholm.com - Me, myself and I » Mozilla Protocol Abuse Wed, 25 Jul 2007 18:37:19 +0000 http://larholm.com/2007/07/25/handling-url-protocol-handlers/#comment-1088 [...] Handling URL protocol handlers [...] [...] Handling URL protocol handlers [...]

]]>