Apple Security Update 10.3.9, Analyzed
I have a confession to make. I’ve spent way too much time thinking about patching, and secure programming technique. This week’s Apple security update is interesting to me for a few reasons. Two side comments before I delve into the nitty-gritty.
What’s with releasing this at 5.30PM on a Friday? If Microsoft had done that, they’d have been drawn and quartered. Secondly, what’s with making me agree to a new license for a security update? How about (at worst) “This code is licensed under the same terms as the code it updates. The license is included below, and you need to agree to it to continue.”
This post is more technical than most, but some readers may want to read what’s after the break.
The first thing that I noticed about this it’s mostly about core Apple code, the kernel. A great many of Apple’s security updates are about somewhat peripheral bits of open source code, like their ftp server. (It’s so peripheral that I only know one person who noticed the bug that caused them to re-issue that patch. The bug completely prevented you from using the ftp server. He was most put out.)
Either Apple code is better than other code, or it’s not being attacked as aggressively. My guess is that it’s the latter, only because writing secure code is still a specialized and rare skill.
This update is actually part of an OS update, rather than a security pack. The update fixes 8 issues. The first two bugs are in unused features: 0969: “The kernel contains syscall emulation functionality that is not used in Mac OS X…” 0970: “Apple does not distribute any SUID/SGID scripts, but the system would allow them to be installed or created.” The next two are privilege escalation for credentialed users. The other three kernel bugs are all listed as local denial of service attacks. The final issue packaged here is Safari. I wish they’d unbundle that one, because as the only user of the machine, I’m not that worried about local users escalating their privileges.
So looking at this, 25% of the update could have been avoided entirely if someone had combed out unused features. That can be a hard decision to make: you might expect to use the features in the future. Removing code can lead to bugs, which is a little counter-intuitive, but all changes to code involve people doing things, and people make mistakes. When the changes are complex and widespread, the odds of problems go up.
Still, it’s worth noting. Removing unneeded code cuts the odds of security issues, makes your product faster, and makes customers less unhappy because of your patch stream. Faster? Because no line of code executes faster than no line of code.
Anyway, there’s my thoughts on this thing. I just had to get it off my chest.