

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

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.<p>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?<p>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.<p>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"<p>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.<p>Is the above feasible in theory, if not with current OS's and programming languages?<p>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?
======
kstenerud
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.

------
noonespecial
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.

~~~
sendos
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.

~~~
bartonfink
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.

------
bartmcpherson
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.

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

------
iamdave
Managers.

