Yes, they could have waited, but if 10.3.4 was already ready, I'd prefer for Apple to release it on time and give us the fixes they can right now, and then work on the recent problems to provide us a good security patch (or maybe a 10.3.5) when they've fixed it.
Totally agreed. I prefer Apple's "release when ready" rather than "lump all our releases together" approach to security fixes.
Or to put it a little more clearly, requests for protocol handlers come from someplace: a web page in Latvia, manually being typed in the address bar, etc. So in order to use a protocol handler, why not have the handler subsystem ask where the request is coming from? From there, the handler could behave differently if the source is a local file versus a remote web page. Local handlers could just run, but links from far away might pop up a scary warning.
Well, yes, you can put up warnings, but most people won't know what to do. It doesn't solve the problem, it just shifts the burden to the (mostly ignorant) user. And that's even scarier.:-) How many of us would have blinked at loading a disk image if asked, before this week?
This would not be a perfect solution, would be tricky for many programs to implement
If you are going to offload the burden to the application, then why not just have the application make sure no unsafe operation can be performed on the data? It's an easier solution, more reliable, and more transparent to the user. Sure, sometimes apps can choose to only allow certain things from within themselves, or other trusted apps, but if you want the protocol handler system to still retain usefulness -- that is, allowing users to click on many kinds of links on web pages -- then it still needs to be about the data.
It would also preserve the robustness of the protocol handler system by not requiring any program that uses handlers to know which ones are good and which one might be dangerous.
But that's the point: all of them have unsafe data. That's always been the case, and always will be (for the forseeable future...). It's not really about the handlers at all. The critical mistake Apple engineers have made is treating this data as though it could be trusted, not even looking for all the ways untrusted data could do bad things. The handlers themselves are fine, if the engineers make sure what they do with the data is reasonable.
Either the researcher notified Apple in February, or he did not.
You mean either he notified Apple *properly*, or he did not. True. But so what? Why should I have to pick one or the other to believe? What kind of depraved existence do you live that you feel you must decide on everything, despite lack of sufficient evidence?
in this case all the doors clearly provide access to the same part of the house--namely my home directory where I keep my files
It is not merely about location. Clearly, the telnet exploit, which can overwrite only one known file, is not nearly as serious as an exploit which can run arbitrary code.
Get hold of an example written by somebody who actually knows what he's doing (such as the various benign demos of these exploits). Identify the payload. Substitute my own.
Yes, which is significantly more complex a process for the disk-mounting-and-adding-a-new-protocol-handler exploit, than for the runscript exploit.
You apparently didn't read my post. Try again. I concluded with:
There's no way to deal with these except to make sure the target applications deal with all the incoming data safely, or shut down the protocol handler altogether (as we must temporarily do until Apple fixes the applications).
Yes, you can shut down the handler altogether, as I said. That is what it would be to "ignore everything except http(s)://". But that isn't going to happen. Users want mailto:, aim:, ftp:, and the rest.
So if my home has 5 unlocked doors, and I lock one of them, I am less vulnerable?
Yes, if:
1. Each door provides access to only certain parts of the home, and 2. Each door is not able to be accessed via the same methods
Let's compare the two big exploits so far, Help Viewer's runscript command, and the one where Apple adds new protocol handlers upon volume mounting.
The latter exploit is much more difficult; it requires a significant ability to program, and to prepare a volume for mounting, and a place to put that volume online, for either downloading (which won't affect the many people who turn off "open files," even thought it is the default) or online mounting (which has even greater requirements for the attacker). For exploting Help Viewer, you don't need a server, you don't need programming ability, you just need to be able to construct a URL or two cleverly, and a place to post it.
If both exploits were just as easily executed, and both allowed the same access to the system, then you're right, users would be just as vulnerable. But even granting they probably both allow the same approximate access, one is significantly more difficult to exploit.
So independent researchers uncovering security flaws are now to be held up to a higher burden of proof than the corporate authors of those flaws?
I am holding them both to the same standard. Whichever group did not follow such a reasonable procedure is to blame. I don't know which is to blame, so I blame neither.
Ultimately, you have to believe one or the other.
A more ridiculous statement I've not seen all week. Congratulations!
it's odd to heap skepticism verging on contempt upon the former
I am not verging on contempt for the originator -- unless it is shown he really didn't notify Apple properly, at which point I will have plenty of contempt -- but I do have contempt for those who expect me to believe the originator, sans evidence. Similarly, I will have contempt for Apple if it is shown they were properly notified.
What is odd, to any reasonable person, is to not have skepticism for the claim. There's no evidence whatsoever backing it up: how can I *not* be skeptical of it?
As far as you know, it was not known. And even if it was not known. it was still an existing vulnerability. There's no doubt on this.
And no, that is not evidence, that is assertion. It doesn't say how Apple was notified, it merely says "i told Apple on 23rd of February". The lack of good form in this posting makes me extremely skeptical that Apple was notified properly, if at all.
You're right on for the most part, but you are flat-out wrong about "carefully rethink protocol helpers, perhaps even deprecate the current system, and reimplement it in a more security conscious manner." It is not possible. All the system does is pass arbitrary data from one app to another. Changing the system would be like making it so a web browser can't pass arbitrary data to a web server through a form interface or URL.
The only solution is the finger-in-the-dike approach, except more proactive than you describe: to audit every single application that receives the data, and make sure that it doesn't allow any dangerous operation with the data it receives. This is what web programmers around the world have to do (often failing miserably). Is this a robust permanent solution? No, but there is no robust permanent solution.
I've been dealing with this for years in the Slash code. If one of our programmers wanted to, we could allow this:
http://slashdot.org/index.pl?runscript=$url
Then index.pl would download the script at $url and execute it. Perl can't solve that problem, and neither can the underlying Slash code. If index.pl allows that, there's nothing that can be done except to fix index.pl, or disable it. Oh, sure, we could disable the "runscript" parameter at a lower level, but that really is the intolerable finger-in-the-dike approach, because index.pl could just use some other parameter name.
Look at iChat. Part of the aim handler suite are getfile and sendfile commands. iChat does not have those implemented, probably in part out of security concerns. Terminal should not allow arbitrary command-line options to be passed to it from a URL: if it allows commands to be run at all, it should filter any option out that might lead to writing a file, reading a file and sending its data over the connection, opening an additional possibly unsafe process, etc. Help Viewer should not allow running arbitrary scripts or opening arbitrary applications. The OS should not automatically modify system settings based on the mounting of a volume.
There's no way to deal with these except to make sure the target applications deal with all the incoming data safely, or shut down the protocol handler altogether (as we must temporarily do until Apple fixes the applications).
No, you're wrong too. It is simple math. You have a pile of exploits. You remove one, and now you have fewer possible exploits. You are therefore less vulnerable.
As for Apple being "fairly responsive" I see absolutely no evidence that they were not notified on 23rd February as the original researcher wrote.
And I see no evidence they were informed; further, how were they informed, if it did happen? Was it a "dude, your browser sucks! I can totally 0wnZ j00!" email sent to steve@apple.com? Or was it a well-written report sent through the proper channels? Or was it somewhere in between? I won't assume Apple was notified, or that it was done properly, just because someone says so.
Well, in one sense, that's true. But considering the only fixes from Apple address the actual problems (such as fixing Terminal and Help Viewer), that clearly shows them to be distinct. Indeed, no one has come up with a way to actually fix the problem at the protocol handler level, because the exploits are far too different. Who is to say if telnet://-nFoo is dangerous? You can't tell that by looking at the URL, you can only tell by seeing what the app does with it.
They all have a common thread, use of the protocol handler facility, but exploit that in very different ways. The only solution is to disable the facility, which ain't gonna happen, or have application authors be much more careful about what data they accept from the facility.
It's just like in web programming: anything that comes from the web browser cannot be trusted for potentially dangerous operations. You define those operations -- such as writing files, opening applications, installing new protocol handlers -- and you don't allow those things to happen without specific user interaction or permission.
iChat has the "aim" protocol handler, and there's been security holes in other apps because of it, for the same reasons. Does iChat have these problems too? I dunno, but if Apple is smart, every single app it has that accepts a GURL Apple event will be triple-checked to make sure nothing unsafe is allowed.
The problem is that Secunia is entirely wrong. The removal of runscript left users less vulnerable. The exploit was much worse than any of the others, and even if it weren't, it is different, so the users are not just as vulnerable, because that exploit is removed (for those who updated).
And Apple has been failry responsive, as far as we know. If it is true -- which is unverified -- that Apple was told about the runscript hole in February, then fine, Apple dropped the ball. But we don't know that and can't assume it.
Of course, when it comes right down to it, both companies are spinning to make themselves money. But Secunia is doing it with FUD, which makes it far more distasteful.
Last year, I regularly watched BBC news, and I picked up CNNi, and various programs on Worldlink. I've read a lot of foreign news, of course, too, mostly British and Canadian. And none of them had nearly as interesting or insightful analysis and interview of American politics as what you find on the top shows in the U.S.
No prior accusations of prisoner abuse eh? I think Hersh broke the story to you folks, not the rest of the world.
Please don't attempt to change the goalposts: it makes you look dishonest. You were not talking about "prior accusations of prisoner abuse" -- which were news in the US last year, and then in January, and then again in March, before finally becoming big news in April -- but the pictures themselves, when you said "[US news organizations] were finally showing pics of prisoner abuse after they circulated on the 'net. Not when accusations originally took place."
And the pictures were not circulating the Internet before they broke in the US news. Maybe some people had them somewhere a day or two before they were published, as the stories were being prepared, but certainly not on any large scale. They were shown on TV on April 29, and Seymour Hersh had his story published on April 30. There is no evidence whatsoever that these pictures were ignored or buried, even while they were cropping up on the Internet.
To say otherwise doesn't even make sense on its face: the speed at which such things hit the "blog" websites means that when something like that becomes well known outside the US, it becomes well known inside the US too. I would have seen them on many anti-war websites. But I didn't. No one did, because they weren't "circulating the 'net" before the 60 Minutes piece.
In general US news is vacuous. That is a major reason why they have a penchant to go to war. They just don't ask any tough questions, until it is safe to do so.
Your analysis is wanting. I watch the shows I mentioned all the time (I almost never miss them), and they ask all the tough questions asked by foreign news programs and more, and yet I and many other people who watch these shows favored going to war in Iraq.
Much like penguins testing the water, they were finally showing pics of prisoner abuse after they circulated on the 'net. Not when accusations originally took place.
Huh? These pictures were not circulating the Internet significantly, and there were no accusations -- except what the military itself was doing in its investigations and court-martials -- until after 60 Minutes and Seymour Hersh broke the story. You're just making stuff up.
Nobody asks whether his dumping is merely to fulfill the role of the administration's scape goat for the "faulty intelligence" that they supposedly received.
Maybe Matthews didn't ask, but Chalabi was on Meet the Press, Fox News Sunday, and This Week, all yesterday, and this was a subject that Chalabi commented on. I don't recall anyone specifically asking him that, but that is uninteresting, since the point of a good interview is not to ask specific questions but to elicit informational and insightful responses.
For example, Chris Wallace on FNS asked why George Tenet would lie about Chalabi, and Chalabi responded, basically, because Tenet was wrong and Chalabi was right and he wanted Chalabi to take the fall.
This is just more of you not knowing what you're talking about.
What's clear is that you don't watch a wide range of American news. Try watching NewsHour, Meet the Press, This Week. Those questions of US officials are far better than anything you find on the major network and cable nightly news, and anything you find on British or Canadian news.
What I am referring to is the RFPolicy which does encourage full disclosure, however: "Provided you cooperate with the researcher and keep them 'in the loop', they should provide you with whatever time necessary to resolve the ISSUE." This is what I am referring to: if the issue is disclosed without being resolved, then someone has dropped the ball. Yes, if Apple doesn't "do anything about it," it could be disclosed, but that just means the process has broken down.
I have no trouble believing this. I made it clear I was not blaming anyone in particular, but noting that it was the situation that was problematic. If Apple is to blame, so be it, but I don't feel confident in asserting that.
The current submission is not incorrect. It states the fact that automounting images can allow a known path to a script. It doesn't say there are not other methods for getting a known path to a script; it doesn't even imply it. This guy mentioned one additional method, and there are likely others. If I give his method, then people disable disk: protocol; then what? It's a false sense of security, since the path is not the real problem, it is Help Viewer that is the problem.
Slashdot Mirror
These exploits are serious, and will require a significant overhaul of the protocol handler code
They are serious, but most of the fixes belong in the apps, not the underlying OS services. It's a matter of filtering unsafe data so it cannot be used for unsafe operations, in the individual applications. That, or disabling the handlers.
Yes, they could have waited, but if 10.3.4 was already ready, I'd prefer for Apple to release it on time and give us the fixes they can right now, and then work on the recent problems to provide us a good security patch (or maybe a 10.3.5) when they've fixed it.
Totally agreed. I prefer Apple's "release when ready" rather than "lump all our releases together" approach to security fixes.
Or to put it a little more clearly, requests for protocol handlers come from someplace: a web page in Latvia, manually being typed in the address bar, etc. So in order to use a protocol handler, why not have the handler subsystem ask where the request is coming from? From there, the handler could behave differently if the source is a local file versus a remote web page. Local handlers could just run, but links from far away might pop up a scary warning.
:-) How many of us would have blinked at loading a disk image if asked, before this week?
...). It's not really about the handlers at all. The critical mistake Apple engineers have made is treating this data as though it could be trusted, not even looking for all the ways untrusted data could do bad things. The handlers themselves are fine, if the engineers make sure what they do with the data is reasonable.
Well, yes, you can put up warnings, but most people won't know what to do. It doesn't solve the problem, it just shifts the burden to the (mostly ignorant) user. And that's even scarier.
This would not be a perfect solution, would be tricky for many programs to implement
If you are going to offload the burden to the application, then why not just have the application make sure no unsafe operation can be performed on the data? It's an easier solution, more reliable, and more transparent to the user. Sure, sometimes apps can choose to only allow certain things from within themselves, or other trusted apps, but if you want the protocol handler system to still retain usefulness -- that is, allowing users to click on many kinds of links on web pages -- then it still needs to be about the data.
It would also preserve the robustness of the protocol handler system by not requiring any program that uses handlers to know which ones are good and which one might be dangerous.
But that's the point: all of them have unsafe data. That's always been the case, and always will be (for the forseeable future
Either the researcher notified Apple in February, or he did not.
You mean either he notified Apple *properly*, or he did not. True. But so what? Why should I have to pick one or the other to believe? What kind of depraved existence do you live that you feel you must decide on everything, despite lack of sufficient evidence?
in this case all the doors clearly provide access to the same part of the house--namely my home directory where I keep my files
It is not merely about location. Clearly, the telnet exploit, which can overwrite only one known file, is not nearly as serious as an exploit which can run arbitrary code.
Get hold of an example written by somebody who actually knows what he's doing (such as the various benign demos of these exploits). Identify the payload. Substitute my own.
Yes, which is significantly more complex a process for the disk-mounting-and-adding-a-new-protocol-handler exploit, than for the runscript exploit.
You apparently didn't read my post. Try again. I concluded with:
There's no way to deal with these except to make sure the target applications deal with all the incoming data safely, or shut down the protocol handler altogether (as we must temporarily do until Apple fixes the applications).
Yes, you can shut down the handler altogether, as I said. That is what it would be to "ignore everything except http(s)://". But that isn't going to happen. Users want mailto:, aim:, ftp:, and the rest.
So if my home has 5 unlocked doors, and I lock one of them, I am less vulnerable?
Yes, if:
1. Each door provides access to only certain parts of the home, and
2. Each door is not able to be accessed via the same methods
Let's compare the two big exploits so far, Help Viewer's runscript command, and the one where Apple adds new protocol handlers upon volume mounting.
The latter exploit is much more difficult; it requires a significant ability to program, and to prepare a volume for mounting, and a place to put that volume online, for either downloading (which won't affect the many people who turn off "open files," even thought it is the default) or online mounting (which has even greater requirements for the attacker). For exploting Help Viewer, you don't need a server, you don't need programming ability, you just need to be able to construct a URL or two cleverly, and a place to post it.
If both exploits were just as easily executed, and both allowed the same access to the system, then you're right, users would be just as vulnerable. But even granting they probably both allow the same approximate access, one is significantly more difficult to exploit.
So independent researchers uncovering security flaws are now to be held up to a higher burden of proof than the corporate authors of those flaws?
I am holding them both to the same standard. Whichever group did not follow such a reasonable procedure is to blame. I don't know which is to blame, so I blame neither.
Ultimately, you have to believe one or the other.
A more ridiculous statement I've not seen all week. Congratulations!
it's odd to heap skepticism verging on contempt upon the former
I am not verging on contempt for the originator -- unless it is shown he really didn't notify Apple properly, at which point I will have plenty of contempt -- but I do have contempt for those who expect me to believe the originator, sans evidence. Similarly, I will have contempt for Apple if it is shown they were properly notified.
What is odd, to any reasonable person, is to not have skepticism for the claim. There's no evidence whatsoever backing it up: how can I *not* be skeptical of it?
As far as you know, it was not known. And even if it was not known. it was still an existing vulnerability. There's no doubt on this.
And no, that is not evidence, that is assertion. It doesn't say how Apple was notified, it merely says "i told Apple on 23rd of February". The lack of good form in this posting makes me extremely skeptical that Apple was notified properly, if at all.
You're stupid. I didn't say Apple was not informed, I said I won't assume they were. That also necessarily means I won't assume they weren't.
That is what reasonable people do when they have a lack of evidence: they don't make assumptions either way.
The only solution is the finger-in-the-dike approach, except more proactive than you describe: to audit every single application that receives the data, and make sure that it doesn't allow any dangerous operation with the data it receives. This is what web programmers around the world have to do (often failing miserably). Is this a robust permanent solution? No, but there is no robust permanent solution.
I've been dealing with this for years in the Slash code. If one of our programmers wanted to, we could allow this:Then index.pl would download the script at $url and execute it. Perl can't solve that problem, and neither can the underlying Slash code. If index.pl allows that, there's nothing that can be done except to fix index.pl, or disable it. Oh, sure, we could disable the "runscript" parameter at a lower level, but that really is the intolerable finger-in-the-dike approach, because index.pl could just use some other parameter name.
Look at iChat. Part of the aim handler suite are getfile and sendfile commands. iChat does not have those implemented, probably in part out of security concerns. Terminal should not allow arbitrary command-line options to be passed to it from a URL: if it allows commands to be run at all, it should filter any option out that might lead to writing a file, reading a file and sending its data over the connection, opening an additional possibly unsafe process, etc. Help Viewer should not allow running arbitrary scripts or opening arbitrary applications. The OS should not automatically modify system settings based on the mounting of a volume.
There's no way to deal with these except to make sure the target applications deal with all the incoming data safely, or shut down the protocol handler altogether (as we must temporarily do until Apple fixes the applications).
I see ... if you want a more sweeping solution that is more paranoid and catches every possible exploit in this regard, Paranoid Android is for you.
No, you're wrong too. It is simple math. You have a pile of exploits. You remove one, and now you have fewer possible exploits. You are therefore less vulnerable.
As for Apple being "fairly responsive" I see absolutely no evidence that they were not notified on 23rd February as the original researcher wrote.
And I see no evidence they were informed; further, how were they informed, if it did happen? Was it a "dude, your browser sucks! I can totally 0wnZ j00!" email sent to steve@apple.com? Or was it a well-written report sent through the proper channels? Or was it somewhere in between? I won't assume Apple was notified, or that it was done properly, just because someone says so.
Did you read the story? This is exactly what RCDefaultApp does, it allows you to selectively disable those handlers.
Well, in one sense, that's true. But considering the only fixes from Apple address the actual problems (such as fixing Terminal and Help Viewer), that clearly shows them to be distinct. Indeed, no one has come up with a way to actually fix the problem at the protocol handler level, because the exploits are far too different. Who is to say if telnet://-nFoo is dangerous? You can't tell that by looking at the URL, you can only tell by seeing what the app does with it.
They all have a common thread, use of the protocol handler facility, but exploit that in very different ways. The only solution is to disable the facility, which ain't gonna happen, or have application authors be much more careful about what data they accept from the facility.
It's just like in web programming: anything that comes from the web browser cannot be trusted for potentially dangerous operations. You define those operations -- such as writing files, opening applications, installing new protocol handlers -- and you don't allow those things to happen without specific user interaction or permission.
iChat has the "aim" protocol handler, and there's been security holes in other apps because of it, for the same reasons. Does iChat have these problems too? I dunno, but if Apple is smart, every single app it has that accepts a GURL Apple event will be triple-checked to make sure nothing unsafe is allowed.
The problem is that Secunia is entirely wrong. The removal of runscript left users less vulnerable. The exploit was much worse than any of the others, and even if it weren't, it is different, so the users are not just as vulnerable, because that exploit is removed (for those who updated).
And Apple has been failry responsive, as far as we know. If it is true -- which is unverified -- that Apple was told about the runscript hole in February, then fine, Apple dropped the ball. But we don't know that and can't assume it.
Of course, when it comes right down to it, both companies are spinning to make themselves money. But Secunia is doing it with FUD, which makes it far more distasteful.
Have you watched much foreign news?
Last year, I regularly watched BBC news, and I picked up CNNi, and various programs on Worldlink. I've read a lot of foreign news, of course, too, mostly British and Canadian. And none of them had nearly as interesting or insightful analysis and interview of American politics as what you find on the top shows in the U.S.
No prior accusations of prisoner abuse eh? I think Hersh broke the story to you folks, not the rest of the world.
Please don't attempt to change the goalposts: it makes you look dishonest. You were not talking about "prior accusations of prisoner abuse" -- which were news in the US last year, and then in January, and then again in March, before finally becoming big news in April -- but the pictures themselves, when you said "[US news organizations] were finally showing pics of prisoner abuse after they circulated on the 'net. Not when accusations originally took place."
And the pictures were not circulating the Internet before they broke in the US news. Maybe some people had them somewhere a day or two before they were published, as the stories were being prepared, but certainly not on any large scale. They were shown on TV on April 29, and Seymour Hersh had his story published on April 30. There is no evidence whatsoever that these pictures were ignored or buried, even while they were cropping up on the Internet.
To say otherwise doesn't even make sense on its face: the speed at which such things hit the "blog" websites means that when something like that becomes well known outside the US, it becomes well known inside the US too. I would have seen them on many anti-war websites. But I didn't. No one did, because they weren't "circulating the 'net" before the 60 Minutes piece.
In general US news is vacuous. That is a major reason why they have a penchant to go to war. They just don't ask any tough questions, until it is safe to do so.
Your analysis is wanting. I watch the shows I mentioned all the time (I almost never miss them), and they ask all the tough questions asked by foreign news programs and more, and yet I and many other people who watch these shows favored going to war in Iraq.
Much like penguins testing the water, they were finally showing pics of prisoner abuse after they circulated on the 'net. Not when accusations originally took place.
Huh? These pictures were not circulating the Internet significantly, and there were no accusations -- except what the military itself was doing in its investigations and court-martials -- until after 60 Minutes and Seymour Hersh broke the story. You're just making stuff up.
Nobody asks whether his dumping is merely to fulfill the role of the administration's scape goat for the "faulty intelligence" that they supposedly received.
Maybe Matthews didn't ask, but Chalabi was on Meet the Press, Fox News Sunday, and This Week, all yesterday, and this was a subject that Chalabi commented on. I don't recall anyone specifically asking him that, but that is uninteresting, since the point of a good interview is not to ask specific questions but to elicit informational and insightful responses.
For example, Chris Wallace on FNS asked why George Tenet would lie about Chalabi, and Chalabi responded, basically, because Tenet was wrong and Chalabi was right and he wanted Chalabi to take the fall.
This is just more of you not knowing what you're talking about.
What's clear is that you don't watch a wide range of American news. Try watching NewsHour, Meet the Press, This Week. Those questions of US officials are far better than anything you find on the major network and cable nightly news, and anything you find on British or Canadian news.
What I am referring to is the RFPolicy which does encourage full disclosure, however: "Provided you cooperate with the researcher and keep them 'in the loop', they should provide you with whatever time necessary to resolve the ISSUE." This is what I am referring to: if the issue is disclosed without being resolved, then someone has dropped the ball. Yes, if Apple doesn't "do anything about it," it could be disclosed, but that just means the process has broken down.
Yes, there is, of course, nothing we can do about external redirection sites, or offsite pages with redirects or other links on them, etc.
I have no trouble believing this. I made it clear I was not blaming anyone in particular, but noting that it was the situation that was problematic. If Apple is to blame, so be it, but I don't feel confident in asserting that.
Yeah, Help Viewer just blows, and it always has. I can use Google about 10x faster than Help Viewer, and with fewer crashes.
The current submission is not incorrect. It states the fact that automounting images can allow a known path to a script. It doesn't say there are not other methods for getting a known path to a script; it doesn't even imply it. This guy mentioned one additional method, and there are likely others. If I give his method, then people disable disk: protocol; then what? It's a false sense of security, since the path is not the real problem, it is Help Viewer that is the problem.
On any reasonably well maintained OS X system
:-)
/" as a normal (or even Admin) user cannot cause the entire hard drive to be deleted.
...
That's a bit like saying "email viruses aren't a problem because they only spread when users do stupid things."
executing "rm -rf
It's a remote possibility, not not an impossible one. It is also possible to run Help Viewer as root.
This does not detract (much) from the seriousness of this exploit, but let's not get carried away with the alarmism.
Maybe it should have been explained better or worded differently, but it would be incorrect to leave it out as a possibility
According to the thread in macnn, Apple has been aware of this at least since Februari, but hasn't said or done anything so far.
...
And since Apple did not respond, how does anyone know they were aware of it? Question everything