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

slow the spread of viral epidemics

[batemanm]

Okay everyone back to 2400bps modems :-)

Re:slow the spread of viral epidemics

[MImeKillEr]

2400 bps is too fast.

Everyone drop your baudrate to 110.

Just for laughs, we used to get stoned and call a multi-line chat board here in Austin, Tx (long live AfterHours, R.I.P. Tombob). We'd drop our baudrate to 300 or 110. and attempt to have coherent conversations while inebriated.

Yeah, pathetic but the internet wasn't available to the public yet and we were young and st00pid.

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

[vidnet]

Yeah ok......starting tomorrow.

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

[FortKnox]

True, but why do people have to keep writing programs with static buffer sizes?

I think it isn't that people WRITE programs with static buffers now-a-days as much as it is that people who maintain old software don't fix the static buffers.

Plus I could also argue what is more important to the program? Static gives me knowledge of the maximum size of memory used, if that knowledge is required. Searching is faster in arrays than linked lists (although replacing, on average, is slower). Don't assume that static buffers are ALWAYS wrong.

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

Re:Technique

[OeLeWaPpErKe]

heuristic scanning is very ineffective.

why ? new viruses are designed to subvert them. I've done it, installing 5 virusscanners to check if, and how they detect your virus. (btw my virus was a .com infector without a chdir instruction, not very dangerous, but it worked)

example :

wrong:
-> to_infect = "*.com"; // oops, heuristics detect this

right:
-> boem = "*.c";
-> othervariable = 5;
-> to_infect = strcat(boem,"om");

I have yet to see the first scanner that detects this one. The difference in codesize is about 3 extra bytes (assuming you were using strcat anyway) so in today's 500kb viruses it is negligeable.

Heuristics are nice, they do have some effect, but they are no solution.

Virusscanning is inherently responsive. The best they can hope to do is to repair the damage when it is done. They have no use whatsoever for online worms.

This will of course lead to a new class of virus..

[Unknown Bovine Group]

The "annoy the user to death" virus.

You have a possible virus(mickeymouse variant 1a). Transmit to everyone in your address book?

No.

You have a possible virus(mickeymouse variant 1b). Transmit to everyone in your address book?

No.

You have a possible virus(mickeymouse variant 1c). Transmit to everyone in your address book?

No.

You have a possible virus(mickeymouse variant 1d). Transmit to everyone in your address book?

No. ARGH!

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.

Microsoft already does this...

[krystal_blade]

Virii thought: Woohoo, I got in a machine!
Windows: "Are you a dll?"
Virii thought: "Umm... Yes. I like Outlook."
Windows: "Okay, hang on..."

Launches Outlook...
Virii thought: "Why is everything blue?"
Windows: .............
Virii thought: "Oh, if only I had hands!!!"

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.