Let's also not forget that buffer overflows are in general much much harder to exploit on PowerPC where overwriting the stack merely overwrites program data, not the return address or function parameters (which are all stored in registers). To successfully exploit a buffer overflow on PowerPC you'd need to have more specific knowledge of the particular program or library you are exploiting.
Completely false. The return address and stack pointer is stored on the stack in OS X too, at least if the function calls another function (since that may manipulate the registers).
These problems are not new for 10.3.9 (they most likely affect Jaguar too, and that system does not get a fix at all) and Apple knew about most or all of them when they released 10.3.9.
Do you realize that one of the issues allowed remote code execution when viewing a TIFF image? No firewall will help you there.
It took Apple 4 months to fix the iSync mRouter local root vulnerability, despite the fact that an exploit was available on BugTraq ready to run. That is borderline negligent.
It should be noted that I agree with your sentiment on openness. I chose not to publish the problems I found until a fix was available. But that does not change the fact that the problems were there for three months.
While I agree that the.DS_Store bug is far-from-critical, local exploits are serious too. They can be used to escalate privileges (get root) after first entering the system. Secondly, Macs are used increasingly (again) in shared environments such as schools with multiple users of each machine having limited access.
They could do a better job, I think. The product security team must be overworked. I was credited with discovery of four of the issues (more about those), and I reported them in mid-February. Almost three months later, the patch is out...
No, there is very solid reasoning behind doing so.
A security update should have a very low threshold for installation. An admin should be able to apply it feeling somewhat confident it is not going to break anything important. Of course, on critical systems "somewhat" is not enough so it may still require some testing.
Point being, a security update should be lightweight to encourage quick adoption.
As an aside, Apple "violated" this express policy and included a few security updates with 10.3.9. That update turned out to break things for a lot of people, therefore people held off installing it. During that time, they were subjected to published vulnerabilities.
That could easily be said for other experiments that have been challenged on ethical grounds. Sometimes experiments find things about ourselves we'd rather not know.
For example, the Milgram experiement, where participants were mildly coerced by an authoritative person to administer strong electrical shocks to a subject (who was really an actor). A high proportion of the participants were willing to administer levels of shock that they believed to be lethal.
Would you like to know that you would be capable of murder as long as someone else was there to take the responsibility/blame? Even if the person in the quoted blog post should feel foolish, that does not make the experiment ethical and non-offensive - quite the opposite.
Apple has not disabled suid. They have disabled suid scripts, a technique inherently unsafe. It is not possible to write a suid script in a secure manner. It is _difficult_ to write a secure suid binary, but far from impossible.
Except Apple used this model before. When you insert a CDR, it gets mounted on the desktop and you add to it like you would with any other disk. When you eject it, the contents is burnt.
The new thing is that "burnable folders" can be at any location in the (user's view of the) file system. At least that's my guess. I'm not familiar with burn:///, but it sounds like it is always in a specific location?
Re:Why is stealth mode pointed out as special?
on
Tiger's 200 New Features
·
· Score: 5, Informative
OS X's firewall is very competent (ipfw). However, Apple's GUI for it was quite rudimentary, for good and for bad. It basically had a button to turn it on or off and one to open ports.
Most consumer-oriented firewalls overdo the configurability and impose the log on users who would be better of not knowing how many malicious and non-malicious "attacks" are directed towards their computers, as long as the firewall blocks them. It's the attacks that aren't blocked / logged that should be interesting.
Apple always strives to strike a balance between "user-friendliness" and power. Apparently they decided they should give stealth mode to those who need it and make it easier to view a log.
The information can also be found on the web:
KB 301327.
It is quite unfortunate that Apple "forgot" to mention the new security vulnerabilities that the update addresses in the short blurb. It does mention "previous stand-alone security updates", but not the new ones.
Presumably the artist or his or her record company owns the copyrights. The terms under which they distribute the music can thus be determined set by them (just like the GNU GPL for example). In this case, they allow non-commercial reuse (it sounds like from the blurb, I did not RTFA).
I discovered this vulnerability, and i can confirm that Apple is indeed starting to think in zone separation paths...
I have written a detailed advisory about the problem (Apple conveniently "forgot" to link to it). Apple allows XMLHttpRequest more privileges when running from a file: URL than from http:. This created a problem combined with the fact that disk images are automatically mounted with predictable paths and that Safari did not enforce separation between the http: and file: zones.
Apple took the approach of separating the zones instead of limiting XMLHttpRequest access from file: URLs.
Note that Konqueror is already separating zones, and also allows file: URLs to use XMLHttpRequest to access local resources.
I don't know if there are any other instances where the local zone is given higher privileges than the Internet zone. That's something for future research. If you haven't already updated, feel free to test the demo exploit on the advisory page.
Due to lacking communications, Apple did not notify me in advance that the issue was addressed in 10.3.9, and failed to link to my independent advisory on the issue. Hopefully they will rectify that on Monday.
My advisory for CAN-2005-0976 is called DR001 and is available on my web site at remahl.se/david/vuln/001/. It has also been posted to bugtraq.
It is a requirement under the GPL. Right there in the first section:
You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
However, the advertisement clause specified _where_ the attribution should be (in all advertising and on the front of the documentation or something like that), making it incompatible with the GPL.
Text content contributed to Wikipedia must be GFDL, so the foundation can sell it as long as they respect the authors' copyright and the terms of the license. Although the Wikimedia Foundation is not-for-profit, even commercial distribution would have been acceptable under the terms of the GFDL. But the content copyrights still belong to those who created it.
On the other hand, it happens that people contribute material copyrighted by other people, without their consent. According to U.S. law, Wikipedia cannot be held responsible for that, as long as they act quickly to remove infringing material. When physical media is distributed, that protection is no longer valid.
Every action in a contextual menu should be available by other means.
Yes, you need modifiers for multiple selection in most programs.
Menulings can be removed from the preferences of respective program / preference pane. That holds true for all Apple-provided menulings.
Yes, many third-party programs require modifiers to perform certain tasks, but in many cases there are alternative ways of achieving the same thing.
Yes, option was used to move the control strip.
Using modifiers is not the same thing as requiring a second mouse button though. Very few programs do that.
Slashdot Mirror
Clue #1.1.1: As are the setuid root programs.
Completely false. The return address and stack pointer is stored on the stack in OS X too, at least if the function calls another function (since that may manipulate the registers).
Here is an article about stack-based exploits on PPC.
These problems are not new for 10.3.9 (they most likely affect Jaguar too, and that system does not get a fix at all) and Apple knew about most or all of them when they released 10.3.9.
Do you realize that one of the issues allowed remote code execution when viewing a TIFF image? No firewall will help you there.
It took Apple 4 months to fix the iSync mRouter local root vulnerability, despite the fact that an exploit was available on BugTraq ready to run. That is borderline negligent.
It should be noted that I agree with your sentiment on openness. I chose not to publish the problems I found until a fix was available. But that does not change the fact that the problems were there for three months.
While I agree that the .DS_Store bug is far-from-critical, local exploits are serious too. They can be used to escalate privileges (get root) after first entering the system. Secondly, Macs are used increasingly (again) in shared environments such as schools with multiple users of each machine having limited access.
Perhaps you should be worried that you hadn't heart of them before.
Oh (three months) really (5 months)?
I'm just happy one of the issues I reported was assigned CVE "CAN-2005-1337" ;-). Must have been my lucky day.
They could do a better job, I think. The product security team must be overworked. I was credited with discovery of four of the issues (more about those), and I reported them in mid-February. Almost three months later, the patch is out...
No, there is very solid reasoning behind doing so.
A security update should have a very low threshold for installation. An admin should be able to apply it feeling somewhat confident it is not going to break anything important. Of course, on critical systems "somewhat" is not enough so it may still require some testing.
Point being, a security update should be lightweight to encourage quick adoption.
As an aside, Apple "violated" this express policy and included a few security updates with 10.3.9. That update turned out to break things for a lot of people, therefore people held off installing it. During that time, they were subjected to published vulnerabilities.
That could easily be said for other experiments that have been challenged on ethical grounds. Sometimes experiments find things about ourselves we'd rather not know.
For example, the Milgram experiement, where participants were mildly coerced by an authoritative person to administer strong electrical shocks to a subject (who was really an actor). A high proportion of the participants were willing to administer levels of shock that they believed to be lethal.
Would you like to know that you would be capable of murder as long as someone else was there to take the responsibility/blame? Even if the person in the quoted blog post should feel foolish, that does not make the experiment ethical and non-offensive - quite the opposite.
I don't think you're allowed to modify the GPL and add restrictions as you did in your first example.
Apple has not disabled suid. They have disabled suid scripts, a technique inherently unsafe. It is not possible to write a suid script in a secure manner. It is _difficult_ to write a secure suid binary, but far from impossible.
Except Apple used this model before. When you insert a CDR, it gets mounted on the desktop and you add to it like you would with any other disk. When you eject it, the contents is burnt.
The new thing is that "burnable folders" can be at any location in the (user's view of the) file system. At least that's my guess. I'm not familiar with burn:///, but it sounds like it is always in a specific location?
OS X's firewall is very competent (ipfw). However, Apple's GUI for it was quite rudimentary, for good and for bad. It basically had a button to turn it on or off and one to open ports.
Most consumer-oriented firewalls overdo the configurability and impose the log on users who would be better of not knowing how many malicious and non-malicious "attacks" are directed towards their computers, as long as the firewall blocks them. It's the attacks that aren't blocked / logged that should be interesting.
Apple always strives to strike a balance between "user-friendliness" and power. Apparently they decided they should give stealth mode to those who need it and make it easier to view a log.
The information can also be found on the web: KB 301327.
It is quite unfortunate that Apple "forgot" to mention the new security vulnerabilities that the update addresses in the short blurb. It does mention "previous stand-alone security updates", but not the new ones.
Presumably the artist or his or her record company owns the copyrights. The terms under which they distribute the music can thus be determined set by them (just like the GNU GPL for example). In this case, they allow non-commercial reuse (it sounds like from the blurb, I did not RTFA).
Microsoft sells an expensive (no argument there) product and says "don't compete". The "don't compete" part is wrong and unethical in both cases.
I discovered this vulnerability, and i can confirm that Apple is indeed starting to think in zone separation paths...
I have written a detailed advisory about the problem (Apple conveniently "forgot" to link to it). Apple allows XMLHttpRequest more privileges when running from a file: URL than from http:. This created a problem combined with the fact that disk images are automatically mounted with predictable paths and that Safari did not enforce separation between the http: and file: zones.
Apple took the approach of separating the zones instead of limiting XMLHttpRequest access from file: URLs.
Note that Konqueror is already separating zones, and also allows file: URLs to use XMLHttpRequest to access local resources.
I don't know if there are any other instances where the local zone is given higher privileges than the Internet zone. That's something for future research. If you haven't already updated, feel free to test the demo exploit on the advisory page.
I was credited with discovery of the Safari flaw.
Due to lacking communications, Apple did not notify me in advance that the issue was addressed in 10.3.9, and failed to link to my independent advisory on the issue. Hopefully they will rectify that on Monday.
My advisory for CAN-2005-0976 is called DR001 and is available on my web site at remahl.se/david/vuln/001/. It has also been posted to bugtraq.
It is a requirement under the GPL. Right there in the first section:
However, the advertisement clause specified _where_ the attribution should be (in all advertising and on the front of the documentation or something like that), making it incompatible with the GPL.
I'm sure you have also been reinforced in your decision to hire someone too, because of what you found when you googled him/her, right?
Text content contributed to Wikipedia must be GFDL, so the foundation can sell it as long as they respect the authors' copyright and the terms of the license. Although the Wikimedia Foundation is not-for-profit, even commercial distribution would have been acceptable under the terms of the GFDL. But the content copyrights still belong to those who created it.
On the other hand, it happens that people contribute material copyrighted by other people, without their consent. According to U.S. law, Wikipedia cannot be held responsible for that, as long as they act quickly to remove infringing material. When physical media is distributed, that protection is no longer valid.
Not counting images and other media, yeah.
Every action in a contextual menu should be available by other means. Yes, you need modifiers for multiple selection in most programs. Menulings can be removed from the preferences of respective program / preference pane. That holds true for all Apple-provided menulings. Yes, many third-party programs require modifiers to perform certain tasks, but in many cases there are alternative ways of achieving the same thing. Yes, option was used to move the control strip. Using modifiers is not the same thing as requiring a second mouse button though. Very few programs do that.