I'm afraid I disagree. There are plenty of places where you might want to use this, for instance in order to display content generated by an application that is installed on the user's machine in a web interface. Most such applications currently use IE as their browser, but the ability for them to use Mozilla based browsers is quite important, I think.
#1 talks about an option to disable external protocol handlers (URI schemes) by default. I have to say that would be the right thing to do. "Secure by default" is the correct approach.
Unfortunately, external protocol handlers are an important feature which, if disabled, would cause many people to feel that Mozilla was unusable as a browser. They are important for anyone who wants to use Mozilla alongside instant messaging applications, P2P file sharing applications, and other similar networking utilities. They can also be used to implement user interfaces for multimedia CD-ROMs (see my parenthetical remark below).
#2 talks about an approach that uses context to determine if an external handler should be invokved.
The approach suggested in this bug would have prevented any automatic exploitation of this hole. But it's easy enough, as stated in one of the comments, to trick a user into clicking a link. It would have been helpful, and makes some sense (although the case isn't as clear cut as suggested in some of the comments in that bug - you can have an external protocol handler supply data to the application, and this would be useful for instance to allow Mozilla to view web pages generated by a DLL installed locally without needing to run an HTTP server).
No browser can avoid that problem without just disabling the ability to download and run programs, full stop. And as millions of users _want_ a browser in order that they can download and run programs, preventing that would mean instant commercial failure.
The problem is, this bug didn't suggest a correct fix to the problem. Merely stopping them from being executed automatically doesn't actually solve it -- you would still be able to write a link that executed an arbitrary program, or anything like that. And that's nearly as big a problem!
In that situation, it still seems negligent to me when you're failing to fix an exploitable hole once it's come to your attention and when there's no disadvantage to doing so.
As far as I can see from a quick read of the referenced bug page, they didn't _know_ it was exploitable until the day before yesterday. Not fixing something that you don't know about doesn't seem negligent.
Do they guarantee anywhere that their handler API is secure against arbitrary Internet strings?
No. But they don't mention that it isn't. There's even a page about security of the API where it doesn't mention anything like this.
Mozilla should just handle the protocols it knows to handle and give an error message for everything else. What it is actually doing, handing off unknown things to the OS is just the sort of OS integration that causes so many problems for Microsoft applications as well.
If it did this, many users would stop using it. Integration with plug-in URI handlers is essential for a modern computing environment, as they are used for important functions of large amounts of very popular modern software, including instant messaging applications and P2P filesharing applications.
Whitelisting is the way to go (e.g. it should pop up a message on first use of each scheme saying that the object you have requested to use is an external one and may cause security problems, display as much information as the OS can provide about how it will be handled, and let the user make up his/her mind).
So that's 384mA current consumption. To get through a 12 hour day (hardly impressibe battery life), you would need a battery with a 12*0.384 = 4.6Ah capacity. Your average huge+chunky laptop battery won't provide more than 2.5AH.
Well, yes. But an average huge+chunky laptop battery provides that 2.5AH at either 12 or 18 volts, depending on your model of laptop. Running an LED display will require no more than 3v, possible less, depending on the type of semiconducter in use. 4 standard AA batteries should be adequate to provide 4.6Ah at 3v.
(The moral of this story: amp-hours is a useless unit).
His word processor made a mistake!? What did it do?
Perhaps he received a document on the basis of which he had to make his decision with "Show revisions" on, and thought that the highlighted changed text was the actual text of the proposal he was voting on.
Any member country can effectively 'remove' its signature from the various treaties that indicate membership of the EU. If it was then desired, a new EU could be set up by a consensus of countries who had taken that action.
I would strongly recommend, for your own safety, that you do not use Kazaa to download software.
Kazaa (and any other software that uses the same networking protocols) uses a very simple file hashing mechanism to identify files. It is trivially easy to produce a modified file that confuses Kazaa into thinking it is the same as an original source file. This could be used to plant trojan horse software into your download.
If you insist on downloading software, use a network, such as gnutella, that uses a secure hashing algorithm (gnutella uses SHA1 -- edonkey et al use MD4 which is not as safe, but still much better than kazaa) to verify the file you downloaded is the one you wanted. And look up those SHA1 codes on a suitable catalogue web site (there are plenty of links from any P2P related site) before running the downloaded program.
Until P2P offers feedback ratings on a combo hash and filename, there's little to be done with it to verify safety except to do one's own "best effort" and pray no one else is able to hide things better than you are able to find them.
There are plenty of web sites that provide this kind of information. Some P2P software supports it internally, also. So stop saying "until" -- that time is now.
Even if you got the originating number from the telescum's PBX, you probably could not call them back or otherwise do anything useful; those numbers do not point to incoming lines.
I think his theory is you can use them to avoid anwering when they next call you...
It's intentional. You're supposed to be able to use non-geographic numbers that route back onto any of your own DIDs, and your line-providing telco doesn't necessarily know about these.
I don't know about the US networks, but in the UK we operate a system where non-geographic (e.g. 0800, 0845, 0870 numbers that are billed at special rates) numbers are mapped onto ordinary lines. Your line providing telco doesn't need to know about the arrangement. One feature of a PBX is to set your outgoing CLID to one of your alternative numbers that will be forwarded to your ordinary telco lines.
Think of it like the 'from' address in your e-mails. As long as its an address that gets back to you, it doesn't really matter which you use.
The same sort of system would be needed to prevent abuse -- a list of acceptable source lines associated with each number to prevent CLID hijacking.
The interesting part is that you don't have to go out and get a lot of expensive telephone equipment to intercept blocked numbers and impersonate someone else's number.
A personal computer and a PBX are now in approximately the same price bracket.
The law states that in order to be in violation, it has to be proven that the P2P application's only method of commercially viability is by inducing copyright violations.
No it doesn't. In fact, that's the current legal situation, and why Napster ended up being shut down (its only technically viable use was to distribute music, of which such a large majority was copyright violation that it was deemed to be the only viable use) while Kazaa was allowed to continue running (largely due to the reasonably large number of legally distributed pron videos on the system...).
What this does is change it so that it doesn't have to be proven that that's the only way it can be viable, but rather that the author's intent in developing it was that it would be used for copyright violation. And this doesn't have to be proven beyond reasonable doubt, either, merely enough evidence to convince a 'reasonable person' (a rather interesting legal fiction, IMO) that it was the case.
This kind of legislation makes me glad I don't live in the US.
Yes, but it only works for already protected content -- it doesn't apply in the general case. And there's little point in distributing protected content anyway because it's tied to your unique keys.
There is no way that it can tell whether, for instance, the sound that it is recording through the analogue input of my sound card is me practising with my guitar or me ripping off a professionally produced CD. I ought to be able to authorise copies of the former, the record company that produced the CD can authorise copies of the latter. But my computer doesn't know which file is which, and there is no way that it ever can.
Slashdot Mirror
I'm afraid I disagree. There are plenty of places where you might want to use this, for instance in order to display content generated by an application that is installed on the user's machine in a web interface. Most such applications currently use IE as their browser, but the ability for them to use Mozilla based browsers is quite important, I think.
#1 talks about an option to disable external protocol handlers (URI schemes) by default. I have to say that would be the right thing to do. "Secure by default" is the correct approach.
Unfortunately, external protocol handlers are an important feature which, if disabled, would cause many people to feel that Mozilla was unusable as a browser. They are important for anyone who wants to use Mozilla alongside instant messaging applications, P2P file sharing applications, and other similar networking utilities. They can also be used to implement user interfaces for multimedia CD-ROMs (see my parenthetical remark below).
#2 talks about an approach that uses context to determine if an external handler should be invokved.
The approach suggested in this bug would have prevented any automatic exploitation of this hole. But it's easy enough, as stated in one of the comments, to trick a user into clicking a link. It would have been helpful, and makes some sense (although the case isn't as clear cut as suggested in some of the comments in that bug - you can have an external protocol handler supply data to the application, and this would be useful for instance to allow Mozilla to view web pages generated by a DLL installed locally without needing to run an HTTP server).
True. But many other file sharing apps use such links. magnet:*, ed2k:*, gnutella:* and others are all in common use.
Hello. I have /bin, /sbin and /usr directories on my Windows 2000 machine. And they have useful stuff in them, too...
No browser can avoid that problem without just disabling the ability to download and run programs, full stop. And as millions of users _want_ a browser in order that they can download and run programs, preventing that would mean instant commercial failure.
People may laugh, but 98 is a great OS for one reason - it doesn't actually do anything. Can't exploit an OS that doesn't do anything.
If this other vendor is right that people want no more than monthly patches, such a fix may have to wait weeks.
When two independent security flaws in Mozilla are discovered within 3 weeks of each other, get back to me.
The problem is, this bug didn't suggest a correct fix to the problem. Merely stopping them from being executed automatically doesn't actually solve it -- you would still be able to write a link that executed an arbitrary program, or anything like that. And that's nearly as big a problem!
I don't believe it handles SFTP, though. I could write an SFTP handler DLL for Windows and register it, at which point would work.
In that situation, it still seems negligent to me when you're failing to fix an exploitable hole once it's come to your attention and when there's no disadvantage to doing so.
As far as I can see from a quick read of the referenced bug page, they didn't _know_ it was exploitable until the day before yesterday. Not fixing something that you don't know about doesn't seem negligent.
Do they guarantee anywhere that their handler API is secure against arbitrary Internet strings?
No. But they don't mention that it isn't. There's even a page about security of the API where it doesn't mention anything like this.
Mozilla should just handle the protocols it knows to handle and give an error message for everything else. What it is actually doing, handing off unknown things to the OS is just the sort of OS integration that causes so many problems for Microsoft applications as well.
If it did this, many users would stop using it. Integration with plug-in URI handlers is essential for a modern computing environment, as they are used for important functions of large amounts of very popular modern software, including instant messaging applications and P2P filesharing applications.
Whitelisting is the way to go (e.g. it should pop up a message on first use of each scheme saying that the object you have requested to use is an external one and may cause security problems, display as much information as the OS can provide about how it will be handled, and let the user make up his/her mind).
Actually, the existence of shell: isn't mentioned in the referenced bug or any linked from it until the day before yesterday.
Admittedly, the 2-year old report does stress that calling external protocol handlers can be insecure and gives examples, but shell: isn't mentioned.
So that's 384mA current consumption. To get through a 12 hour day (hardly impressibe battery life), you would need a battery with a 12*0.384 = 4.6Ah capacity. Your average huge+chunky laptop battery won't provide more than 2.5AH.
Well, yes. But an average huge+chunky laptop battery provides that 2.5AH at either 12 or 18 volts, depending on your model of laptop. Running an LED display will require no more than 3v, possible less, depending on the type of semiconducter in use. 4 standard AA batteries should be adequate to provide 4.6Ah at 3v.
(The moral of this story: amp-hours is a useless unit).
Displaying cleavage would attract every man's attention. This way, you get to be picky.
His word processor made a mistake!? What did it do?
Perhaps he received a document on the basis of which he had to make his decision with "Show revisions" on, and thought that the highlighted changed text was the actual text of the proposal he was voting on.
Any member country can effectively 'remove' its signature from the various treaties that indicate membership of the EU. If it was then desired, a new EU could be set up by a consensus of countries who had taken that action.
> Visual Studio is the best development suite I've used.
I'm hooked on Anjuta. Others may prefer KDevelop.
Neither of those programs can be used for Windows based development. This is a definite disadvantage for people who are trying to work under Windows.
I would strongly recommend, for your own safety, that you do not use Kazaa to download software.
Kazaa (and any other software that uses the same networking protocols) uses a very simple file hashing mechanism to identify files. It is trivially easy to produce a modified file that confuses Kazaa into thinking it is the same as an original source file. This could be used to plant trojan horse software into your download.
If you insist on downloading software, use a network, such as gnutella, that uses a secure hashing algorithm (gnutella uses SHA1 -- edonkey et al use MD4 which is not as safe, but still much better than kazaa) to verify the file you downloaded is the one you wanted. And look up those SHA1 codes on a suitable catalogue web site (there are plenty of links from any P2P related site) before running the downloaded program.
Until P2P offers feedback ratings on a combo hash and filename, there's little to be done with it to verify safety except to do one's own "best effort" and pray no one else is able to hide things better than you are able to find them.
There are plenty of web sites that provide this kind of information. Some P2P software supports it internally, also. So stop saying "until" -- that time is now.
Even if you got the originating number from the telescum's PBX, you probably could not call them back or otherwise do anything useful; those numbers do not point to incoming lines.
I think his theory is you can use them to avoid anwering when they next call you...
It's intentional. You're supposed to be able to use non-geographic numbers that route back onto any of your own DIDs, and your line-providing telco doesn't necessarily know about these.
I don't know about the US networks, but in the UK we operate a system where non-geographic (e.g. 0800, 0845, 0870 numbers that are billed at special rates) numbers are mapped onto ordinary lines. Your line providing telco doesn't need to know about the arrangement. One feature of a PBX is to set your outgoing CLID to one of your alternative numbers that will be forwarded to your ordinary telco lines.
Think of it like the 'from' address in your e-mails. As long as its an address that gets back to you, it doesn't really matter which you use.
The same sort of system would be needed to prevent abuse -- a list of acceptable source lines associated with each number to prevent CLID hijacking.
The interesting part is that you don't have to go out and get a lot of expensive telephone equipment to intercept blocked numbers and impersonate someone else's number.
A personal computer and a PBX are now in approximately the same price bracket.
The law states that in order to be in violation, it has to be proven that the P2P application's only method of commercially viability is by inducing copyright violations.
No it doesn't. In fact, that's the current legal situation, and why Napster ended up being shut down (its only technically viable use was to distribute music, of which such a large majority was copyright violation that it was deemed to be the only viable use) while Kazaa was allowed to continue running (largely due to the reasonably large number of legally distributed pron videos on the system...).
What this does is change it so that it doesn't have to be proven that that's the only way it can be viable, but rather that the author's intent in developing it was that it would be used for copyright violation. And this doesn't have to be proven beyond reasonable doubt, either, merely enough evidence to convince a 'reasonable person' (a rather interesting legal fiction, IMO) that it was the case.
This kind of legislation makes me glad I don't live in the US.
Yes, but it only works for already protected content -- it doesn't apply in the general case. And there's little point in distributing protected content anyway because it's tied to your unique keys.
There is no way that it can tell whether, for instance, the sound that it is recording through the analogue input of my sound card is me practising with my guitar or me ripping off a professionally produced CD. I ought to be able to authorise copies of the former, the record company that produced the CD can authorise copies of the latter. But my computer doesn't know which file is which, and there is no way that it ever can.