Free the Cell Phone! (Wired)

Posted Sep 28, 2005 21:11 UTC (Wed) by Ross (subscriber, #4065) [Link]

Posted Sep 29, 2005 7:09 UTC (Thu) by jonth (subscriber, #4008) [Link]

Smartphones generally have an apps processor and a signalling processor. The signalling processor is often some strange beast with lots of bespoke DSP accelerators for Viterbi/Turbo decoding etc. These run a closed source, heavily controlled embedded signalling stack quite often with an AT interface on top. All the authentication and billing lives here and/or in the SIM. The OS on this processor is usually an RTOS of some sort, like Nucleus.

The applications processor is usually an ARM, running something like Symbian or Linux (or, perish the thought, Pocket PC). This bit runs apps that are much more suitable for open-source development, and it's not too difficult to allow these to be open source/unregulated.

J

Posted Sep 29, 2005 16:35 UTC (Thu) by Ross (subscriber, #4065) [Link]

1) "Default Permit"

I won't defend this one, because it is something I'm always telling people not to do it. But here's a bit of what mjr says:

'A lot of organizations adopted "Default Permit" in the early 1990's and
convinced themselves it was OK because "hackers will never bother to come
after us." The 1990's, with the advent of worms, should have killed off
"Default Permit" forever but it didn't.'

The reason only a few ports were blocked in the early days of firewalls was not due to the lack of worms. In fact, a worm is one of the first incidents which got people looking into firewalls. People only blocked a limited number of ports because they perceived the risk to only be with those ports. This minimized the work in implementation. A good idea? No, but it happened for entirely different reasons than stated. Why did it change? Not because of worms. But because of the realization that just about any service is likely to have vulnerabilities. The discovery of the frequency that buffer overflows and other exploitable bugs occur was the trigger. Also, the realization that pushing security to each and every client and server on the network, involving individual departments, system owners, etc. was just not likely to work well in the long run.

I see the cell phone problem as a similar situation. You don't protect your network by trying to lock down every system (though that is a good idea anyway), not because it isn't good to secure systems but because there are so many of them. You keep your network infrastructure including core routers and firewalls well-maintained.

2) "Enumerating Badness"

Well, I would agree with this one, except he reaches some really silly conclusions. Here's the description:

'Back in the early days of computer security, there were only a relatively
small number of well-known security holes. That had a lot to do with the
widespread adoption of "Default Permit" because, when there were only 15
well-known ways to hack into a network, it was possible to individually
examine and think about those 15 attack vectors and block them.'

(First off, we see a second option for the reason "Default Permit" was popular. This one is closer to the truth than the reason given in the "Default Permit" section.)

The history is pretty good, but the implication is that today it is silly to do the same thing. That's like saying names are a good idea with a few people, but a bad idea when there are millions. In fact, giving unique identifiers to vulnerabilities and patches is one of the most important things which security organizations are doing today. The idea that you can just slap "all" patches onto a system and sit back in your chair without worry is just wrong. We all know that some vulnerabilities are not closed in a timely manner, that some patches which are thought to fix them do not in fact do so, and that when testing a patches system, when a vulnerability is found, it is nice to be able to give a link to an official explanation, with a publishing date.

But he seems to be talking more about viruses than vulnerabilities (despite the introduction):

'It's a dumb idea because sometime around 1992 the amount of Badness in
the Internet began to vastly outweigh the amount of Goodness. For every
harmless, legitimate, application, there are dozens or hundreds of pieces
of malware, worm tests, exploits, or viral code.'

I seriously doubt the accuracy of those statements. In terms of traffic flow (number of bytes) it is probably not the case, unless you count spam, and even then probably not. In terms of existing software, I have never even seen an attempt to enumerate it. Even lists of Free Software are enormous. The problem isn't the ration of valid/malicious but the sheer volume of both. But again, we like to "enumerate" things by giving them names. What's so bad about that? Does it interfere with security? Are virus definitions being held up while people debate the name? No. Instead you end up with different names from different vendors. Just realize they are different namespaces and there's no problem.

'Compare that to the legitimate 30 or so apps that I've installed on my
machine, and you can see it's rather dumb to try to track 75,000 pieces
of Badness when even a simpleton could track 30 pieces of Goodness.'

Again, the author seems to have shifted topics (back to the signed application support or whatever he was alluding to in the "Default Permit" section). But I just have to point out that comparing every piece of "Badness" that was ever named to the list of "applications" installed on his computer is comparing apples and oranges. A virus scanner should not be flagging _any_ valid application. If it did it wouldn't be a virus scanner.

Now having said that, I agree that virus scanners are stupid. They are implemented at the wrong level and it is a neverending "arms race" because the number of possible viruses, worms, and other malware are infinite. The problem isn't enumerating badness but trying to detect badness. It just can't be done. Instead you have to look at what the bad software is exploiting and fix that (even if it is the user) :)

3) "Penetrate and Patch"

'Unfortunately, when buggy software is fixed it is almost always fixed
through the addition of new code, rather than the removal of old bits of
sow's ear.'

