Linked by Thom Holwerda on Wed 16th Sep 2009 14:56 UTC
Mac OS X While Snow Leopard includes some improvements in the area of security, noted security researcher Charlie Miller, winner of two consecutive "Pwn2own" hacker contests and co-author of The Mac Hacker's Handbook, concludes that Apple missed the boat on security in Mac OS X Snow Leopard. "Snow Leopard's more secure than Leopard, but it's not as secure as Vista or Windows 7," Miller said.
Permalink for comment 384554
To read all comments associated with this story, please click here.
Yes its is FUD
by Hakime on Thu 17th Sep 2009 03:58 UTC
Hakime
Member since:
2005-11-16

Snow Leopard's more secure than Leopard, but it's not as secure as Vista or Windows 7.


This is total BS, really i am sorry. And again sorry Thom you are again making shame of yourself reporting it as it is.

First of all, there is nothing technical in your article, besides the claims from Miller who likes to spread FUD in order to attract sensational press on himself.

Speaking of "half-backed" implementation of ASLR when in the same times Miller or you fails to say exactly why, is totally meaningless? What is the technical point, what's going there?

Well, what it is really all about? From this point, everything that i am talking about is assuming 64 bits compiled apps running from Leopard and above, then those security features are on by default.

- OS X supports stack frame protection with a canary. Useful when trying to protect against stack overflow.You can also specify for increased security that every routine in the program will be checked by passing -fstack-protector-all to the compiler with the penalty of having a greater performance impact.

- On the stack and heap, the code is not executable to protect against code injection. Therefore on Mac OS X. it applied to stack, static data and heap.

- Apple specifically asks developers to use safer library functions. An example:

Consider this code

char buffer[1024];
strcpy(buffer, untrusted_data);

This code is dangerous as it may result to a buffer overflow if the untrusted_data happens to be bigger than the hard coded buffer size.

Instead use

char buffer[1024];
strlcpy(buffer, untrusted_data, sizeof (buffer));

This routine instead will truncate any data given to the function that is greater than the size of buffer, avoiding then a buffer flow. The inconvenient is of course that because it truncates data, you may end up with some data being lost if for example you are logging this information and you would want to track where the attack is coming from. A better solution would then to check the return value of strlcpy

char buffer[1024];
if (strlcpy(buffer, untrusted_data, sizeof (buffer)) >= sizeof (buffer))
/* Handle error */

That's the good way to handle string functions.

- But what if you have already a large program, you would then need to do hard work to change all the weak functions. In Snow Leopard, by default, the compiler will try to determine the array sizes, and if possible replaces the standard library functions with a more secure versions, like for example

strcpy -> _ _ strcpy_chk

It will pass the size of the buffer to the new routine and the routine will ensure that it never writes outside the size of the buffer. If it appears that it is the case, the routine will stop the program rather than to allow that it gets exploited by an attacker. Pretty neat.

- Extra heap consistency checks. In Snow leopard the heap checksum is randomized, that means that the attacker now has to manage to guess the correct value of the checksum and if the attacker fails, the program is terminated. This is particularly useful for web browser because it is unlikely that the user will just sit there and wait that the attacker guesses the correct value restarting every time the web browser after it crashed. Hopefully, the user will realize that the web page that he/she is trying to visit is something wrong. (On 32 bits app, the checksum is randomized but the program is not stopped leaving extra possibility for the attacker to be able to guess the correct value.)

- Permission changes. Some directories are no longer writeable by the administrator in Snow Leopard: most system applications (for the example the Safari plug-in directory is no longer writeable by the administrator) and /Library/ScriptingAdditions. And more similar changes to come.

- Avoid attacker to access to setuid tools. For that purpose, in Snow Leopard many system applications are now not using set-user-ID. AppKit will refuse to run setuid and ask for an admin password. Apple encourages developer that their executables are not setuid and instead use daemons backed by launchd.

- Domain Name System Attack by DNS spoofing. To protect against that, an UDP port randomization is introduced. DNS port has been randomized in Mac OS X 10.5.x. The results is that the attacker now needs to send considerably more packets to be successful, on average of billions packets. And in Snow Leopard, UDP ports are randomized for all protocols.

So far, all those features are on by default. Now the ones that are opt-in:

- Code layout randomization. System libraries are randomized since Leopard (you hear me Miller!!!). Since also leopard, executable should be built with PIE to me more randomized. So compiling executable with code layout randomization is not on by default even for 64 bits, but again you can activate it. On Snow Leopard, some system executable are now adopting code layout randomization.

What Apple should do from now is to enable more and more code layout randomization and that the third party apps gets compiled by default with it. But in terms of implementation, it is there.

- Developers can turn on sandboxing with the sandbox_init API. Five sandboxes are available: no internet protocols, no sockets at all, no filesystem writes, no filesystem write except temporary files and pure computation only. Custom sandboxes will be available in the future.

An application of sandboxing is for example that the H264 decoder library in Mac OS X is sandboxed. So if you happen to read a movie on the net and if it happens that the library has a security flaw that an attacker can exploit, the only thing that he can do is changing how the movie looks not the application which is actually using the library to decode the movie.

By the way, it seems that the sandboxing implementation on Mac OS X is well better than it is on windows:

http://blog.chromium.org/2009/06/google-chrome-sandboxing-and-mac-o...

So here we are, pretending that Apple does not do enough in security for OS X is plain wrong, plain wrong, If you take the time to read the developer documentations, you can find a lot of interesting informations about what Apple is doing, This is not the case of Miller (and surely neither you Thom) or actually i believe that Miller knows all of that, he just claims wrong or biased informations, again, when a guy is saying that windows is more secure than OS X, he gets the press to listen to him. Claiming that windows is magically more secure than OS X will turn the light to him so that the poor press and the poorly thinking people listen to him.

Claiming that because only one feature is not as well implemented in OS X as it is on windows, windows is more secure does not make sense at all, security is the collection of many technologies working together. Again the sandboxing implementation is much better on OS X than it is on windows, but does that make OS X more secure than windows? I don't think it is an argument.

So I hardly believe that only ASLR is the answer to everything that would make windows more secure. And i believe that i have proved that OS X is actually using a lot of features to enforce its security.

Edited 2009-09-17 04:16 UTC

Reply Score: 8