Mon, 27 Oct 2008

Open Source VS Closed Source and Security Implications Thereof

Note: I'm going to completely ignore the classic Reflections on Trusting Trust or Countering Trusting Trust through Diverse Double-Compiling but I do recommend reading them as they are both quite interesting. There are a lot interesting things that have happened, and are happening, in this area but they are entirely outside of my philosophical argument contained here.

I'd like to put my thoughts down on something I've been hearing for years now. Is the assertion that open source means better security true? I'm going to argue that this assertion is false. My position is based entirely upon my opinion, semantics and philosophy.

Take, for example, the following code: 

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[]) {
    char buf[1024];
    strcpy(buf, argv[1]);
    printf(buf);
    return;
}

Does the license under which that code is distributed (or not) have any bearing on the fact that it's horrible code?

To think that the code being open or closed affects it's security is absurd. The fact that source code is available under any license does not have any affect on it's correctness - from a functionality, completeness and security perspective. There is a lot of open source (however you define that term) code in the world. There is also a lot of closed source code in the world. How the code is licensed doesn't matter if it's not being reviewed by subject matter experts. If I were to write a program that used the above snippet of code (and I can see at least two major vulnerabilities with it without even thinking) it would be equally as insecure regardless of my choice to make it open source or not.

Open source code does not mean better security. You need only to look at every Debian (and Debian derived distributions) used over the time-frame that their OpenSSL library was crippled to see my point. The code in question was open source, but nobody noticed the bug for years. Nobody even noticed that the change was a bad one when it went into the Debian tree. So if open source code does not mean better security does closed source code mean better security? One could easily envision a closed source vendor making the same mistake as Debian.

The difference between the two scenarios is that it would be inherently harder to find this mistake in a closed source tree due to the lack of access by the general public. The key piece is that open source code results in a lower barrier to entry for subject matter experts and hobbyists to review the code. The important distinction to make is that access to the code does not equate to review. This ensures that the code can be reviewed but does not ensure that it is reviewed. Does this mean that closed source code is not reviewed by subject matter experts because they can't get access? Absolutely not. I know many people who do source code audits on both code bases and in the case of a closed source tree they are always required to sign NDA documents (in truth, they are often required to sign them even for open source code audits as the findings are what are not to be disclosed). Do not make the assumption that open source means reviewed.

This entire position is based upon the premise that open source results in audits by honest individuals that will work with the vendor to fix the bug. There are people in the world who will not do that. They will either release full details of the bug before a patch is out or they will simply sit on the bug for their own benefit. In this case closed source is a good thing because it raises the bar for audits. They have only the binary to use in their audit, which is significantly harder to do.

The security of a piece of code is independent of the license under which it is written. Open source does make things easier to review. Closed source may be a good thing if your threat model is right. Don't assume that open source code has been audited. Don't assume that closed source code has not been audited. At some point you have to trust people to do the right thing, because who knows if your compiler has been compromised. ;)

posted at: 18:27 | tags: , | path: /entries/security | permanent link to this entry

Fri, 29 Aug 2008

Seriously, it's not _that_ big of a deal.

I love the security industry, I really do. I love how people jump on bandwagons, make big deals out of stories that are not a big deal and generally spout off about things to get attention. If there is one thing in the world I could change it's the news - stop giving me your opinion, give me just the facts and let me make up my own opinion on the matter. These pundits (for lack of a better term) will be the first against the wall when I become king.

Earlier this week a bug was reported in the iPhone that allowed for a bypass of the passcode to unlock your screen. Immediately we get people (like gizmodo (you are a horrible website - possibly worse than slashdot)) spouting off with mis-informed information and their opinions. This does not instantly give full control over the iPhone. There are a couple of conditions that have to be met first:

  1. Must have physical access to the phone
  2. User must use the screen lock (if they aren't then game over already)
  3. User must have contacts listed (who doesn't have contacts in their phone)
  4. User must have a list of favorite contacts
  5. Must have other applications linked with that contact (a URL will link with Safari, etc)

It's safe to say that the first three are a given for this scenario. I don't know anyone who has an iPhone (I don't own one) and doesn't use a screen lock and doesn't have a list of contacts.

The really interesting part is the last two. These are things which are not on by default. It's not like your most-called contacts are automatically added to your favorites list. My informal survey of a half-dozen iPhone users did not turn up a single one that used a favorites list or had anything besides a name, picture, and phone number for their contacts. It wouldn't surprise me if this is uncommon though - given how the iPhone syncs with your address book. But still, they would have to be in your favorites list for this to work and that is something which requires the user to setup.

This is a serious bug but I really don't suspect people stealing iPhones are doing it to get at your personal information. They are likely after the hardware to sell. Yes, Apple has a poor record on security patches but don't make this one out to be bigger than it is. Yes, it's a silly bug which impacts security. Yes QA should have caught this. Yes, the entire design should have been questioned from the start. But it's not the end of the world, there are a lot other major bugs out there which deserve more attention. Don't jump all over this one because it's Apple, even if they have a poor security record in a lot of areas.

posted at: 20:10 | tags: , | path: /entries/security | permanent link to this entry

Fri, 15 Aug 2008

Why Announcing Security Bugs is Important

By now I'm sure everyone has heard of Linus' "... the OpenBSD crowd is a bunch of masturbating monkeys ..." comment. There is now a follow-up article on it that I feel the need to comment on. To quote the follow-up article: 

He says neither camp is absolutely right in any event, and that a middle
course, based on fixing things as early as possible without a lot of hype, is
preferable.

I want to draw attention to the "without a lot of hype" part. If my bank has a security hole which puts my account at risk I'd hope they would 1) fix it as quickly as possible and 2) notify me that my personal data was exposed. I'm saying this as a consumer of my banks services. As a developer - which Linus is - then a security bug is just like any other bug: fix it and move on. As a consumer, who has data at risk because of the bug, then a security bug is much more important than one that just affects stability/reliability of the system.

The flip-side is also true. If I'm a consumer of a system that is used to x-ray people and there is a bug which causes the system to emit deadly amounts of x-rays then I would hope the vendor would notify me of that bug so I can act accordingly. In this case it is not exposing sensitive data directly, but rather the stability/reliability of the system is causing a security problem (physical harm).

It's important to understand Linus' viewpoint. He's a developer. He wants to get the code as correct as possible. From this viewpoint a bug is a bug and they should all be fixed quickly. This is a perfectly admirable thing. The problem is people use Linux in one of two ways which conflict with this viewpoint.

First, they can consume it for use in their own product. This means that any bugs in Linux need to be fixed in the product if they affect the product. As such the developers of this product need to pay close attention to the development going on in Linux so that they can cherry-pick the right fixes. By advertising security bugs you're making the cherry-picking job easier. This doesn't mean the people who are doing this cherry-picking of fixes needs to completely ignore all other bugs. Companies need to look at all the changes to make sure none of them affect your product because they, and they alone, know best where their product is being used thereby giving them the best insight into how all bugs affect them. For example, if a company is using Linux to control an x-ray machine then they need to pay attention to any bugs which may affect the control of that machine, because the outcome of those bugs may very well be a security risk despite the bug itself not being a security risk.

The other way people use Linux is to actually develop it. As such security bugs still affect them like they affect everyone else. The difference is they, being developers, should understand the implication of the fixes as they are going into the tree. It is this viewpoint that Linus is trying to use, and from his perspective it is right. From the perspective of those of us who do not follow commit messages it is wrong.

So Linus wants to not state security bugs to the development community because they are just another bug. That's fine, but what about the consumer community of Linux. There are more people in the world using Linux than just the developers. And while the kernel proper is not a commercial product, it is used in many commercial products. I'm amazed that people, especially those who are responsible for the commercialization of the kernel, are not publicly slamming Linus for this. If my company was at legal risk because Linus didn't feel like marking a bug as a security one I'd be pissed. My company must now spend more resources reviewing every change, rather than being able to get a basic triage service done by the Linux kernel developers themselves. Doing this basic triage service may increase the workload of the kernel developers but it does make the lives of the consumers easier, which is a good thing if you want people to consume your code.

By publicizing security bugs after they have been fixed you make the lives of your consumers much easier. A lot of the article focus on Linus' stance on disclosure. I've got my own thoughts on the matter and further thoughts on Linus that I may find time to put down in writing soon.

posted at: 20:30 | tags: | path: /entries/security | permanent link to this entry

Thu, 07 Aug 2008

Default OpenSolaris LiveCD Login

This came across my screen earlier this week. I happened to have an ISO laying around so I tried it out in a VM and it works. Why in the world does OpenSolaris ship like this? Seriously, this is just asking to be turned into a script that looks for the live CD being run and does bad things to it. Maybe it's already fixed but I have no idea since I don't really follow Solaris development.

posted at: 20:43 | tags: | path: /entries/security | permanent link to this entry

Thu, 10 Jul 2008

On DNS, FreeBSD and Security...

So this whole DNS issue that Dan Kaminsky is heading up is interesting. Not from the "is it real or is it a stunt/WTF is going on?" perspective, but from a totally different one.

I'm speaking strictly as myself here, as I'm not a member of the FreeBSD Security team. My interests lie in security and FreeBSD and I've been privileged enough to work with companies, or know people who work for those companies, that use FreeBSD in their products. As someone who wants to see FreeBSD succeed, more corporate use of FreeBSD is one of the ways that can happen.

The FreeBSD community (not just the developers) does a pretty good job of documenting things outside of the base (ie: things that are not in src) with VuXML, which has supporting things like portaudit. The FreeBSD Security Team handles things in src very well. I have never had a reason to think otherwise, and certainly hope that this is not taken as an attack on their work. My goal is strictly to increase the visibility into their work without harming the process at all.

One obvious benefit of the time-based release schedule used by FreeBSD (and by Linux) is that consumers (corporations, other projects, etc) are able to plan their work better. Releasing a new version when it's feature-ready forces these consumers into a corner, which may result in them finding other suitable codebases to use instead. With that in mind the question in my mind was: is it possible to maintain a list of issues under investigation by the security team? The obvious benefit to this is that consumers are better educated about upcoming issues when planning in the short term.

What would this mythical list contain? I initially envisioned it containing three things: a generic name for the problem, a date arrived, and an expected completion date. Given that FreeBSD is a volunteer project there is nobody that I'm aware of that is paid to work on the security team. This means that even giving an estimation on a completion date is not going to happen. The people doing the work have jobs, lives, families, children, and other important things. I would be the last person to advocate committing their volunteer time to a deadline. The arrival date is something which would be merely for people to know how long something has been under investigation - I see no harm in that.

So what about a generic description? In the security world there is a balance which must be maintained between informing consumers of the risk and protecting the details from the adversaries as to make it difficult for them to write exploits. This is why I thought a generic description would be best. Rather than saying "remote exploit in foo" just say "foo" and leave it at that. Now the consumers of FreeBSD that are using foo are now aware that an issue is under investigation and can plan accordingly. This doesn't give away specific information but it at least narrows down the search for an exploit a bit. Is that an acceptable trade off? I'm not sure.

The downside to this list (besides giving away a small bit of information) is that consumers are now privy to that information and will - and you can bet they will - poke the security team for updates or information. This reduces the time the security team has to work on things and strains the relationship between the two. Is this an acceptable thing to ask of the security team? I'm not sure.

There is one thing I am overlooking here. Some vulnerabilities are disclosed to FreeBSD (and other vendors/projects) under NDA - formal or otherwise. Obviously if someone reports a vulnerability and would like it kept secret it shouldn't go on that list. Doing so would violate their trust in the project and harm the project in the long run.

I poked around some of my friends who work in the security industry or for other OS vendors/projects or are a consumer of FreeBSD. They all agreed that increasing the transparency is a good idea but that it does come with risks. I'm in agreement with them and I am unsure how to address those risks. So for now I'll simply chalk this whole thing up to a failed thought experiment gone public. However, I still feel that making the lives of FreeBSD consumers easier is a good thing for the project and is something I will continue to work towards.

Oh, and for the record: I don't know any of the details but like Dan has said, if the only thing this does is bring about source port randomization then I'm all for it. A more secure (notice I didn't say 'secure' but 'more secure' because seriously, how can you expect to secure a protocol where the only means of an identifier is 16 bits?) DNS system is something we all need. There are plenty of theories floating around about what Dan found, but in the end the more important piece is that the system as a whole is better. The details of what he found are important only to people doing the research (maybe it's something they can adapt to something else) or to people doing the exploiting. If staying hush about it means keeping it out of the hands of the bad guys at the expense of the researchers, then such is the cost of doing business on such a high impact target as DNS. At least he is going to give full details in a month. In the end two well respected researchers have been told the details by Dan (obviously sworn to secrecy) and they claim it's a legitimate and serious attack. Either way, more secure DNS transactions are good regardless of your thoughts on how the disclosure is being handled.

posted at: 18:47 | tags: , | path: /entries/security | permanent link to this entry

Wed, 18 Jun 2008

Why You Don't Trust People

I just received a link to a python script which I was told was supposed to be a POC (or a checker) for a 0day GPG bug. I took a look at the script and it's not obfuscated at all. It simply tries to encrypt everything in your home directory, and delete the cleartext as it goes.

When I was given the link to the script it was explicitly stated that it claims to be a checker for a 0day GPG bug, and that I should run it at my own risk. The extra "run at your own risk" part came from my source, who is luckily well versed in the ways of information security.

But this does illustrate a character trait that non-security folks often lack. Just because someone gives you a piece of code and tells you it does foo does not mean it does only foo, or that it does foo at all. Security conscious folks are always skeptical, always questioning everything. It's in our very nature to do so. If we want to test out a piece of code we find a test bed which is isolated from things we care about.

These types of things are very old (and have probably existed since the dawn of computers). What's interesting is that they are still viable means of attack. Really this is just a form of social engineering, nothing special about it. What's interesting to me is that as the information security world grows it consumes people who are not really security conscious, thus giving rise to these kinds of attacks over and over again.

Moral of the story is that it pays to be skeptical of everything in life. Oh, and that there is no patch for human stupidity. ;)

posted at: 11:49 | tags: | path: /entries/security | permanent link to this entry

Tue, 10 Jun 2008

I Call Bullshit on nCircle.

So, nCircle put up a post entitled iPhone 2.0 is Less Secure and I'm neither shocked nor appalled that they did. Lots of companies have resorted to making shocking and outrageous claims before - and really, can you blame them given the state of media in our world? However, I have to call bullshit where I see it. And today, I'm calling it on nCircle. 

4. The Price

How could the price make the product less secure? Very simply, the more
ubiquitous a platform, the more attractive a target it is. By lowering the
price in order to increase market-share, Apple is creating a more attractive
base of targets.

Since when does price equate with security of a product? By that logic FreeBSD is less secure than Windows. It's true that the more wide-spread a product is the more likely it is to be a target, but that's to be expected given the commercially driven world of exploits that exist today. A lot of people who are looking at the iPhone as a target are doing so because they want to find a way to make money off of it's potential insecurities. It's important to make the distinction between value and security here. 

3. The SDK

Complexity breeds insecurity. The addition of third party code creates an
avenue for exploit. Apple can work to minimize that, but there's a choice of
functionality over security here. After all, not shipping the product at all
would be very secure.

Tell you what. I'm going to take one of my publicly accessible FreeBSD machines and do 'nc -l -p 9999 -e /bin/sh' on it (of course, I would have to build netcat from ports using the GAPING_SECURITY_HOLE definition since the one in base doesn't support -e) and you try to make the argument that FreeBSD is insecure because they let me run third party applications. I _want_ you to make that argument so you can be laughed at. One can hardly blame Apple for allowing third party applications to be run on their device. Of course, it would be nice if the code had to be signed and verified by Apple (that may be the case, I have not looked into it), but one can not fault a vendor for code they did not write. 

2. MS Office Compatibility

Do you remember MS08-026? How about MS07-044? Well, welcome to the world of
remote code execution via MS Office Documents, little iPhone.

So vulnerabilities in MS products instantly means that any vendor who parses those files is vulnerable? I could write a parser for those formats and DEPENDING UPON MY IMPLEMENTATION it could be vulnerable to the same problem, a completely different problem, or nothing at all. Don't equate vulnerabilities in one product with potential vulnerabilities with another. 

1. Enterprise-Ready

If the price of the iPhone increases its attractiveness as a target due to
volume, then being enterprise-ready increases its attractiveness due to value.
All the things about other enterprise computing devices that attackers love
will now be present in the iPhone. Along with that comes a whole new world of
exciting hackability. Who wouldn't want to break into it and see what juicy
data the CEO is storing there?

This is kind of like the price argument (#4) but instead of price you're trying to tell me that because it's sexy CEOs or other important types will want it more so than the first generation iPhone. Sure, I'll give you that argument. What I disagree on is that it instantly becomes less secure because of that. It becomes a more valuable target, not less secure. Please don't confuse target value with security.

Arguments #1 and #4 only increase the value of any security vulnerabilities in the iPhone. These two arguments mean that iPhone 2.0 will continue to see increased scrutiny from the security community, and that any vulnerabilities could have a large impact across people and businesses.

Arguments #2 and #3 are - to put it bluntly - bullshit. How does an SDK decrease the security of the iPhone? Nobody said I had to run third-party applications. It probably makes post-exploitation a bit easier since there is more to work with on the system, but it doesn't magically open up a vulnerability on it's own. Regarding #3, do you really expect anyone with half a clue to equate bugs in MS applications to instant bugs in Apple applications? Don't get me wrong, I think the Office File Formats are atrocious (I should know, I've spent time looking at them), but that's one hell of a leap from "bug in code from vendor A" directly to "instant bug in vendor B." Yes, Apple needs to be careful of these things, but don't jump to conclusions. To be perfectly honest, this is the one area I suspect will give Apple the most headache. If I expect there to be any serious vulnerability with the iPhone I expect it to be in the area of MS Office Compatibility. What you won't see me doing is posting to this site about how MS Office Compatibility instantly makes you less secure.

Shame on you nCircle. A post like that looks like it's begging for attention.

posted at: 19:02 | tags: | path: /entries/security | permanent link to this entry