Holland Bans AMD's 'Virus Protection' Campaign

Hack Jandy writes "For those of you who didn't see this coming, AMD's Advanced Virus Protection campaign has been banned in Holland since the technology does (almost) nothing to stop viruses! If you recall, AMD's NX bit attempts to stop the processor from executing pages on the stack that have been written to. Does NX even solve more problems than it causes?"

Comments

How do you explain it to Joe Sixpack?

[LostCluster]

What the "NX bit" actually does is a pretty nice thing for preventing buffer overflows... if a segment of memory is marked for data use and then the code execution point somehow arrives there, you get a crash-out instead of the execution of arbitrary code.

Of course, AMD's problem is finding a way to try to communicate that concept to the average user. Joe Sixpack doesn't even know what buffer overflow problem is, so they don't understand why they need a solution to that problem. AMD is trying to use the concept of "virus prevention" instead, but apparently they've gone too far in implying that the NX bit eliminates the need for conventional anti-virus methods, which it most certainly does not.

This is an extra set of suspenders, not a new belt.

Re:How do you explain it to Joe Sixpack?

[karniv0re]

This is akin to OpenBSD's W^X, which specifies that memory can be either Writable or eXecutable but never both. Wikipedia has a good stub on it, as well as a nice article on the NX bit.

Re:How do you explain it to Joe Sixpack?

[tepples]

Apparently, code loaders such as DLL loaders and JITs have to explicitly go through a syscall to copy from writable memory to executable memory.

Re:How do you explain it to Joe Sixpack?

[iamacat]

You can just map the same physical memory to two different addresses - one place for writting and another for executing. This way there is no overhead involved, although it weakens the protection to some degree.

Not just for servers

[gad_zuki!]

Windows XP uses NX now as of SP2. Its part of its Data Execution Protection scheme. DEP can run without an AMD too. Its on by default for windows system files.

Buffer overflow exploits arent just for servers either, the RPC/DCOM exploit was one. So was the previous big worm, err blaster? I don't quite remember.

This is tech for the desktop, really. Modern computers run a slew of services.

Re:Does it rely...

[CoolGopher]

For those of you who don't remember the evil bit, it's RFC 3514.

Re:Holland or the Netherlands?

[choas]

Noord-Holland, Zuid-Holland, Zeeland,
Friesland, Groningen, Brabant, Limburg,
Drente, Overijssel, Gelderland, Utrecht
and Flevoland. ... To be exact.

Re:Hum.

[Anonymous Coward]

As has been said over and over by people who understand NX, it is simply one more arrow in the quiver, not a panacea to stop all viruses.

A well crafted buffer-overflow attack that overwrites the return instruction pointer on the stack to point to existing code elsewhere will not be caught by NX. NX catches *execution* of code
from non-allowed pages as pre-determined by the OS; but it does not block data writes.

For now, it creates more problems than it solves.

[Anonymous Coward]

In a recent cluster installation, we noticed that any tool (IBM's RAID console and the PolyServe cluster files system managment console) involving Java aborted with SIGSEGV errors. This was a Redhat ES 3.0 u3 installation on IBM e336 (dual Xeon 3.06 GHz) systems. Run the tools, immediate BOOM!

Noting that the problem was the JRE blowing itself out of the water with SIGSEGV (and talking to friends that had installed the same OS and same software on different hardware) led me to do some more research. "strace" can indeed be your friend. It seems that AFAICT the NX feature was added to the Xeon processor versions (stepping) that were in our machines. There was no way to disable the feature in the BIOS. There is a little, er, confusion in the various documentation about the kernel's behavior, but "noexec=on" is the default as far as I can tell.

So, what (apparently) happened here?

[personal opinion] Intel, rushing to counter the AMD marketing blitz about the wonders of "no execute", put the feature into their newest Xeon CPUs, possibly before the BIOS functionality caught up. The Linux kernel's choice of defaulting the new feature to "on" (theoretically the best choice) unfortunately resulted in numerous "issues", particularly in applications (simulators, virtual machines, etc.) that commonly execute things within the stack segment. This is done all the time in this class of application. The software development community hadn't caught up to the new feature, either. It seems that there are linker attributes that can disable the behavior (still researching this). [/personal opinion]

If you Google for this issue you will find that virtually (pun intended) anyone that relies on a JRE on Linux (Oracle, IBM, etc.) was affected iff the hardware did the NX bit. Our solution was to download the latest JRE from a source on the Web (Sun in this case) and hope that we did not run into Java compatibility issues or that the JRE versions in the software packages were not bolted in.

We squeaked by with our solution, but it only cost about a whole day figuring it out. Time is cheap. Technical problems are fun, especially with a customer watching all of the game over your shoulder. "You have done this before, right?"

Re:Self-modifying code?

[VertigoAce]

This is the kind of thing that NX breaks. One notable situation is that Java, .NET, and anything else that dynamically generates code will break if not properly coded. My understanding is that you have to specifically request that a data page be executable. In an OS that uses the NX bit normal data pages will be marked as not executable. I recall seeing something from Microsoft telling developers how to fix their software so this wouldn't be an issue when they updated the OS to use the NX bit (XP SP2, I believe).