bugzilla.mozilla.org/show_bug.cgi?id=163767
and explected future exploits, allowing any registered protocol in the Windows registry is a time bomb. I can see that many people will want the functionality (that's what it's for, I guess), but some users will feel very uncomfortable, if any installed application could possibly the base for an attack. A major selling point for Mozilla and against MSIE is that it is not integrated that much with Windows. Add a pref so that the user can disable the lookup of protocol handlers outside of Mozilla. A pref to selectively enable some of these protocol handlers would be good (and it very cheap). then replace: 460 if (externalProtocol || NS_FAILED(rv)) with: if (externalProtocol || (NS_FAILED(rv) && useExternal)) That should do the trick.
Created an attachment (id=96113) Possible Fix, version 1 This compiles on Linux, but it's still untested. Somebody on Win32 please test, if it works as specified. Try eg the following: 1 Pick an uncommon URL scheme that you have a protocol handler for in the Windows registry and that you can trigger, eg hcp:. hcp, false (if you chose hcp:) 7 Start Mozilla, click on URL.
Ben Bucksch 2002-08-22 07:05 PDT ------- I think that you can delete the offending protocol handlers out of the Windowes registry, so there is a workaround. A full-blown UIis going to be hard, because we'll have to enumerate all available protocols handlers in the prefs dialog and offer a checkbox/listitem for each of them to allow users to selectively enable certain external protocol handlers.
ru 2002-08-22 07:26 PDT ------- >I think that you can delete the offending protocol handlers out of >the Windowes registry, so there is a workaround Oh, why must I edit registry to make my browser safe? More, "vbscript:" is probably required for internal Windows needs (MSHTML+VBScript engine is used in Microsoft Management Console and many other system utilities), and registry hacking can violate system control abilities.
ru 2002-08-22 08:00 PDT ------- We must understand, what did we add external protocol support for? Previous versions of Mozilla (including 11b) didn't it, and I was not a bit suffering from it.
Maybe, Mozilla plugins, such as RealAudio, might add another protocols and register it in Mozilla configuration files. But other protocols, which have no any relation to Mozilla componets and plugins, must be disabled - otherwise we shall go on a way of the Microsoft, aspiring to grasp immense and to push everything in their Internet Explorer.
net 2002-08-22 11:23 PDT ------- Is your patch the first implementation of this, or modifying the existing prefs that are supported? I'm working on URL scheme test cases right now, so I'm hoping you are going to say that the scheme handling is caps insensitive, as well as handling other aspects of scheme formating: (from RFC 2396:) scheme = alpha *( alpha | digit | "+" | "-" | "." Does anyone know how well the punctuation will work in a pref?
Ben Bucksch 2002-08-22 12:20 PDT ------- benc, you raise valid problems, but that's not exactly what this bug is about, it just makes them more obvious. The scheme-specific prefs are already there, I just added the useAnyExternal pref. I do intend to make some sort of limited UI for this, I am just not sure how.
David Bradley 2002-08-22 12:35 PDT ------- Ok, the last patch seems to work. useAnyExternal to true and MMS worked set both to true and MMS worked set both to false and MMS doesn't work One concern I have is that when useAnyExternal is absent or false we say the protocol isn't registered, which isn't exactly true. I know it's more work, but there probably should be a separate error message for this, rather than just reusing the protocol not registered one.
Once I removed them from there, it worked like you stated. This isn't the result of your patch, but the error paths are a little hard to follow in the code. For instance the: if (externalProtocol || (NS_FAILED(rv) && useAnyExternal) could be testing the rv of the GetBoolPref or the CallGetService, depending on the useAnyExternal pref.
useSystemDefaults" (default false), but it's only looked at in docshell and not where we actually need it. You might want to remove that one or combine it with the prefs you're working on. Darin: you, Mitch and I were looking at URIloader, Ben's poking at IOService. Which is a better place to trap these in your Necko design?
Sven Krohlas 2002-08-28 10:12 PDT ------- Well, a more general comment: Why do we need to support starting another application, when we stumble over an external protocol?
Darin Fisher (IBM) 2002-08-28 13:31 PDT ------- IOService is a good catch-all i think. URL strings get converted to nsIURI objects via nsIOService, and that is where we decide to talk to the default protocol handler when we encounter an unknown protocol scheme.
Boris Zbarsky (out of town June 14 -- July 11, no email then) 2002-08-28 15:03 PDT ------- > Why do we need to support starting another application, when we stumble overan > external protocol? So that streaming medial players (realplayer in particular) will work correctly. This is just like asking why we need to start another application when we encounter a type we don't handle internally or via plugin...
Darin Fisher (IBM) 2002-08-28 16:07 PDT ------- then those streaming media players are currently broken on linux because we ignore unknown protocol schemes under linux. seems mac, windows, and os2 each resort to launching external apps.
This data (in our case, playlist) may contain URLs with internal WinAmp protocols. I think, this is safe and pellucid alternative in comparison with calling non-internal protocols directly from Mozilla.
Boris Zbarsky (out of town June 14 -- July 11, no email then) 2002-08-29 00:08 PDT ------- > 0 Streaming application, such as WinAmp, installs as plugin to handle specific > MIME-type (eg WinAmp playlist - "audio/mpegurl"). "As plugin" has its own issues, btw, like running in the same process space as the browser....
com/bid/5445 But if user installs one or another plugin, he understands that if his system will be cracked via similar vulns, it will be guilt of plugin, not a browser.
ru 2002-08-29 00:58 PDT ------- Another consideration - by now plugins can be (and are by default) disabled in e-mail messages. This prevents using plugin vulnerabilities for personalized attacks.
Sven Krohlas 2002-08-29 01:01 PDT ------- For me it was always the following: if my browser doesn't understand the protocol or file type it tries to find a plug-in who can cope with it. If it can't find one, then I get a error message or asks me to save the file. That's the way it was working, and that's the way it should work. A user should be able to cut and paste a link into another application if he likes to view things linked by protocols Mozilla and its plug-ins can't handle. If we have a look at the registry to find a corresponding application (and I'm strongly against it) it should look like the following: "Mozilla can't cope with the URL you opened. But we found another application on your computer which could. There is a reason I recommend Mozilla to my friends: security. And they slowly start to understand what it means, since some virii were happyly exchanged between them via Outlook. Now some of them don't use Outlook anymore (you may guess what they are using now :) If they catch the fact, thet we can have the same (or nearly) problems in Mozilla, why should they use it? If some Mozilla distributors want this feature: just take the code and add it.
is safe and pellucid alternative > in comparison with calling non-internal protocols directly from Mozilla. Calling external apps with data from the net is dangerous, no matter, if using strange protocols or file types. Add the pref, default it to use external protocols, make a UI, and we can be all happy. If you want security, use Beonex Communicator (or let your friends use it) :-). If that's not enough for you, please open another bug to argue about the default pref.
ru 2002-08-29 08:22 PDT ------- >Add the pref, default it to use external protocols, >make a UI, and we can be all happy Main question is: for what, generally, we need to use external non-standard prot...
|
http://csua.com/feed/