Slashdot Mirror
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?"
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.
Servers, P2P programs, messaging programs, ... email (Outlook?), web browser (IE? Even Firefox had one not too long ago, didn't it?), or pretty much any software that reads data from an untrusted source.
By the way - that includes things like word processors. A malicious attacker overflowing the buffer of Word via some viral Word doc spread via email - NX bit can help here, too. By "untrusted source" - that means pretty much any program.
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.
Almost all CPU advertising is misleading, first of all because it has to paint with such a broad brush. The NX bit plays only a tiny role in virus prevention. The much-hyped Hyperthreading was only of questionable benefit and certainly not worth paying extra license costs for most people. Dual cores may be a mixed bag if I read my cards correctly. I can think of lots of examples... But, misleading advertising is allowed anyway.
Well, I guess this time someone got caught. I hope this trend continues. If I have to be subject to censorship rules, why shouldn't the marketing people at AMD?
The people behind X-bit Labs are Russian and Estonian, but don't let that stop you from taking a shot at Americans.
For those of you who don't remember the evil bit, it's RFC 3514.
Noord-Holland, Zuid-Holland, Zeeland, ... To be exact.
Friesland, Groningen, Brabant, Limburg,
Drente, Overijssel, Gelderland, Utrecht
and Flevoland.
I will work to elevate you, just enough to bring you down
That is hilarious. An RFC telling crackers to make sure to set the "evil" bit when they are attacking so that secure systems can protect themselves from it. That's a great april fools joke.
Don't count your messages before they ACK.
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.
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?"
I can understand the stance that the Dutch took in regards to the NX issue. Ultimately, these commissions need to ensure that the information given out by companies such as AMD are as clear and accurate as possible, and I'm sorry, when they say, "advanced virus protection", after putting my end-user hat on for two minutes, what the advertisement is basically saying is this; "throw out all your anti-virus software, this new CPU can not only protect you like a normal virus protector, but does it even better!"
With that being said, however, the other flip side is how thinly do they want to slice the information; many things in IT can't be simplistically put down to a few catch words; the people to blame for this over simplification aren't the engineers, most engineers would love to give the information straight to the customer and say "here is the information, make you decision based on that", on the other side, the people who sell these products tend to have limited information technology knowledge, and not only misunderstand technology but try to break down things into simplistic language in when reality, they're complex matters now matter how much they're rephrased.
So, I guess it is more of an issue of trying to weigh up on one hand, informing customers of a product feature whilst at the same time realising that some aspects of technology are just plain well complex.
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).
ok, here goes. The Netherlands and Holland are one and the same, so they are different names for 1 country. Holland is an old name, you see, 'Hol' is an old word for wood in dutch (= the language of the netherlands), back in the day the whole country was full of trees so they basically called it 'Land of wood'.
...
The Netherlands means what it says; compared to sea level countries like belgium, holland and luxemburg lie very low (not sure if 'lie very low' is the correct way to say it but you catch what I mean.), about 16 meters or so below sea level. Since a few centuries ago the Netherlands consisted of belgium, holland an luxemburg, those countries were called 'the netherlands'. As in, 'the lands which lie nether'
Added confusion: Holland consists of 12 'provinces', not unlike a 'county' in the US. two of these counties are called 'North-Holland' and 'South-Holland'. Those are just names, and are only a small part of the country.
Quite a few virusses and hacks rely on buffer overflow errors. So eliminating that goes a long way.
In fact I think Dutch courts took it to far, or at least farther than they would have for other pruduct that mislead the public through advertising.
Don't get me wrong, I'm all for truth in advertising, but this is selective justice.
I have yet to see one laundry detergent that fail to get your cum stains out of your mothers favorite sweater to actually get banned for false advertising.
Noord Holland, Zuid Holland, Utrecht, Gelderland, Overijsel, Drente, Friesland, Groningen, Noord Brabant, Zeeland, Limburg and Flevoland together make up the kingdom of the Netherlands.
There are 12 provinces. Holland as such simply does not exist.
And to you moderators who think this is redundant, maybe it would be if for once the editors would get it right. So far they never do, so the information is not redundant.
I beg to differ. That address will differ from system to system, but it will NOT differ on the same system or from program run to program run. Sorry bub, libc gets loaded by ld.so at exactly the same place.
/home/andyw/nasm-0.98.38/nasm
/home/andyw/a
--------->
(gdb) break main
Breakpoint 1 at 0x8048d77: file nasm.c, line 150.
(gdb) run
Starting program:
Breakpoint 1, main (argc=1, argv=0xbffffa04) at nasm.c:150
150 pass0 = 1;
(gdb) print system
$1 = {<text variable, no debug info>} 0x410598a0 <system>
(gdb)
------------>
(gdb) break main
Breakpoint 1 at 0x804838a
(gdb) run
Starting program:
Breakpoint 1, 0x0804838a in main ()
(gdb) print system
$1 = {<text variable, no debug info>} 0x410598a0 <system>
------------>
Thus if I have local access, return-to-libc exploits are easy-peasy. If I'm striving for a remote exploit... then I'll want to exactly match the OS/Distro/program-in-question on my "development" machine.