Apple Computers

Today I interviewed with Apple for a security researcher position, it's a position that has been open since something like August of 2005 and now I know why. Before I detail what occurred in the interview, let me elaborate upon my motivations behind being interested in a position with Apple.

First let me say, I am not a huge Apple fan, honestly the commercials drive me up a wall because they're largely filled with disinformation. I am not part of the 'cult of mac', but I am generally not someone who hates Apple either. However there is one thing that I am fairly certain of, they have the most insecure mainstream operating system currently on the market, and they're about five years behind the curve in regards to security. I'm sure plenty of people will turn their nose up at that statement, but let me explain. If we look at it from a coders perspective, it's NeXT dressed up as Unix for Halloween, except it lacks the evolution that has occurred throughout the Unix world, and the evolution that has made it's way into Redmond as well. On my PPC powerbook, the stack, heap, .data and .bss are all executable, my understanding is that on Intel mac's this is not the case, however they're lacking any form of ASLR, which makes the non-executable stack/et cetera more or less useless. Even more, the GCC on my Apple CD is missing stack smashing protection (SSP formerly ProPolice), which is something that comes in GCC by default, which means that they had to rip the extra security out of the compiler. A lot of people are mistakenly under the impression that SSP is only stack cookies, which is something it does implement, but it also does other rather unique things that make it a really great feature, namely it will reorder variables to minimize the damage of potential overflow.

So we have a relatively soft target platform, we also have an incredible monoculture never dreamed of in the windows world, not only is everyone running the same OS, but they're largely running the same hardware, or rather one of a few different types of hardware, this means that you have only 3 or 4 targets, whether it be userland or kernel exploitation, which means that by and large any exploit found will work fairly well, think about that for a moment in the context of a worm.

But, my dear mac friend, you may say, 'oh but the firewall!', and as previously pointed out by Jay Bealle, the firewall is useless as implemented. To bypass the TCP filter, you just need to fragment your packets because it will accept any fragment, to bypass the UDP filter you just need a source port of 53 or 67, because it allows anything with these source ports through.

So we have a soft platform, with a faulty firewall, and then one of the biggest dangers to OSX- its user base, how many times have you seen a random OSX user make some comment about not needing anti-virus or really to have any true concerns in regards to security, after all everyone is targetting windows, right? That is a very dangerous perspective that one of these days will eat the OSX user base alive, or so one can hope anyways.

So we have an uneducated user base, a soft platform, a faulty firewall and what else? One of the things that came out of the Month of Apple bugs that I found interesting was the format string bugs in the AppKit framework. Why? Because these are APIs written in Cupertino, and used by the same people in Cupertino, and they misused them horribly leading me to believe that they simply don't understand the dangers, for those wondering I'm specifically referring to the following functions:

* NSBeginAlertSheet
* NSBeginCriticalAlertSheet
* NSBeginInformationalAlertSheet
* NSGetAlertPanel
* NSGetCriticalAlertPanel
* NSGetInformationalPanel
* NSReleaseAlertPanel
* NSRunAlertPanel
* NSRunCriticalAlertPanel
* NSRunInformationalAlertPanel
* NSLog

Let me make sure my point is crystal clear here, Apple defined these APIs, then they misused their own APIs in a very elementary way that makes me question the basic comprehension of security by their developers, QA team and security engineers/researchers. Furthermore, while I am on the subject of the Month of Apple Bugs (which to be bluntly honest left me mostly unimpressed), these were bugs that were largely found, as I understand it, by fuzzing, feeding random data in a semi-intelligent manner to the applications.

So we have a faulty firewall, a soft platform, ignorant users and developers that don't truly understand what they're doing and extreme monoculutre; what we really have is a recipe for disaster.

So when I looked at Apple, I saw a company in distress, I see a company whose future is intersects with a major security incident, and naively, I wanted to help. The Apple team is running towards the cliff in a date with destiny, and that's not a threat, thats a prophecy. It's going to happen and it wasn't until maybe 20-30 minutes after my interview that I realized why nothing is being done to prevent it; they believe their own marketing hype. I'll get back to this soon enough though.

So my interview started around 1330 and I was greeted by a gentlemen who told me basically what they do and then proceeded to tell me that their phone was 'half-duplex' and that they could either talk or listen, but not both at the same time. I find this incredibly hard to believe, but I opted to not comment on treating me like an idiot and dumbing down the point that if I give a long answer I should pause every so often, thanks, I almost forgot how to talk to people, but with your guidance I'm sure I'll do great!

The interview started with pretty simple questions, they're going to ask me system calls and I'm going to tell them what they do and any security implications it might have. The first one was fork() .. Okay well it um, fork's a process, or create a child process, security implications would be largely the inheritance of file descriptors and that a fault in either one of the processes wouldn't affect the other, as opposed to threads. They wanted more, but I couldn't think of anything and I still can't, the next was execve() which we talked about some mostly about failure to sanitize possible user-input and relative paths/et cetera, then I was asked how a process would drop its privileges, and I mentioned setuid()/setgid() and we discussed that some and then I was asked how I would drop privileges if I wanted to regain them later, and I commented that it probably wasn't the answer they were directly looking for but that what I would do would be to keep a parent management process that listened on a Unix socket to perform privilege seperation and that if a child wanted to restore it's privileges that it would make a request to the parent to create a new privileged child and pass on the file descriptors.

Here's what shocked me, I was told I was wrong (!!), they were obviously looking for some about saved/effective uid's and such but that's pointless because you might as well never had dropped your privileges, or to say it another way, if you can regain your privileges, you never dropped them.

I was then asked about how if I had this *large* code base of like 30,000 lines of code and like two days to audit it, what would I do. Firstly, let me comment that 30,o00 lines is not large, its fairly common, but whatever. I said that I'd look for usage of functions known to have problems traditionally and look at the core internal API and see if it can be misused. They asked me how I would do that, kind've making it sound like I was oversimplifying the situation and I commented that it typically wasn't that hard, grep or look at the filenames as there is typically things like alloc.c or similar, then work backwards from there. This again was met with resistance and I said that it isn't like this is hypothetical, this is what I do for a living and then they said something like 'While I can appreciate that you supposedly do this for a living, I was asking for a real answer' at which point I had enough and told them that I didn't like their fucking attitude and that this type of arrogance is why Apple is in the midst of such a security nightmare, that I wasn't interested any longer in a position with them and then proceeded to hang up.

Then about five minutes later I got a call back from the recruiter, asking what had happened and she started to laugh when she repeated back my line about the security nightmare and I realized what the problem really is, they're mistaking beginners luck for skill. When I say beginners luck, I don't mean beginner to the computer industry, but rather beginner to the 'real' industry; up until OSX they were a tinker toy OS that was largely disregarded, then they stepped up and put themselves on the same level with Microsoft and Unix, and they seem to think that just because no one has ripped them apart means that no one can. Even worse they don't seem to recognize that their arrogance makes enemies, and generally speaking they're not the types of enemies that a software vendor wants.

So fuck it, here's to you Apple and to your future insecurity, I wanted to help you and instead you just ended up with another person interested in auditing your software.