Again, I doubt this is true. Usually security bugs are fixed by adding input sanity tests (very short code which should have been present to begin with), using safer functions, removing static limitations, or detecting an unhandled corner case. Yes, that often involves adding more code but saying that it is a bad idea is just ignorant. You can't usually fix something by deleting parts of it. At least if you could, it wouldn't likely have the same functionality as before. It is true some software is so crufty that it should be abandoned but calls for rewrites are usually too soon and too frequent. Why? The new "replacement" software is unlikely to be any less buggy, and also not likely to be smaller if it has the same feature set. In fact, old code tends to be significantly smaller than new code. Small is good, but it should not be the only consideration.

'Let me put it to you in different terms: if "Penetrate and Patch" was
effective, we would have run out of security bugs in Internet Explorer by
now. What has it been? 2 or 3 a month for 10 years?'

Oh where to start. The fact that bugs are infinite is one of the fundamentals of computer science. Saying that it can be avoided by doing everything correctly the first time is one of the dumbest ideas in software development. Bugs do exist. It's not satisfying to say it but in any sizeable piece of human-written software there will be many of them. Most bugs in software which handles untrusted input are security bugs. In other words "Penetrate and Patch" will always exist. The best you can do is to use good coding practices to reduce the bug density, pre-release testing to find some of them, compiler and OS technologies to shield the program from some untrusted inputs and to mitigate the consequences in case of an exploit, and finally, to respond quickly when a bug is found so that a working patch can be released. That _is_ as "secure by design" as you can get.

4) "Hacking is Cool"

I think this is more of a social problem than a computer security problem. Even if the media stopped doing this (and using the term "hacking") we'd still be stuck with it. You see what underlies this is a bad premise: if there were no script kiddies there would be no need to fix the bugs. It's true that the number of compromised system would be less, but the risk would still be present, and more importantly the vulnerabilites still would be present.

'If you're a security practitioner, teaching yourself how to hack is also
part of the "Hacking is Cool" dumb idea. Think about it for a couple of
minutes: teaching yourself a bunch of exploits and how to use them means
you're investing your time in learning a bunch of tools and techniques
that are going to go stale as soon as everyone has patched that
particular hole.'

I can't disagree more. Learning how "hacking" (cough) works is important to a security professional or even normal admins. For one thing it makes security more real: the realization that a tiny program is all that keeps someone from a root prompt on your system is likely to make you think about security. Using exploit tools is a great way to test for vulnerabilities and look for systems which need to be fixed. In fact many are useful tools for normal administration. (Microsoft keeps trying to prevent nmap from working on Windows. The problem is that there are more "good" users of nmap than "bad" so they are really doing everyone a disservice.) Learning about "hacking" is also important for the same reason law enforcement learns how criminals work. You can't really understand what the risks are until you understand the tools and people which are out there. Knowing the vulnerability side is one part, but knowing the exploit side is important too.

5) "Educating Users"

I'm not even going to quote portions and address them individually here.
This pretty much summarizes my opinion:

Yes, let's keep users in the dark because we can programmatically handle all situations in software. After all, it has worked so well so far :p

6) "Action is Better Than Inaction"

I mostly agree with this one. But I wonder why it is in a list of bad ideas in computer security? It's a general truism. What would have been better for this list is "Early Adopters are Early Victims". Also, I'd like to address the comment about stupid managers. Yes, there are many, and they are a problem. But they are also quoting "The Art of War" and I'm pretty sick of it. Please don't imitate them :p

(and the minor ones)

7) "We're Not a Target"

True this is a commonly-held belief, and it is wrong. But worms aren't the only things which don't care who you are. People will attack computers just to have systems to use as a jump-point for other attacks. They use long strings of them in an attempt to hide their identity. You don't want to the one in the string before "cia.gov." :) And others like spammers don't care who you are ... they just want to use your bandwidth and have your postmaster take the brunt of the compaints.

8) "Everyone would be secure if they all just ran <security-flavor-of-the-month>"

Very true, though it can be a good idea to switch if you will be able to manage the new system as effectively as the old. I'd like to point out that not only is "system administration is not a solved problem in computing" that it won't ever be. Like it or not bugs will continue to exist unless we find some infinite fast form of computation, or a way to write software without decision points. Not going to happen.

9) "We don't need a firewall, we have good host security"
10) "We don't need host security, we have a good firewall"

Those are good ones. The best approach is security in depth. Yes, have a firewall, and also patch your systems (and segment your network by group and function to the extent it is feasible).

11) "Let's go production with it now and we can secure it later"

Agreed, this is not ever advisable.

12) "We can't stop the occasional problem"

'Would you travel on commercial airliners if you thought that the
aviation industry took this approach with your life? I didn't think so.'

Apples and oranges again. The risk with an airplane is different with the risk of an unsecured system or network. However I agree that the idea that problems can be "cleaned up" after they happen is stupid. For one thing it assumes you would know that there was something to clean up, which is unlikely if you don't have any security.