Hmmm, well, if the company gets bought or divvied up then you are out of luck if you accepted one of those horrible "we can change the deal at any time in any way for any reason or none whatsoever" clauses. I'd like to see such overbroad provisions declared unenforceable.
The rogue employee case is pretty simple: 100 million angry customers sue him into oblivion.
There, you see? We may need *more* greenhouse gases, not less.
(What we really need is to figure out how to modulate the atmosphere to trim up dangerous temperature excursions in *either* direction, without going overboard and suffocating ourselves.)
Got it! Killer bees, maddened by the loss of directional sense, cause volcanoes to erupt all over the world simultaneously, attracting aliens whose invasion is stopped in the penultimate scene when they are wiped out by the asteroids.
(In the sequel, rotting alien corpses trigger global warming (in a matter of days) which sets off a worldwide spate of tidal waves. Then, thinking humans are responsible for the mess, the loggerhead turtles attack!)
Don't forget *secondary* radiation. Proton whacks some random molecule in the atmosphere; molecule absorbs energy from it; molecule releases energy as photon. Kind of like a laser or an X-ray tube. So even your particle shielding can kill you if you don't use it properly.
I'd say that, if you're still running Win9x, you're not an enterprise customer. There's a difference between "enterprise computing customer" and "we have a tremendous pile of unmanageable, unsecurable, toy computers".
Yeah, I've been heard to suggest that, once a work has been published, refusal to continue publishing for more than some reasonable period (say, two years) should automatically place the work into the public domain. (There'd have to be some rule about not just raising the price 1000x to keep the work without ever having to actually sell it again.)
Where have you been? Identification==evil. Everyone should be completely anonymous all the time. Anyone who wants to know anything about you is up to no good.
This reminds me that I'm curious as to whether there's any principle in law (anywhere) which would enable one to treat the IP in an orphaned product as abandoned property? At least to the extent that, if a manufacturer refuses to service the product anymore, one is automatically protected from any claims the manufacturer may make when one reverse-engineers just the bits he needs to repair it himself?
OTOH Toyota used to give you a card with the car to facilitate ordering the shop manuals for said car. Not too expensive either. (Dunno if they still do, as I haven't bought a car in several years.)
Cure: "Thanks for installing our tape robot. Now give us the passwords. All of them. It *is* our property now, is it not? No, I'm not signing your form until you deliver everything we purchased."
"The maintenance password is the same on all of them? Tsk tsk, what an error. Okay, change it to $WHATEVER on this one."
"You refuse? Very well. Since the product is (for us) not fully functional, we revoke our acceptance. Please take it away."
You misunderstand. The Carpenter and the Contractor are both working for Mozilla.
Returning to the software realm, Mozilla does need to use ShellExecute() but they certainly do not need to blindly use it whenever a URI scheme is not recognized by their code. Instead it should be used only when the scheme *is* recognized and known not to be implemented by their code; otherwise punt the decision to the user with appropriate scary warnings. Let the user also decide whether to push the "add this scheme to the safe list" button if he dare.
It is wrong to cast this as an either/or, be secure or be usable matter. The browser's behavior can, and always could, be made much safer regardless of whether anything is ever done to ShellExecute().
Carpenter: "Boss, did you notice that our standard house plans all specify doors with no locks? We've installed 234 front doors this year without locks."
Contractor: "WONTFIX. Let me know when there's a specific exploit."
The setuid bit is not inherently damaging. A program which copies stdin to stdout is not inherently damaging. 'chmod u+s/bin/cp' is, however, incredibly stupid.
In Mozilla's case, the problem was combining a facility for fetching untrused code off the Internet and a facility for interpreting arbitrary commands. ShellExecute() by itself is insufficient to yield a remote exploit; a web browser by itself is insufficient to yield a remote exploit; a web browser that hands things off to ShellExecute() uncritically *does* permit a remote exploit if ShellExecute() knows how to execute arbitrary commands (and, as it turns out, it does).
So? "The URI handler in MS Windows is insecure." "Uh-oh. Don't use it, then. Or find a way to only use it securely." Not, "not our problem, MS should fix it." Notice how quickly it became "our problem" when a more specific exploit was noted.
I agree that the specific vulnerability was not known back then, but I disagree on the burden of blame nonetheless. If someone had pointed out to me that our project was currently handing untested web documents over to code not under our control which is ill-defined and could be extended without our knowledge, I would have considered it DROPEVERYTHING, not WONTFIX.
One thing that bugs me about this particular problem is that the Mozilla folk spend so much time relentlessly creating "cross-platform" reimplementations of stuff that could safely and sanely be left to the platform (such as storing user preferences) and yet here, in a very security-sensitive place, they happily glommed onto a platform-specific thingy which turned out to have unintended consequences. I am negatively impressed.
Gotta keep in mind that contemporary "Windows" is a protected subsystem running atop NT just as older versions were a shell running atop DOS. It's the kernel that is essentially VMS mk II, and it *is* possible to build decently secure systems on it. The Win32 subsystem, OTOH, suffers from unwholesome tradeoffs of security for convenience. There's not a lot that any kernel can do if privileged code works against it.
This is not a problem with restricted access; it's a problem with third-party app.s written without any consideration of MS Windows' security model or the fundamental requirements of a multiuser runtime environment. Those app.s "break" because they were broken as designed.
It's not hard to do it right. Don't depend on being able to write anywhere outside of %USERPROFILE%. Don't depend on being able to write anywhere outside of HKEY_CURRENT_USER. Put user files in %USERPROFILE%\Application Data\name-of-company\name-of-app. Put user settings in HKCU\Software\name-of-company\name-of-app. Put scratch files in %TEMP%. Problem solved. This has been the case since Windows 95 -- there is no excuse for not knowing it today.
The "more to it" is Windows' definition of "execute". This is a consequence of making documents "executable" by having the shell associate them automagically with the applications which handle them. So you ask Windows to "execute" a.DOC and the shell says to itself, "hmmm, look up.DOC -- ahh, yes, that really means I should launch Word and fake a command line naming FOO.DOC as its input."
(It's actually somewhat more complicated, since Word is an OLE server, but that's the basic model.)
This is really handy when you know what's in the file. You doubleclick on some document and Explorer uses ShellExecute() to figure out what to actually run on it. You can also START the same document in a command window and the same thing happens.
Unfortunately, when you *don't* know what's in the file, because you fetched it from some random website, the same idea becomes really handy for people who mean to do you harm, because now it works for them, too, *on your computer*. Applications which fetch things that are beyond your control must be much more picky about what is done with them. Just sucking down some random file from the other side of the world and handing it to ShellExecute() is not wise.
On Linux, on the other hand, if you try to exec() a word processing document (say), the kernel will burp back its equivalent of, "that is not a program, master." The tricky bit is that, as mentioned elsewhere, this *does* work for shell scripts, which are the subject of a special case in the kernel code. You can also add other special cases, but I've only ever seen that mechanism used to make Java classes "executable". It's not done with anything like the enthusiasm you see in MS Windows. Probably sooner or later the special case will be factored out of the kernel and replaced with a userspace implementation that you can omit to have added to the list at boot time if you don't mind breaking "shebang" scripts.
"There are other minor issues, like WinAmp doesn't save its preferences into my profile, but rather saves them to the Program Files\WinAmp directory. Granting permissions on the necessary files is not particularly difficult, however."
Poor design of WinAmp, then. Programmers who know their way around Windows have known for a decade where the user pref.s go (because, for once, Microsoft told them), and their code doesn't have this problem. There are, sadly, hundreds of incorrect designs like what you mention. At least you're attacking the problem in the least incorrect way, instead of making everybody a Power User as one is usually told to do by the clueless.
What seems to be going on is that Mozilla-for-MS-Windows uses the time-honored method of punting unimplemented file types to ShellExecute() in the hope that Microsoft has provided a handler. The problem with this is that Microsoft *has* provided handlers for all sorts of things you do *not* want others to be able to run on your box remotely. Worse, I don't know of any place to find a definitive list of stock filetypes. Worse still, any other product can add to the list on your box, and doesn't have to tell you it has done so. The actual outcome of ShellExecute() ought to be documented as "undefined".
I think that a whitelist is a capital idea here. There is no good way to know what to put into a blacklist.
Slashdot Mirror
"It should be a public utility."
See the "OMG the UN is getting interested" thread.
Hmmm, well, if the company gets bought or divvied up then you are out of luck if you accepted one of those horrible "we can change the deal at any time in any way for any reason or none whatsoever" clauses. I'd like to see such overbroad provisions declared unenforceable.
The rogue employee case is pretty simple: 100 million angry customers sue him into oblivion.
To make 40% less?
:-)
The beer-hockey sounds interesting, though.
There, you see? We may need *more* greenhouse gases, not less.
(What we really need is to figure out how to modulate the atmosphere to trim up dangerous temperature excursions in *either* direction, without going overboard and suffocating ourselves.)
Got it! Killer bees, maddened by the loss of directional sense, cause volcanoes to erupt all over the world simultaneously, attracting aliens whose invasion is stopped in the penultimate scene when they are wiped out by the asteroids.
(In the sequel, rotting alien corpses trigger global warming (in a matter of days) which sets off a worldwide spate of tidal waves. Then, thinking humans are responsible for the mess, the loggerhead turtles attack!)
Don't forget *secondary* radiation. Proton whacks some random molecule in the atmosphere; molecule absorbs energy from it; molecule releases energy as photon. Kind of like a laser or an X-ray tube. So even your particle shielding can kill you if you don't use it properly.
Dunno about that -- how good is zinc oxide at blocking particle radiation? You'd probably have to wear a *lot* of it, though.
Hey, a new use for those tinfoil hats!
I'd say that, if you're still running Win9x, you're not an enterprise customer. There's a difference between "enterprise computing customer" and "we have a tremendous pile of unmanageable, unsecurable, toy computers".
Yeah, I've been heard to suggest that, once a work has been published, refusal to continue publishing for more than some reasonable period (say, two years) should automatically place the work into the public domain. (There'd have to be some rule about not just raising the price 1000x to keep the work without ever having to actually sell it again.)
Where have you been? Identification==evil. Everyone should be completely anonymous all the time. Anyone who wants to know anything about you is up to no good.
}sarcasm off{
This reminds me that I'm curious as to whether there's any principle in law (anywhere) which would enable one to treat the IP in an orphaned product as abandoned property? At least to the extent that, if a manufacturer refuses to service the product anymore, one is automatically protected from any claims the manufacturer may make when one reverse-engineers just the bits he needs to repair it himself?
OTOH Toyota used to give you a card with the car to facilitate ordering the shop manuals for said car. Not too expensive either. (Dunno if they still do, as I haven't bought a car in several years.)
Cure: "Thanks for installing our tape robot. Now give us the passwords. All of them. It *is* our property now, is it not? No, I'm not signing your form until you deliver everything we purchased."
"The maintenance password is the same on all of them? Tsk tsk, what an error. Okay, change it to $WHATEVER on this one."
"You refuse? Very well. Since the product is (for us) not fully functional, we revoke our acceptance. Please take it away."
That'll never happen, of course.
You misunderstand. The Carpenter and the Contractor are both working for Mozilla.
Returning to the software realm, Mozilla does need to use ShellExecute() but they certainly do not need to blindly use it whenever a URI scheme is not recognized by their code. Instead it should be used only when the scheme *is* recognized and known not to be implemented by their code; otherwise punt the decision to the user with appropriate scary warnings. Let the user also decide whether to push the "add this scheme to the safe list" button if he dare.
It is wrong to cast this as an either/or, be secure or be usable matter. The browser's behavior can, and always could, be made much safer regardless of whether anything is ever done to ShellExecute().
Carpenter: "Boss, did you notice that our standard house plans all specify doors with no locks? We've installed 234 front doors this year without locks."
Contractor: "WONTFIX. Let me know when there's a specific exploit."
Think of it this way.
/bin/cp' is, however, incredibly stupid.
The setuid bit is not inherently damaging. A program which copies stdin to stdout is not inherently damaging. 'chmod u+s
In Mozilla's case, the problem was combining a facility for fetching untrused code off the Internet and a facility for interpreting arbitrary commands. ShellExecute() by itself is insufficient to yield a remote exploit; a web browser by itself is insufficient to yield a remote exploit; a web browser that hands things off to ShellExecute() uncritically *does* permit a remote exploit if ShellExecute() knows how to execute arbitrary commands (and, as it turns out, it does).
So? "The URI handler in MS Windows is insecure." "Uh-oh. Don't use it, then. Or find a way to only use it securely." Not, "not our problem, MS should fix it." Notice how quickly it became "our problem" when a more specific exploit was noted.
I agree that the specific vulnerability was not known back then, but I disagree on the burden of blame nonetheless. If someone had pointed out to me that our project was currently handing untested web documents over to code not under our control which is ill-defined and could be extended without our knowledge, I would have considered it DROPEVERYTHING, not WONTFIX.
One thing that bugs me about this particular problem is that the Mozilla folk spend so much time relentlessly creating "cross-platform" reimplementations of stuff that could safely and sanely be left to the platform (such as storing user preferences) and yet here, in a very security-sensitive place, they happily glommed onto a platform-specific thingy which turned out to have unintended consequences. I am negatively impressed.
Gotta keep in mind that contemporary "Windows" is a protected subsystem running atop NT just as older versions were a shell running atop DOS. It's the kernel that is essentially VMS mk II, and it *is* possible to build decently secure systems on it. The Win32 subsystem, OTOH, suffers from unwholesome tradeoffs of security for convenience. There's not a lot that any kernel can do if privileged code works against it.
This is not a problem with restricted access; it's a problem with third-party app.s written without any consideration of MS Windows' security model or the fundamental requirements of a multiuser runtime environment. Those app.s "break" because they were broken as designed.
It's not hard to do it right. Don't depend on being able to write anywhere outside of %USERPROFILE%. Don't depend on being able to write anywhere outside of HKEY_CURRENT_USER. Put user files in %USERPROFILE%\Application Data\name-of-company\name-of-app. Put user settings in HKCU\Software\name-of-company\name-of-app. Put scratch files in %TEMP%. Problem solved. This has been the case since Windows 95 -- there is no excuse for not knowing it today.
The "more to it" is Windows' definition of "execute". This is a consequence of making documents "executable" by having the shell associate them automagically with the applications which handle them. So you ask Windows to "execute" a .DOC and the shell says to itself, "hmmm, look up .DOC -- ahh, yes, that really means I should launch Word and fake a command line naming FOO.DOC as its input."
(It's actually somewhat more complicated, since Word is an OLE server, but that's the basic model.)
This is really handy when you know what's in the file. You doubleclick on some document and Explorer uses ShellExecute() to figure out what to actually run on it. You can also START the same document in a command window and the same thing happens.
Unfortunately, when you *don't* know what's in the file, because you fetched it from some random website, the same idea becomes really handy for people who mean to do you harm, because now it works for them, too, *on your computer*. Applications which fetch things that are beyond your control must be much more picky about what is done with them. Just sucking down some random file from the other side of the world and handing it to ShellExecute() is not wise.
On Linux, on the other hand, if you try to exec() a word processing document (say), the kernel will burp back its equivalent of, "that is not a program, master." The tricky bit is that, as mentioned elsewhere, this *does* work for shell scripts, which are the subject of a special case in the kernel code. You can also add other special cases, but I've only ever seen that mechanism used to make Java classes "executable". It's not done with anything like the enthusiasm you see in MS Windows. Probably sooner or later the special case will be factored out of the kernel and replaced with a userspace implementation that you can omit to have added to the list at boot time if you don't mind breaking "shebang" scripts.
"There are other minor issues, like WinAmp doesn't save its preferences into my profile, but rather saves them to the Program Files\WinAmp directory. Granting permissions on the necessary files is not particularly difficult, however."
Poor design of WinAmp, then. Programmers who know their way around Windows have known for a decade where the user pref.s go (because, for once, Microsoft told them), and their code doesn't have this problem. There are, sadly, hundreds of incorrect designs like what you mention. At least you're attacking the problem in the least incorrect way, instead of making everybody a Power User as one is usually told to do by the clueless.
What seems to be going on is that Mozilla-for-MS-Windows uses the time-honored method of punting unimplemented file types to ShellExecute() in the hope that Microsoft has provided a handler. The problem with this is that Microsoft *has* provided handlers for all sorts of things you do *not* want others to be able to run on your box remotely. Worse, I don't know of any place to find a definitive list of stock filetypes. Worse still, any other product can add to the list on your box, and doesn't have to tell you it has done so. The actual outcome of ShellExecute() ought to be documented as "undefined".
I think that a whitelist is a capital idea here. There is no good way to know what to put into a blacklist.
Many species will go extinct, and *every one of the extinctions will be blamed on human activity*.