Anti-virus industry: white knight or black hat?
This is an interesting piece about the ethics of AV marketing. Some time ago I turned down a (very lucrative) job developing antivirus software for handheld devices because I didn’t like the ethics of the industry, it is built on peoples fears, has no incentive to reduce those fears, indeed, much incentive to intensify them to the point where people feel unsafe running without protection.
Some technical questions are worth asking:
– Why do we need antivirus?
The usual answer given for this is that we live in a Microsoft monoculture where features are more important than security. Some of that is true, however, I would speculate that the real reason we need protection from malicious code is that it is possible to run malicious code. The normal starting point for an attack is a buffer overrun allowing the replacement of a stack pointer with a return address within the overrun buffer, thus you can get your code run when the current function completes. You have to be slightly careful when you do this, since you cannot rely (much) on the context you are in so you effectively have to bootstrap from there, but its all possible, almost trivial, if you’ve got an appropriate buffer giving you a way in.
– If I were a virus writer what would I do?
I’d start by trying to break a comms stack on a machine, to find a buffer to overflow. This is a simple exercise if I can write a device driver, something like, say, an ethernet passthrough driver…once I’d got a simple passthrough working I would then add some corruption to the data being passed through, in the expectation that something, somewhere, won’t be able to handle such corruption. Doing this I’d be looking for crashes when running invalid instructions, these indicate that something has overwritten the program stack. After I’d got a few I would investigate how to reproduce them and figure out the buffer sizes and whether they’d moved around between different versions of the OS – I could figure out a jump table that would make a series of different versions of similar code suffer the same infection.
Now, the interesting part. How about making a number of different operating systems vulnerable to the same virus? All I really need is the ability to write such a redirector device driver for all the OSes I am targetting – sure I might have to do some clever stuff if there is some overlap in the jump tables, but thats not difficult to do.
I can do better than that, though. What about taking the same virus across a series of different processors? This is only problematic if the jump tables would coincide, if that were the case there are valid operation sequences for each core that would allow a discriminator to branch to different payload areas.
Anyone got any ideas how resiliant any of the comms stacks out there are? I’m guessing the Win32 stack(s) is pretty easy to crack. What about the Linux stack – does that still have a BSD legacy? If so, its probably quite vulnerable. I take it it doesn’t run with kernel privilege?
– What could be done to prevent malicious code?
Most of the viruses currently circulating (well, the ones which are not triggered by stupid users, at least) would be prevented by a simple, one-bit change in most operating systems. The bit that needs changing is setting the execute permission in the MMU (surely everything worth exploiting these days has an MMU?), that should only be set for code loaded by the executable loader, while heap and stack allocation have the execute permission denied. Obviously it isn’t quite as easy as that, since that causes some problems with (validly) self modifying code, among other things, and would likely break a whole slew of programs out there with various copyprotection schemes. But, is there a real reason not to do this?
3 comments