Throttling Computer Viruses

An anonymous reader writes "An article in the Economist that looks at a new way to thwart computer viral epidemics, by focusing on making computers more resilient rather than resistant. The idea is to slow the spread of viral epidemics allowing effective human intervention rather than attempting to make a computer completely resistant to attack."

Comments

I have a brilliantly original idea

[ekrout]

Start writing secure software!

I'm not joking. The #1 rule of computer science is that computer scientists are lazy.

We need to stop working just to accomplish the minimal functionality desired and start testing the hell out of our software to ensure that it's secure.

Re:I have a brilliantly original idea

[janolder]

Hate to rain on your parade, but there is ample evidence to suggest that quality has to be designed in rather than tested into the product later in the process. If your design is flawed, testing won't help a bit. If your implementation is riddled with bugs, testing will find 95% of them, but Murphy will ensure that you get bitten by the rest at the worst possible moment.

In this business, it's a tradeoff between quality and time to market. Up until recently, software purchasing decisions haven't been based on quality very much so the software producers have given the customer what he wants: Buggy product now.

Re:I have a brilliantly original idea

[cyborch]

There's always a hole that cannot be planned.

True, but why do people have to keep writing programs with static buffer sizes? I cannot think of one single acceptable excuse to write a piece of software where a buffer overflow can happen.

If user input is in any way involved - directly or indirectly - then you need to test it before you accept it! There is no exuse!

Buffer overflows is not the only security issue with software, but the principle behind preventing it applies to most of the security issues out there...

So, I have to agree with your parent poster: the people making the software are lazy!

Re:I have a brilliantly original idea

[rossjudson]

Here's a thought. Stop writing programs in languages that HAVE static buffers. Stop writing programs in languages that have memory buffers that the program is free to overwrite. The problem isn't the programmers. What you're saying is that every programmer in the world has to write perfect code every time, and that's never gonna happen. Programs need to run in safe environments. The sandbox concept for running applets has been with us for a while, and it's a good one. You have a single place where you can fix things. It's gotten pretty hard to write an applet that can screw up a machine.

I think that ALL programs should be running in the equivalent of a sandbox at all times. There should be sandboxes inside sandboxes. When you download something off the net, you can go ahead and run it in a relatively safe, walled-off environment. There should be NO need for the program to look outside of that. Later on you might decide to allow the program more access to your system, once you begin to trust it, or some else in your web of trust has trusted it.

The OS needs to be designed to do this from the beginning.

Re:I have a brilliantly original idea

[Tim C]

Don't assume that static buffers are ALWAYS wrong.

Indeed - generally, there's nothing wrong with static buffers. If you're going to use them, however, there is absolutely no excuse for not bounds checking access to that buffer. That is, if you know that the buffer can contain say 1000 characters, check anything you write to it to make sure it fits!

That's most of what's "wrong" with static buffers - that it's too easy to use them incorrectly. It's not entirely the fault of the buffer, though, that it's easily misused

Technique

[gurnb]

Antivirus software makers are recycling some old tricks to combat computer viruses proliferating over the Internet.
The technique, called "heuristics," checks for suspicious commands within software code to detect potential viruses.

Heuristic techniques can detect new viruses never seen before, so they can keep malicious code from spreading. An older method, called signature-scanning, uses specific pieces of code to identify viruses.

Both methods have down sides. Heuristic techniques can trigger false alarms that flag virus-free code as suspicious. Signature-scanning requires that a user be infected by a virus before an antivirus researcher can create a patch--and the virus can spread in the meantime. Most antivirus vendors use both techniques.

It's time for the industry as a whole to look at different approaches The time-honored method of signature scanning is a little worn and weary given new viruses coming out

Issue at Hand

[seangw]

I think the issue at hand is a more global issue faced when writing applications.

Software is expected to behave 100%. How many of the developers here have had some strange bug, that may only appear in 1 out of every million users (not instances, otherwise it would happen in less than a second in most all modern processors). Then we are asked to fix it.

This solution is great, throttle the computer, lose that 2% of all connections being instantaneous, but then it won't be perfect.

I think we have to more realistically analyze the needs of modern software, and accept that it can "fail" to an acceptable degree if we want some superior functionality.

The human brain is great, but it fails (quite too much for myself). IBM is annoucing building a computer that could simulate the human brain, but it won't reap the rewards of our brains, until it's willing to give in to the issues that we face, uncertain failure.

With our "uncertain failure", look how great we are at calculating PI to the 100th digit (well, normal individuals anyway). Our brains certainly couldn't calculate nuclear simulations with the "uncertain failure"

We will probably have to split "computer science" into the "uncertain failure, superb flexibility" and the "perfect, 99.999% of the time" categories.

This sounds great for the "uncertain failure" group.

Umm, I don't buy it.

[Toodles]

In short, this guy's idea for curbing infection rates of &pluralize("virus"); is to restrict systems network access to one new host per second. Exceptions would be made for high demand, known servers, such as mail server and (I presume, even though it wasn't in the article) HTTP or SOCKS proxies. Interesting idea, and it would help in slowing down the infection of, say, Nimba or Code Red.

I can't help but think that his logic is flawed however. For example, most corporate headaches come from email based virii. If the only connections needed for the virus to spread is the email server it already has access to, there is no delay for the emails to be sent out to the mail server. No one could request for the email server to be throttled and keep their job, so the infected emails would be sent out, with no perceptable delay caused by the throttling.

The only thing this might help with is worms only, no virii in the more common sense such as email based LookOut virii, .exe/.com infectors, or boot sector infectors. The article fails to mention the Hows of this throttling; is it based on the routers (in which case quick infection of the local subnet would take place) or on the switches (which could break most broadcast applications, not to mention mean all systems outside the subnet look the same) or in the OS (in which case the virus could put its own TCP/IP stack in to replace the throttled one, and end up with no throttling affects whatsoever).

How about, instead of throttling network access, we move to more reliable code, better access controls at the kernel level, and a hardware platform that makes buffer overruns and stack smashing a thing of the past. While I am anti-MS, Palladium does actually have some good ideas on the hardware level. Is the DRM level that stinks to high heaven.