codesecurely.org : Operating System Security

Mirror, mirror on the wall which is the securest of them all? Part Deux

rudolph — Wed, 21 Feb 2007 08:04:05 GMT

The story so far … And now for more of the adventures of Jack Bauer! ;).

So since I posted the first of this series I have to come to realize a number of key things:

There's seemingly people that agree with me at least partly that if nothing else "Securability" must be a first class player
All this who is more secure than who doesn't always make sense
The word securability is actually and surprisingly so not a word! (not if I have anything to do with it though J)
Lastly but perhaps most importantly I got pointed to a very interesting read by my co-worker Roman Hustad and that's where we will start this post.

The OLPC (One Laptop Per Child) is an endeavor to provide (every?) child a laptop – each costing about a 100 bucks. Now this is an effort in itself involving hardware engineering to what operating system will run on the machine and so on. One of the things this team has taken up on to itself is building security into the system from the ground up. None of this patch work and design augmentation etc. I believe these guys really get it. While I did post my Securabilty post a week or so before I ran into this I must say I couldn't say it any better:

<quote>

To provide an example, consider the Solitaire game shipped with most versions of Microsoft Windows. This program needs:

* no network access whatsoever

* no ability to read the user's documents

* no ability to utilize the built-in camera or microphone

* no ability to look at, or modify, other programs

Yet if somehow compromised by an attacker, Solitaire is free to do whatever the attacker wishes, including:

* read, corrupt or delete the user's documents, spreadsheets, music, photos and any other files

* eavesdrop on the user via the camera or microphone

* replace the user's wallpaper

* access the user's website passwords

* infect other programs on the hard drive with a virus

* download files to the user's machine

* receive or send e-mail on behalf of the user

* play loud or embarrassing sounds on the speakers

