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

[El Neepo]

Being lazy = good.

If you write the simplest code you can that meet the requirements then more than likely its secure. It has no fancy tricks, its easy to see what its doing, therefore has less holes that need to be found.

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

Re:I have a brilliantly original idea

[radish]

FUDDY FUDDY FUD FUD :)

Depends what you mean by "performance application". Java is just as fast as C++ for a long-lived server process, running on a decent OS with a new-ish (i.e. 1.3.0 or above) JVM. Hotspot (even more so the newer 1.4 versions) is a fantastically good optimising engine which tunes your compilation as it runs. That's something gcc can never do...I have seen the suggestion put forward by better scientists than myself that something using the same concepts as Hotspot should in most cases be able to beat a traditional compiler, for that reason.

For client side apps Java can "feel" a little slow, but that is often caused by the graphics libraries, Swing is a little sluggish. Look at the Ecplise IDE however if you want to see a client side graphical Java app running just as fast as C.

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

[Tenebrious1]

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

True, but most of the new viruses that come out are produced by script kiddies and their virus construction kits, and heuristics work well for detecting these.

Besides, AV software does not stand alone. AV security includes scanning, monitoring and blocking at the mail servers and firewalls, good communication between av software companies and IT AV staff, desktop security policies, and the most important, user training. Admittedly the last is the hardest, but well informed users are less likely to infect themselves and risk infecting everyone else.

NOW we're talking!

[Shoten]

This is an excellent idea. For a long time the fight against computer viruses (as well as many other aspects of computer security) has been focused on winning or losing, period. Try to stop the virus, and that's it. But what about what happens when a virus gets through? Like almost all things in computer security, there hasn't been enough attention given to what happens if security fails. Bruce Schneier has been yelling from the mountain that security is as much about what happens when safeguards don't work as it is about making sure they do. The notion of being able to keep a virus in check to a certain degree is a good example of security that can fail gracefully when a new virus comes around.

Not very sophisticated.

[onomatomania]

Article blurb:

The idea, then, is to limit the rate at which a computer can connect to new computers, where "new" means those that are not on a recent history list. Dr Williamson's "throttle" [...] restricts such connections to one a second.

Hrm... well, it might have some benefit for things like Nimda, but it won't do anything for nasties that spread via email. If this becomes a default in a future version of Windows, though, you can bet that any virus meant to propagate by opening outgoing connections will just self-throttle, or disable the feature first. Already there is precedent for this, such as Bugbear that disables software firewalls so it can get out and spread.

I would much rather see effort spent educating people to install security related patches regularly and turn off unused services, and push vendors towards "secure by default."

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.

Problems With Insecurity

[txtger]

A lot of the vulnerabilities of these systems are things that are just downright idiotic, in my opinion. We've made programs that don't really need to talk to the outside world able to do so (Word, Excel), and we've given programs that shouldn't be able to control the filesystem and other aspects of the system that privilege (Outlook, Internet Explorer). During the Summer I managed to have Internet Explorer install software for me (.NET Platform).

Why do we not look at applications and give them a domain before we just open the floodgates? Why not just say, "hey, email comes from the outside world, I don't trust the outside world, so I won't let my email client do anything it wants to". I know that this wouldn't stop all of these problems, but I think the general idea would circumvent many virii.

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.

False Positives

[Erasmus Darwin]

I can think of two false positives off the top of my head where legit traffic would get unfairly throttled:

Web-based message boards -- Several of the message boards that I'm on allow users to include inline images. However, the users are responsible for hosting the images on their own servers. So a given page full of messages could easily add an extra 10 hosts to the "fresh contact" list, causing a 10 second delay. Furthermore, at least one of the message boards has a large enough user population that the "recent contact" list wouldn't help out enough at reducing the delay.

Half-Life -- The first thing Half-Life does after acquiring a list of servers from the master server list is to check each one. For even a new mod (like Natural Selection), this can be hundreds of servers. For something popular (like Counter-Strike), it's thousands.