The End to Computer Viruses and Spyware

When I heard about the new NX (No-Execute) feature that AMD introduced over a year ago, I started to get excited. Wow, we can finally eliminate so many of these overflow exploits. It got me thinking about the whole virus,worm,spyware problem. I think there is a viable and practical solution to all of these problems. So about 6 months ago I said to some co-workers, “I’m going to write a paper about this”. After much procrastination, I finished it.

Here is the link to the article: http://www.bigunix.com/, it’s called “The End of Computer Viruses is Near”

If you like it or think I’m right or wrong, please link to this blog or article. The more this gets blogged about, the more people will start thinking about the problem. I really want to get the conversation started out on the internet. I don’t think 90% of the people out there know that this problem is solvable.

“Why did I put it on a separate site?” Well, way back, I wanted the article to be a sort of site for ideas like this. So I made a system that would publish the article as a series of static pages so the slashdot effect wouldn’t crush my system. I’ve had a few of my posts slashdotted before, so I wanted to be ready.

“Why did I focus on windows?” Well, the answer is simple. What is 90% of the world running? What are 90% of the virus/spyware/worm targets? They are one and the same. If we are going to deal with this issue, we need to deal with the biggest platform for this issue.

Anyways, my writing skills aren’t the greatest, and there aren’t any pretty pictures, but I hope that you give the article a read. I strongly believe that we must solve this issue and end these threats to our systems. Technology can solve this problem!

This entry was posted in General. Bookmark the permalink.

7 Responses to The End to Computer Viruses and Spyware

  1. Hey Dru, How do software cert authorities know which code is safe to certify?

  2. Dru says:

    They could just use the same techniques that the Cert authorities use to authenticate SSL certs for web sites. There just has to be a barrier. Some may slip through, but that will be manageable and a world changing difference.

  3. The last time I looked into getting an SSL cert, it was just a matter of paying an expensive fee. I’m not sure how this ensures that software is virus free. If it’s just attaching a bank ID (and presuming the bank can locate the individual) then it may be useful in finding and prosecuting virus writers assuming 1. they are in a country with anti-virus laws 2. they’re software was not infected by someone else’s virus. Also, if certs are expensive, how do we prevent certs from effectively eliminating small shareware and freeware apps whose authors can’t afford such fees?

    BTW, I like your article and think this is interesting stuff.

  4. A couple of points: 1) Your contact page on bigunix is a 404 2) Why is the No-Execute the most interesting enhancement? 3) Why assume that you need hardware to create security architecture? The same way that you can build reliable systems on top of unreliable ones, you can have a new architecture built on top of the old one, although that needs to be carefully done. For example, C# and E are written using less secure languages. 4) Assuming a code signature scheme, who is allowed to sign executables? Do you sign scripts and macros? What if data can exploit a bug, does data need to be signed too? ActiveX are already signed but people already install some that they shouldn’t. 5) In the winners/losers list, you forgot to mention “Open Source” in the losers. Who’s paying to get the nightly builds signed?

    I’d recommend watching Marc Stiegler’s SkyNet virus talk. You mentioned Hydra, a capability-based secure system, in my opionion capability-based programming languages and platforms have the most potential to fight this flood of malware that we’re seeing.

    Cheers, Julien

  5. Dru says:

    Hi Julian, let me address your points.

    1. Sorry about the 404.
    2. It is a sign that the ‘architects’ out there are finally getting it with security. You need hardware to enforce proper execution. For example, where would we be without hardware memory management? We would have much more fragile systems without MMU’s.
    3. See above. Even with Type safe languages, they can be exploited. Also, if something can be done in hardware, then why not? It will 9 times out of 10 be faster than not.
    4. Anybody is allowed to sign an executable, script, or macro if they have a trusted cert.

    Data doesn’t need to be signed since the hardware protection will stop that.

    If the authorities actually respond to complaints then you will find that those certs will be revoked. Just like for SSL.

    1. Sourceforge can sign your build for free.

    On hydra, skynet, malware… I disagree. You will need to have trust systems to implement security. You trust Intel, so you run their processor don’t you?

  6. I have to disagree on a number of the points in your reply. I agree that NX is a good thing, and so was memory managment. But I disagree that it is required to build a secure system. You can have memory-safe systems without MMU (see http://www.cs.utah.edu/plt/publications/ismm04-wf.pdf ) and you can have safe executables without NX (see C#, E). In my opinion, the biggest problem with cert is that it is too much of an all or nothing, compared to capability-based security (like E, EROS,…). Because I trust Microsoft to write Notepad and Notepad is signed doesn’t mean that Notepad should have access to all my data, the network and my devices. That’s just because even though I trust Microsoft, Notepad may have a bug that makes it exploitable to do bad things. NX and MMU are good because they partition capabilities: a program can only access it’s own memory space, a program can only execute instructions in memory that is not flagged with NX… What we need is to introduce this partitionning at the software level. And just because it’s software doesn’t mean it won’t be secure enough, the same way the JVM and the .Net runtime can manage their own memory without needing help from a new memory handling chip. Why wait for hardware solutions to come tomorrow, when we should be investigating software solutions today?

    Cheers,

  7. Dru says:

    I agree with what you say, but you don’t really give a great argument on the practicality front. I could emulate a 32 bit processor with an 8 bit, but why would I want to do that?

    The same arguments can be made for avoiding MMU’s and Security in hardware. If you think that everyone is going to just buy into a particular VM and expect that to work flawlessly, then your views of practicality are far from reality. The reality is that people can make that choice and they prefer the OS for enforcement than a language specific system.

    On the capbability based system argument, I agree. Those systems are inherently more secure. I’ve studied those about 10 years ago. Unfortunately, they are also very inpractical. The key goal of my proposal was to introduce a practical system that can be deployed ‘yesterday’. To this day, nobody has produced a shipping capability based OS that is ready for real use (even Eros)

    In short, your systems would work, but they would require a massive reengineering effort to pull off. That will not happen in the next 5-10 years.

Comments are closed.