The critical observation here is not that Solitaire should never have the ability to do any of the above (which it clearly shouldn't), but that its creators _know_ it should never do any of the above. It follows that if the system implemented a facility for Solitaire to indicate this at installation time, Solitaire could irreversibly shed various privileges the moment it's installed, which severely limits or simply destroys its usefulness to an attacker were it taken over.

</quote>

They go on to describe their threat model and cover how one by one they have attempted to mitigate the threats uncovered as part of this model. They warn you that this does not mean their system is going to be completely infallible – heck they have even considered what would and should happen in the event of failure. In many ways these smart folks stole my thunder – my follow on blog post was meant to be a case study on how to build a securable system folks – but I will gladly give it up since these guys have actually gone much further and built a real world system. Only time will tell if they will be successful but if I were a betting man I wouldn't bet against it.

So to recap then what are some of the key aspects for you to take away as you consider building securable systems:

Document your security requirements. Understand what it is that you are trying to protect. What is the attacker persona? Who are you up against? Bring back all of the The Art of War books you've read.
Use these security requirements to build a deep and detailed threat model – one that covers the requirements from above but also what the threats are to your system, what countermeasures you have (or will have) in place to prevent those threats from being realized and finally where are you vulnerable – what are those weak spots?
Use the threat model to govern your system development effort from a security perspective:
1. Do the countermeasures you have or thought you had in place adequately protect you against the threats you thought they were going to protect you against? Have these been tested and exercised?
2. How about the vulnerabilities you are left with? Have you made a conscious risk management decision to live with these vulnerabilities. What is the long term plan to deal with them? What happens if one of them get exploited? Do you have an incident management plan in place?
Plan for failure and hence engage in defensive design and development. One of those vulnerabilities above might come back to bite you or worse still an entire new class of vulnerabilities that we might have never considered before might suddenly be discovered and guess what you are vulnerable as hell – what happens next? This in turn comes down to a number of basic principles which are age old:
1. Do you run with the least privileges needed to execute? Do you implement patterns such as privilege separation and compartmentalization?
2. Even with least privileges do you explicitly turn off or refuse those you don't and will never need? Think Solitaire from the example above or iTunes (which should have access to my music folder and perhaps some registry keys at most! – more on that in a future post). If you run within the .NET environment do you run in partial trust, do you use features such as Security Transparency and RequestRefuse?, if you run as a Java application have you configured the security manager? If you are running on Unix are you creating a chroot jail? Are you setting your effective user ID to a low privileged user account and leaving all the high privileged stuff for the parent process?
3. Have you tested your implementation and design against your threat model and security requirements? Does the "stuff" really work as expected? Have you looked through code to detect issues? Have you opened bugs for the stuff that doesn't work? Do you have a plan to fix those bugs?
4. Will you fail securely if failure is inevitable? Have you even defined what failing securely means?
5. Do you have the right amount of auditing and logging? Do you have an incident management and response plan in place? Has this planned been tested and proven to work or will get caught out when failure strikes the first time? Would you know whether to cut the red wire or the black one when something threatens to explode?

These last few bullet point is a good segway into the concept of Survivability.

<quote>

Survivability is the ability of a network computing system to provide essential services in the presence of attacks and failures, and recover full services in a timely manner.

</quote>

That's where the red and black wires come in – which are your most essential services? What can be turned off and the business will still survive? What does it mean to fail securely?

Finally, again the reason I believe this is important is because the true threats moving forward are not going to be to the web server running on your machine, they are going to be through the applications you use every day (think your email client, your word processor, your media player, your instant messaging client) to you and your identity, your social security number, your credit card information, your privacy! That's where I believe the OLPC folks have been truly innovative, have grabbed the opportunity and get it!

Mirror, mirror on the wall which is the securest of them all?

rudolph — Wed, 07 Feb 2007 06:50:30 GMT

All too often I get asked questions such as:

Which is more secure Microsoft Windows <Put your version of choice here> or Apple Mac OS <Pick your version here>?
Which is more secure Internet Explorer or Firefox?
Are two tier architectures – where my database is accessible from my web server in the DMZ less secure than a three tier architecture where all database access goes through a middle tier?
…

Much debate along these lines has been seen recently with the public consumer release of Microsoft's latest OS offering in the form of Vista. The Microsoft bashers will point to the fact that Vista already has unpatched vulnerabilities and it has barely been released. On the other side of the spectrum, a lot of Microsoft marketing and a number of security experts will tell you that security was the number one feature in this release and that is precisely why you should upgrade. I would almost be willing to bet that for all the experts you will find that would be willing to put themselves on a life support system hooked up to a public wireless network and running on Windows Vista, you would just as many that would refuse to do so unless the operating system is Apple Mac OS X.

So what is the correct answer? Which "experts" does one as a consumer believe? Well I decided to look at some of the statistics that people like to throw around as backing data for their arguments. Secunia.com is a wonderful site at times like these – and if I assume (and perhaps wrongly so – but I think we can for argument's sake) that they are the one and only definitive source of vulnerability tracking on the planet, then the numbers below can be trested as absolute. Before I go further though, I want to extract a promise from you the reader, irrespective of what side of the fence you sit on – don't assume I am on one side or the other at least until you get to the end of this blog post (I promise there is a method to my madness and the wait will be worth it J).

Ok let's talk about pure numbers since numbers don't lie some would say. Consider this:

or perhaps this

From the looks of these statistics it would appear that Microsoft has had 43% more vulnerabilities in their Windows XP Professional offering as compared to Apple Mac OS X. And you can take that number and write article after article and post after post claiming Microsoft is a lot less secure than Apple. But then someone will turn around and say Microsoft has got their act together in recent times and have invested a ton of money into security (which they have) and offer something like the following as evidence:

vs. this

But I wonder if the Month of Apple Bugs had something to do with this?

And then off course you have those that say well this isn't even an argument worth getting in to because I run on IBM OS/400 which is by far the most secure operating system on the planet while offering something like this as evidence.

Well, try telling to that to the one administrator of an AS/400 machine that fell victim to the one vulnerability that was patched in November of 2006.

Hopefully you see my point now, numbers by themselves are meaningless as are how many patches are released on Patch Tuesday. The reason this is so because each vendor (Microsoft and Apple in this case) has their own risk assessment methodology and patch release process. While Microsoft tends to fix single issues per patch / advisory, Apple on the other hand will tend to bunch up a number of fixes into a single "patch". While one can argue for a more standardized approach, at a high level I don't have too much of a problem with either approach. What I care about is that patches get issued, and vulnerabilities get fixed.

So that really brings me to the main point of this post which is whether it even makes sense to talk about numbers like these and get into heated debates about whether X is more Y? In my opinion the main problem with numbers is that unless they are taken in context they can be made to say whatever the presenter wants them to say. Hopefully the examples above have provided some evidence of this.

I think the question we should be really arguing about is which of X or Y is more securable. There is a huge difference in my opinion about someone saying their operating system or application or browser is more secure and saying it is more securable. If you look at the most common types of attacks these days that go after end-consumers if it is things like phishing and identity theft. In light of this what I as a consumer care about is what operating system / application / browser makes it the easiest for me to protect myself and the hardest for me to shoot myself in the foot which I will inevitably do. That is my definition of securability.

So with that said let's talk about securability – I think Mac OS X and now Vista both have capabilities and features that make them far easier to secure than their predecessors – an example being not running everything as an administrator or user account control (UAC). I think by itself will help alleviate the "I shot myself in the foot" problem to a large extent. Off course I think there will be vulnerabilities and I absolutely do not think that a year from now the graphs for either operating system on Secunia will be empty. The reason for that is it is not an easy task to get rid of every buffer overflow or every format string vulnerability. What you can do is mitigate the risk – compile your code with stack protection, run with least privilege, use default deny and so on. I think to a large extent the major software vendors and certainly from what I can see – both Microsoft and Apple have seen the value in doing this and will continue to do this. But in code bases with that many lines of code (50 -60 million from what I hear but who's counting J) there are bound to be mistakes that have been made, oversights and just things done which at the time they were done were completely correct but security research has evolved and will evolve to prove those very things to be huge vulnerabilities.

So are we all done then – we cannot get any better? Well not really, I think the next thing to get right is to chop privileges down even further. Sure we have made it harder for malware to install a kernel mode key stroke logger on our machines but how about that phishing site or that JavaScript which runs in the background or that email client which receives an email containing a malicious script that reads my confidential files. I think that is where the next evolution of software security should be going. How can we create true application sandboxes (and I know this word has been used and misused multiple times) which restrict what an application can and cannot do based on only what they need to do. We have attempted to solve the security problem of an attacker damaging the underlying machine and the infrastructure (operating system, applications etc) but how about preventing an attacker from hurting the user him / herself. How about preventing my email client or my browser (even if these are running min my context or heck in the context of the administrator himself) from accessing my Microsoft Money or Quicken files unless I the user explicitly allow that access?

Well for my thoughts on a more concrete basis – stay tuned. To be continued ….

Full disclosure: I am a Microsoft Developer Security MVP and receive a number of benefits from Microsoft as a consequence. However, this post has nothing to do with that relationship or the benefits. I would like to think I was and am completely unbiased. I should also mention that I also am an owner of both a Mac and a PC laptop on personal level but do use primarily Windows for work.