1. We’re here at GoToCon Copenhagen 2012, I’m with Graham Lee. Graham, who are you?
Hi, you mentioned I am Graham Lee, my job title is Smartphone Security Boffin, which kind of means I do mobile application security as you might imagine but also iPhone software development and Objective-C programming. I am with a company called O2, which is one of the big mobile network operators in the UK, on their Lab. So this is a team that’s focused on discovering new applications, building new products for the rest of O2 to evaluate and use. I also do some security consultancy for external developers as well and talking at conferences.
Right, we can talk for a while and try to dispel that myth, but let’s put that to one side, even if the operating system itself is doing everything it’s ought to, has no flaws or vulnerabilities in it, you can still build applications that are insecure because the operating system can’t possibly have any knowledge of what your information means or the data in your app is about, who cares about it, whether they believe it’s supposed to be confidential, whether it’s supposed to be high integrity, so it really doesn’t matter from the perspective of application security. Yes, if there are problems in the operating system, they can be used by an attacker, but the attacker has some goal, and that goal is usually targeting the data in the application and so the application itself still needs to be aware of its environment; there will be some risks it needs to mitigate.
It runs the whole software lifecycle, really, so as I mentioned we are in an advanced product type group so what will often happen is that one of the developers will say "I have this kind of idea for an app and here it is, I’ve built a version on my phone". And that’s really the best time to start thinking about security, when your project is in the early stage, when you are trying to define what it is, who will use it, what it will be used for, because that’s the time when you get to change anything you what, when the application is a sheet of paper or it is just a demo on one person’s phone.
You’ve got a great chance to ask them questions: who is going to use this thing, what are they going to use it for, will they be worried if somebody else gets access to this data, will O2 be worried if somebody else gets access to the data? And we can start planning what we’re going to do there and designing the security into the application from the start. But then again of course you have to have code reviews, buffer overflows as you mentioned, the iPhone code is built on the Objective- C language. Objective-C is C with a bit of Smalltalk style, object stuff on top and as we know, C is the perfect breeding ground for the buffer overflow, it’s almost like it was designed to be a crashy language. These things are real and a well-designed but poorly implemented application can still expose its users, its developers to problems.
So this goes back to what you asked in the first question, isn’t the iPhone secure? It doesn’t matter in this case whether or not there were any vulnerabilities in the address book framework, the address framework allows you to read the data in the address book, that’s why it exists. And so it functions correctly in giving the app the data and then the operating system doesn’t know what the app intends to do with that data, so it doesn’t worry if you try to pass it up to the server. What people were concerned about with the Path problem, is not so much about sharing, people like sharing.
Facebook has 900 million users because people like to tell other people what’s going on or what’s on their mind, Twitter has over 100 million users because people like to share, to upload photos, to talk to each other, to give each other information, they also like to be in control of that, they like to know who they’re sharing with, what it is that they are sharing and what they can do to stop that. So the problem with Path and other applications that where uploading your address book to their service, they were doing it so they could find out whether any of your contacts were also in this application and could recommend that you add them as contacts in that app. Which sounds like a fair goal, but the fact that they get all this data that you didn’t necessarily explicitly choose to give to them and that they might choose to do something else with it, this is why it was a problem.
There is a more interesting question than whether it was right for them to upload your data, because is it really your data, if I give you my business card, do I own that information or do you own that information? Now, if I own it, do you have the right to upload it to Path servers in the first place, whether it’s through choice or through accident, is it actually yours to share? Should operating systems track the ownership of the data that is used and the valid uses of that data and do some sort of access control so that I can say "my app is allowed to access my address book but isn’t allowed to push that data over the network"? That is a bit scary because it sounds like DRM and people don’t really like DRM, but on the other hand what are the alternatives? The thing that people suggested as a reaction to "Pathgate", I suppose you can call it, is why don’t Apple just put a modal dialogue in, so when your app tries to use your address book you get a pop-up saying "do you want this to happen?", which you already get with your location and with your Twitter account in the new version of iOS. Imagine that they added that, and then we find that apps are uploading your photos from your photo reel and we put another modal dialogue in there, and then we find some other data store that they are able to read and so start uploading that information. And then we put another modal dialogue on there.
Eventually, iOS becomes Windows Vista. Do you want to confirm or deny for every action the phone allows, that is not a scalable solution, is not even a solution at all, because the people who know how the software works and what the software is meant to be doing, are the people who wrote the software and the people that decide, the people at Apple who decide the policy for the AppStore, they are the people that should be fixing this, they should be pushing the questions out to the users, that’s basically saying "sorry, we give up, we don’t know what we are doing anymore, so we’re going to ask you, we know you are not an expert but we’ve decided not do any work to solve this problem". So, the profusion of modal dialogues isn’t a solution, but, you know, what is?
It definitely adds problems. It does solve problems, the difficulty is they tend to be problems that developers don’t have. So the goal of the Mac sandbox is that when my application is running in the sandbox, it’s restricted in what it can do as my user account, which means it limits the damage that that app can do to other apps. So, as the developer of the first app, do I care if another app breaks? Perhaps it would be bad, it would get me bad reviews if my app was known to be breaking somebody else’s, but if my app is happily working fine and then Apple say "there is this new bunch of restrictions we are going to add and you are not allowed to sell your application through us until you comply with them", and it doesn’t add any benefit to my application or to users who are in my application but it does add engineering effort then you can certainly see why people are reluctant to make the changes and are frustrated and angry at the fact that some of what their application needs to do, which Apple have been happy to sell right up until now, can no longer be done in that context.
It is widely used, the biggest example I can point at is Java. The Java Virtual machine restricts what apps running in Java are allowed access to on the operating system. So, if there is a problem in the app and the app starts running away and comes under the control of an attacker, let’s say that there is some way I can load an additional class into a Java app and get its main function executed or something, what that can do is restricted by the sandbox, which is often implemented as a set of access control switches and a policy for what code is granted what access.
In the case of the Mac applications sandbox, it’s a set of access controls in the kernel to gate the results of system calls, so if I try to call 'open' it enters the kernel, inspects what file I’m trying to write or read, looks at a set of rules which are written in the Scheme language, so it’s got a list of paths and regular expressions to match against, if the outcome of evaluating those rules is that I should be denied access to the file then it would just return from the system call without doing anything. And you can do this not just for files, but for network access, for interprocess communication, for access to hardware devices, so you get to, in quite a fine grained way, control what an application is allowed to do. Which is different from the access control already existing in Unix systems, which is all based on the user, so most people are probably aware that Unix has a root user that is allowed to do anything on the system and then you have users with different restricted sets of privileges and you can control whether user Graham is allowed to access user Barbara’s files or whether he is just allowed to read those files or whether he’s allowed to write to them as well.
That’s existed for decades and it’s a form of sandboxing in itself. But what we haven’t had on Unix platforms on the Mac until very recently is the ability to say "these applications are actually different actors, they’re not all representing me, the user account holder, they’re representing their developers and what they want to do with files that I have access to. So we should give them different levels of access to the system than just having all the system access I do".
If you look at this kind of Scheme rules engine, as independent or third party developers we are not actually supposed to use that rules engine directly we’re supposed to use the set of entitlements, so there’s a series of checkboxes in your application project that allow reading and writing to files, access to the photos, to the cameras, to USB and so on and so forth. But the way those rules are written is with this very fine grained and general language based on, as I said, on lists and Scheme. Now you could have a very very tightly restrictive policy that allows an application to do just exactly the things it needs to function and nothing else using this Scheme thing, but it would be incredibly hard to get it right. So what Apple have done, which is a bit more of a pragmatic solution is to say "you can turn on these coarse grained features and if you don’t turn them on then you don’t get them at all." Which is a compromise to make it easy for the developers to know what it is that their app needs to do, in return for getting quite large switches of behavior in the sandbox.
I don’t know about popularity. Along with the application sandboxing functionality, version 10.7 of Mac OS X introduced XPC, which is effectively an interprocess communication framework, that’s designed very much for factoring a single application with multiple processes, so it’s not a general thing that you use for communication between like a daemon and a UI. It’s something you use to break a single application up into multiple components and then you can apply different restrictions to each of those, so a common example would be if you’ve got some application, let’s take a Twitter client, because that’s the Hello World of the 21st century, so I’ve got a Twitter client and what it needs to do is to download this list of tweets from the network, organize them into some data model and then represent that on the screen.
That’s three different pieces of functionality, I don’t need network access in my screen drawing code and if there is some way that an attacker can break my screen drawing code, I don’t want them to be able to download shell code and run it, so I don’t that to have network access at all. So what I do is I break my Twitter app into the app and the network helper and I use this XPC to send requests and receive responses from this little helper bundle which in turn will contact the network on the app’s behalf and pass the data back in, so I get to isolate the risky components of my application. Whether that will lead to a resurgence of native code development, I think there are other issues at stake such as whether where the developers have their experience, where they ‘re happy to work, there are plenty of Objective-C programmers on the iPhone platform that are starting to look at Mac applications as a way to work and because they’re already familiar a) with Objective-C and b) with being with a strongly restricted sandbox environment that the iPhone supplies, they’re quite happy to stick with native code, whereas people who’ve been doing, let’s say MFC programming on Windows, yes, they are writing native code but it is completely different from the way that it would work on Mac OS 10, so they might be looking at some cross platform thing whether it’s native, or there would be or they decide to go for a Java or even a mono, C# type platform.
That’s true, security is only one part of the software engineering process, there are times when you need to make an architectural decision based on the security posture of your app, but really it’s just one component of the development process. So my answer has to take into account the rest of software engineering, you can’t say that because of security you have to use PhoneGap or you have to use Objective-C, or something like that. And so, what we find is that there are tradeoffs in doing HTML5 web applications targeting the mobile web and doing native applications that target the phone’s frameworks. For a start, not all the functionality of the phone is exposed through HTML5, now there are people on my team who are working with Mozilla on the open web device and on the Boot2Gecko project which is going to be delivering an HTML5 based complete smartphone operating system that will expose all of these features through JavaScript.
Now, whether that will all get adopted by the rest of the players and actually be available on iPhone or Android or Windows Phone is still an open question. But the fact that not all the features are available now, does mean that if you need one of those things you don’t have this choice, if you need to access some particular parts of the hardware then you have to go native as it were. On the other hand, one of the nice things about delivering a web app is that you are completely in control of the deployment and the distribution. If there is some kind of problem, someone’s found a bug or a security vulnerability, you need to get that fix it out now, you can do that, you write your new version, you hopefully test it, and then you push the new version to your server and it’s live, everyone who uses the app from that point onwards has a new version.
With native code, particularly on the iPhone, you have to get your application submitted to Apple in a particular way, they then go and review it and approve that, and they do have an expedited review process so if you have some very serious bug you can email them and say "I really need to get this out as soon as I can". Of course they are not going to promise any particular timeframe, so it could be somewhere between one day and one week, perhaps even longer before your change gets out to the store. But, on the other hand you’ve got the high visibility that goes with the app store and the greater feature set that come with native apps, so there is this trade off. And I think for a lots of line of business apps should be going mobile if they haven’t already, then I don’t particularly need to be sat in my office plugged into the internet to do what my work entails. And so they shouldn’t be internet applications, there shouldn’t be a restriction on how I do my work. For those kinds of applications, then a mobile web interface is probably the best option, because once you get this control of the deployment, you get to limit access using whatever network infrastructure you already have in place. With a native app, you can’t do that so much, but as I said you get the richer features sets of the phone, so I think they both have a place in the future of the mobile app.
Right. So, Objective-C was written in about 1985 by a man called Brad Cox who wanted to marry the kind of performance you get or at least you got in 1985 by having a native compiled language with the object oriented design paradigm expressed through Smalltalk. Now I’ve heard people describing Objective-C as having all of the elegance of C and all of the performance of Smalltalk as well, so opinion is divided on this matter as well. But I was reading very recently the Smalltalk-80 book the people at Xerox wrote about the language and I realized there is a lot of stuff in that that we don’t have in Objective-C and it would be interesting just to try it out and to see whether it really works like the object browser. In Smalltalk the IDE is a very graphical thing whereas in Objective-C we are still using a text editor, it might be a fancy text editor that’s got a compile button on the front but it’s still a text editor with fixed width fonts and usually 80 line columns just like a punch card.
Well, we don’t really need to be using a punch card style interface anymore now that we’ve got rich multi touch screens and the ability to do interesting animations and 3D effects, so why don’t we try to kind of sex up the idea a bit and have an object browser for Objective-C. So that's what I’m looking at the moment, it's helped a lot by the advances in the compiler technology, so for a couple of years now Apple have been developing along with the open source community the Clang compiler which is a front ends to LLVM. Both of these things are libraries for implementing compilers, so the fact that they have an Objective -C compiler and a complete tool chain is a side effect to having built these libraries for doing each of the different steps like parsing the syntax tree generating, code generating and the machine language generating. What this means is that as in Smalltalk, the compiler is an object, which is something that Brad Cox talked about when he was describing the Objective-C in his book as well, but that we never had in Objective -C, the ability to just inside the IDE, take code, compile it and then add it into the process and start using it effectively as an extended REPL, I guess. I just thought it would be interesting to see whether this was possible, which I believe it is. I now just need to get the time required to actually build this thing.
11. So this was all made possible by a Clang, essentially.
Well if it wasn’t made possible, it was made a lot easier. If someone who is mainly applications programmer I didn’t really have any understanding of how a compiler works, if something like object oriented black box is going to go, "I’ll do compiler magic you just give me the stuff and I’ll sprinkle pixie dust on it", I’m very happy and can get things done that I would never have been able to do before.
Yes, the Clang interface as well as being able to compile things and generate the tree, will also give you tokens so you can do syntax highlighting, it will do potential tokens as well so you can do code completion, you can say "I’ve got this text in this space here, what do you think it can possibly end up being" and you get a call back saying "oh, I found these half dozen options and you can do code completion". Something that I see a lot of in the Objective-C community, people are kind of getting a bit frustrated with XCode at the moment, which is the IDE that is used for Mac and iPhone development. And the reason is the current release has quite a number of stability problems and things will suddenly stop working, every so often you’re in the middle of editing a file and the syntax highlighting disappears.
So you’re looking at essentially a text editor. So if it’s easy enough with a couple of hours hacking in the evening, I can at least understand how this library works. And we’ve got a bunch of application developers who know how to make applications and who don’t like their IDE, "why haven’t we made a different IDE yet?". And so I suppose a lot of what I want to do isn’t necessarily the end goal of having a Smalltalk object browser, although I definitely think that is interesting, I would like to investigate what that allows, whether it changes the way we do Objective-C programming, what I would also like is to just say "hey, we can do this stuff, why isn’t there a third party community making more tools, making its own experience better", because while we are software engineers, iPhone and Mac programmers in my experience have a very keen idea of the importance of the user experience and a very good focus on user goals when developing their apps, why aren’t we doing that for ourselves as well?
13. It’s always a question, why do we use tools from the 70’s?
Yes, as I’ve said we are effectively laying things out in the same way you would do to load them into a batch compiler. We don’t need to anymore.
14. As we are getting to the end, I think you’ve been busy writing books.
It keeps me off the streets, I guess. I have two books out at the moment, one is called Professional Cocoa Application Security, it’s mainly for Mac application developers, there is information that is useful to iPhone programmers in there as well, stuff about the Objective-C language and the foundation framework and how the address book and so on apply in both contexts equally well. And I recently published a book called Test Driven iOS Development, which as the name suggests, is about TDD with a focus on writing Objective-C applications on the iPhone. There have been plenty of books on testing driven development, most of them use languages like Java and C#, which is understandable because those are really popular languages. Objective-C is perhaps different enough that readers coming from that background might not be comfortable with reading examples in Java and of course there are idioms both in the language and Apple’s frameworks that it is good to see strategies for testing with those idioms in place. So that’s why I tried to do with that book.
15. So finally to wrap up, final question, you are available for Morris dancing?
I knew you were going to bring that up.
Listen for the sounds of the bells, I guess. But my Twitter handle is @secboffin, that’s the best place to find me.
17. So for next May we will contact you and you will bring your bells.
Well I’ve done it at a conference before, so don’t wish for things you don’t want to come true.
Community comments