Is the lack of computer security due to programmer laziness and/or incompetence? | Hacker News Reader

Is the lack of computer security due to programmer laziness and/or incompetence?

2 pointssendos8 comments

The exploits of lulzsec in the past several weeks, and the relative ease with which they infiltrated so many websites reminded me of a question I have had for a while.

Basically, is the current state of affairs, where so many websites are vulnerable, where your computer can get a virus just by reading a PDF or playing an MP3, etc, due to programmers' laziness and/or incompetence, or is this a fundamental problem than can never be solved no matter what languages are used and no matter what computing paradigm is implemented?

Things like SQL injections and buffer overflow attacks seem eminently solvable. For example, to address buffer overflow attacks, simply do a bounds check before writing to any array.

I'm not a CS major or security expert, so I may be mistaken here, but in theory at least, it seems reasonable to have an OS where you can say something like "this action is a read-only action, and therefore no part of the hard disk of the computer will be modified upon executing this read-only action"

For example, playing an mp3 song, or viewing a jpg or pdf file, are all read-only actions, and so any program which attempts to change anything on the computer while performing any of these read-only actions will be intercepted by the OS and stopped. To me, it has always seemed ridiculous that the way computers and languages are designed today allow a computer to be infected by simply listening to a song or viewing an image.

Is the above feasible in theory, if not with current OS's and programming languages?

If it is not feasible, can you explain why not? If it is feasible, can you explain why there are so many compromised websites and computers that have been taken over by hackers?

The short answer: Security is HARD.

The long answer:

When even OpenSSH, a product dedicated to security, with highly trained, security focused minds, has new vulnerabilities coming to light on a regular basis, chances are this isn't an easily solved problem.

There can be any number of reasons why a security hole exists, covering laziness, incompetence, ignorance, or simple mistakes. Unless you can mathematically prove the correct functioning of your program (no small feat), there are bugs in it, and chances are some of those bugs are security vulnerabilities.

There have been numerous attempts at protecting so-called "data-only" memory, but thus far they have not stopped buffer overrun exploits completely.

The only way to be more sure that your program is not vulnerable to memory pointer exploits is to use a language that doesn't expose pointers to the programmer. But then you sacrifice speed and executable code size. And even then you can't be 100% sure because the compiler and runtime have bugs in them.

The more safety you bake into a language, the slower programs written in it will run. And even then, you're only safe until the next generation of exploits come out that take advantage of something nobody thought would be a security hole. And round and round we go.

Ok, boss, we've got the prototype going, it should only take about two more weeks to test it and get it secure enough to... What, now? Seriously? It's not... Ok, you're the boss.

Can there be an OS and/or language where, making something secure comes by default when you write anything, thereby rendering obsolete the need to make something secure after you make a prototype?

e.g. a language that automatically does array bounds checks, whether the programmer asks for them or not.

Such a system would protect against managers and bosses' demands as well as against lazy and security-incompetent programmers.

The problem is that "secure" isn't a well-founded concept. For instance, Java does the array bounds checks you're talking about (and throws an ArrayIndexOutOfBoundsException if they fail). It checks memory accesses and won't let you access memory that's been freed or is otherwise invalid. It does

However, I don't think anybody could seriously say that Java is totally "secure." There are plenty of security-related things that could go wrong (e.g. a man-in-the-middle attack) that Java can't handle unless the developer takes steps to prevent them. By definition, that isn't "by default."

If you want to prevent security problems "by default", you're going to need to specify each problem you want handled, and you're going to need to recognize that there are a lot of security problems that a language or OS simply can't stop by themselves.

That technology exists, but it would cost $100B to adopt it because it's not backwards compatible.

Getting companies to develop software for your OS would be very hard. Your OS would have to have hooks into the outside software to know what the program wanted to do with a file handle. Create a new mp3? Change the info of the mp3? Add album art? Play the Mp3? Delete it? What about future features that haven't been thought of yet?

The outside company just wants the ability to access a file. What it does with it is not up to the OS.

Implementing security measures usually provides little short-term return on time invested. Feasibility is not the issue.

Managers.

Reply on news.ycombinator.com