I became aware of a new paper on developer.apple.com today. It’s about secure coding guidelines. I quickly skimmed over it, here is my preliminary report:
Page 10 covers a list of usefull books to read in addition. There is however no mention of “writing secure code 2nd edition” by Michael Howard and David LeBlanc. While the book is somewhat windows centric it is one of the best books out there
regarding secure coding, and a lot of whats mentioned there can be applied to unix aswell.The book does get mentioned later on when they cover threat modeling, but it deserves more credit imho.
No platform is immune:
“So far, Mac OS X has not fallen prey to any major, automated attack like the MyDoom virus. There are several reasons for this. One is that Mac OS X is based on open source software such as BSD; many hackers have searched this software over the years looking for security vulnerabilities, so that not many vulnerabilities remain. Another is that the default installation of Mac OS X turns off all networking services that might be used to exploit vulnerabilities. Also, the email and internet clients used most commonly on Mac OS X do not have privileged access to the operating system and are less vulnerable to attack than those used on some other common operating systems. Finally, Apple has an active program of reviewing the operating system and applications for security vulnerabilities and issues downloadable security updates frequently.”
The fact that something is opensource software and that it has been audited before is no guarantee whatsoever that it’s more secure then a commercial equivalent. There has been a lot of disscusion around this, and people have concluded that it can have the potential to be more secure but it doesn’t have to be. In this particular case they use BSD as an example. Every once in a while I audit BSD code, and there is nothing magically secure about it, plenty of security bugs in there to go around.
So OSX turns off all network deamons by default. But the firewall is off by default last time I checked, there is dhcp parsing code IN THE FUCKING KERNEL, and it does send out an recieve mdns constantly.
So the email client, browser, and other utils don’t run as root. So if you own them you don’t instantly own the box. That’s what local root exploits are for, it’s a very common 2-step thing! I know this is defense in depth, but I wouldn’t go so far as to brag about it, it might bite you in the ass later.
The Idea that apple’s browser and email client are less vulnerable to attack then others is total bullcrap. In fact, the opposite is true. When I did browser fuzzing safari was ALWAYS the first to break. It’s simply not up to par with IE and Firefox when it comes to parsing input !
I guess “frequent” is a relative term, as sometimes 3 or 4 months go by without a single security update
only to get followed up by a MONSTER security update (40+ vulns fixed in 1 update). Also “frequent”
doesn’t say anything about consistency, it would be nice to have something like patch tuesday for osx.
Types of vulnerabilities:
“There are two ways in which heap overflows are exploited: First, the attacker tries to find other data
on the heap worth overwriting. Much of the data on the heap is generated internally by the program
rather than copied from user input. For example, an attacker who hacks into a phone companys billing system might be able to set a flag indicating that a bill has been paid. Or, by overwriting a temporarily stored user name, an attacker might be able to log into a program with administrator privileges. This is known as a non-control-data attack.
Second, objects allocated on the heap in many languages, such as C++ and Objective-C, include tables of function pointers. By exploiting a buffer overflow to change such a pointer, an attacker might be able to substitute their own data or to execute their own routine.”
This is somewhat short on information. Specifically it doesn’t explicitly mention messing with heap metadata. Which is what most heap exploits out there do. And this is very much possible with the osx memory allocator, infact there was a phrack paper about it: http://www.phrack.org/phrack/63/p63-0×05_OSX_Heap_Exploitation_Technqiues.txt
Types of vulnerabilities: social engineering.
While social engineering is certainly a security issue, It has NOTHING whatsoever to do with secure coding guidelines. Social engineering is also mentioned on page 66 and 67.
There is a list of insecure functions and then the more secure equivalent of these functions that should get used. Unfortunatly, some of these more secure functions have some known issues that one should be aware of, they are however not mentioned. More specifically I’m talking about snprintf and fgets. Also it fails to mention the scanf* functions, which I believe should really be in there.
I blogged about snprintf abuse earlier:
With fgets, it is very common to overwrite the \n character at the end with a 0byte. often
if (fgets(s,len,stdin) != NULL)
s[strlen(s)-1] = ”;
is being used. The problem here is that it’s possible to have zerolength strings and effectively causing an off-by-one underflow. (if you don’t believe me, download some opensource software and grep for fgets!, it really is very common).
secure file operations:
“9. Compare the device and inode numbers in the stat structure obtained before you opened the file with those in the stat structure obtained after you opened the file to verify that they are the same file.”
This is just wrong! just because file x has ino y and is on dev z at time n-1 doesnt mean that at time n the file with ino y and on dev z is file x ! Ok, so this might sounds a bit confusing, there is actually a nice mailing list post about this: http://www.opennet.ru/base/audit/17.txt.html
There is a reference to “building secure software” for more info on how to prevent file race conditions. Unfortunatly the info in there is flawed and suffers from the same issue as page 46 step 9 as described earlier.
“Because launchd is a critical system component, it receives a lot of peer review by in-house developers at Apple. It is less likely to contain security vulnerabilities then most production code”.
And yet when I audited it last year It contained a textbook example of a file race condition (see http://www.suresec.org/advisories/adv3.pdf for more details). More worrysome is that at the time the todo file stated (and I quote): “code review”.
a code example, and that’s not confusing because ….
Page 69 mentions threat modeling, but forgets to mention “Threat modeling” by Frank Swiderski and Window Snyder, which is basicly THE book about threat modeling, it covers nothing else !
There were some things I really liked about the paper:
mention of david wheelers secure programming for linux and unix howto. That one is actually REALLY good. I wonder why David never turned it into a real book (as in, get it in a professionally printed version).
There is a list of insecure functions and then the more secure equivalent of these functions that should get used. It mentions the more secure replacements for strcpy, strcat, strncpy and strncat. Namely strlcpy and strlcat, 2 functions designed by some of the people of openbsd, for more info, see http://www.openbsd.org/papers/strlcpy-paper.ps
functions to “change privilege level” I like how they specifically say to watch the return value (hi vixie cron) and that those calls are confusing and differ across different unices.
So, a conclusion is in order here I guess. There were some dissapointing things in there, first off, there was no mentioning whatsoever about fuzzing, and testing code was only VERY briefly mentioned. Likewise almost nothing was said about secure kernel programming. The only thing that got briefly mentioned regarding kernel programming was to use Kauth and to be carefull which modules you load if you make a helper program that needs to load a module. Imho there was too much marketing in the paper, I don’t want to know why osx is more secure then something else
(wether or not it’s true) I just want to get the facts about writing secure code for osx. I feel this paper didn’t get much (or adleast not enough) peer review. It’s too incomplete. Lastly there is a fair amount of usefull content in there, but please, take it with a grain of salt.
edit: The cat is out of the bag, the bug in cron I hinted towards (see page 55 comment) got fixed not too long ago: