Musings on Computer Security

This is another from my LiveJournal, written October 14th, 2006:

---

While reading my new "Netscreen Firewalls" book for work, I chanced upon the following sentence (paraphrased):

"ScreenOS is more secure than open source operating systems, because it's source is unable to be searched for vulnerabilities"

Normally I would ignore such tripe as the rantings of demented mind, but tonight I reflected on it, and on the general outlook of the security through obscurity camp.

As some of you may know, and others may not care, there are (surprise!) differing opinions among computer security professionals.

One camp, the one which I most strongly adhere to, state that open source code, that is, code which can be read by everyone, is more secure due to the many eyes reading the code, searching the code for weaknesses. Eventually the bugs work themselves out, and the code becomes more secure.

The other camp argues that closed source code is more secure, because Evil Hackers(tm) can't go through the code looking for vulnerabilities to exploit (which they, presumably, wouldn't tell the authors about). This is generally known as security through obscurity.

The perpetual fighting between the two camps has shown no signs of slaking off, and I doubt that it ever will. I suspect that the vastly different idealogies between the "share everything" and the "hide everything" individuals will prevent that from occuring.

Here's what I'll tell you though. There are a couple of things that you won't often hear the open source professionals say...such as that security through obscurity does have it's uses, and sometimes it can be handy. Most won't tell you this because they will argue that Evil Hackers(tm) will eventually beat down your security, reverse engineer it, take it apart, and write exploits for it, without your ever knowing it's taking place, and Good Lord when that happens you'll be screwed because you can't even modify the source to the program and fix the hole and you'll probably get fired and have to move to DesMoines and work IT for a pig slaughtering factory to pay for your sins.

Here's the deal. That may, or may not happen. Here's another thing that security professionals won't always admit. Securing a computer system is a gamble. It is gambling in exactly the same manner as insurance is a gamble. Sure, any time you take a measured risk, you must analyze the situation, hedge your bets, and diversify, but in security, how does that apply? It's time to be frank with ourselves here.

A secure government installation will probably have multi-fold security systems. Historically all good security systems involved something you have (such as an ID card, typically) and something you know (such as a passcode). Technology is at the point where we can include "something you are", such as an retinal scan, fingerprint scan, or maybe in a couple of decades, a DNA scan. Someone trying to compromise your account would need to steal your card, find out your pin number, and maybe scoop out an eyeball to get into your system. It's possible, if implausible (and a bit messy), but I'm sure some foreign agents wouldn't hesitate a moment for the right information, and it's that last sentence that seals the deal.

Government secrets are fine, but your shopping list probably doesn't warrant a retinal scanner. My bike used to have a little chain and a masterlock on it. My bank's vault has a door a foot thick. What I'm getting at is you secure something relative to the severity of it's being compromised. A vulnerability in a recipe database might mean a loss of your data, but the exposure of a security issue in my firewall's ScreenOS could mean dire consequences for all of the people who run that particular hardware.

A friend of mine had this as his signature for a while:

"Half of learning any secret is knowing that there is a secret"

Security through obscurity. If we fly under the radar, then the Evil Hackers(tm) won't beat down our door, reverse engineer our software, and write exploits. Probably because they don't really care about our recipes.

Obscurity is a great hiding place for things that people don't care much about finding. Our recipe database, for one. Unless a really bored hacker chances upon it, gets interested, and spends the massive time it would take to reverse engineer it and exploit it, we're probably going to be safe. There would be no return on the time invested.

Obscurity is a really crappy way to hide something that many people are attempting to exploit. Yes, you make it more difficult for the Evil Hackers(tm) because they don't get the source code, but you lose the benefit of having Good Hackers(tm) look at the code too, and fixing it. You are left with your (probably understaffed and overworked) internal development team fixing the holes that they find. Sure, you can license your code out for review, but regardless of who you send it to to have it checked, chances are really good they're not going to be as creative as the community at large, nor as dedicated as a curious hacker bent on understanding your system.

What security through obscurity produces for the interesting target is a loosly tied together community of people cracking away at your security design, testing the perimeters like the raptors in Jurassic Park, and we all remember how that turned out. You might be secure for a while, because you designed your system well, but if there is a vulnerability, and trust me, there most likely is, then once it is found (and it will be), you will be at the mercy of the people who have uncovered the key.

In conclusion (and to review), security through obscurity is acceptible for targets which nearly noone has any interest in. It is not acceptable for interesting targets. If at all possible, you should secure your targets with community produced, time tested solutions, configured correctly and with the proper amount of paranoia, and if at all possible, heap some obscurity on top of that, and hope no one notices you.

How to ask questions on the internet

This was originally written on October 23rd, 2007 and post in my livejournal. It ends short, but the idea isn't too bad, and the content isn't yet out of date.

---

As the internet has become ubiquitous over the past decade, it has become our primary research tool. Seemingly endless in the knowledge it contains, we use an array of tools to mine for data, most of them from Google.

Sometimes, our search ends up short. The infinite monkeys on infinite typewriters have yet to produce the particular work we need, and it's up to us to prod them into movement. We must ask a question to the faceless, and hope someone succumbs to our petitioning.

I'm here to help you figure out how to do that.

You'd think it would be easy. You'd think you could just ask what you wanted to know. Folly.

At some point during your research, you must have come across two of the most common instances where someone asked a question and received absolutely no help at all. Allow me to illustrate:

Our goal: Why the foo widget doesn't appear to work when the bar widget is installed

Obvious (i.e. wrong) question:
I've got foo widget, but it doesn't work when bar widget is installed. Any idea why?

While to the non-reptilian brain, this might appear to be a perfectly valid question, if you submitted this to a forum, you would most likely be greeted with derision and mocking. Why? You didn't give enough information.

Suppose you asked the question and received several such replies. You might be tempted to say "screw you guys", find another forum, and ask the same question with more detail. Not a bad idea, but you definitely need to be careful. Here's why:

More detailed (i.e. wrong) question:
All: I've got foo widget version x.y.z running on my slackbuntuhat 7 machine. When I install bar widget 37.9 I am getting the following errors occuring in syslog.
- cut 30 lines of text -
I've read through the sourcecode and at the point it generates this error, the $arrBaz looks like it might be overflowing, but I can't tell if it's a bug or a clever programmer. I modified the source, and fixed the original error, but now I am getting this output:
- cut 40 lines of text -
Anyone else had this problem?


The response:

*crickets chirping*


Alright, you have corrected the initial flaw, a dearth of information. In it's place, you have inserted more information than anyone other than the actual developers of the software are likely to know anything about. Unless you're on a listserve where the authors are frequent posters, you're out of luck.

The proper way is to tease support out of the other commenters. You must coax information out of them a bit at a time, just whetting their curiosity. Maybe start like this:

All, I'm having issues with foo widget x.y interacting with bar widget 37. foo works fine, but when I install bar, it goes belly up. Anyone seen this happen?

After that, you'll probably get a reply asking for what platform it's on, log output, etc etc. Include the information they request, and always end the post with a request for more help. That way, anyone casually browsing by who has the knowledge will see your post being the last, with no reply, and they might respond. If you overwhelm them with information in any one post, you'll get dropped like a hot potato.

Thanks for reading, and good luck.