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.
I don't understand really why AMD felt a need to make an ad campaign over the technology anyway. Most uses for this technology are buffer overflow preventions, which are almost exclusively server technology. Admittedly, it is possible for any program that makes a remote connection to accept data or idles waiting for data to possibly be vulnerable, but for a userland machine this would be mostly messaging programs and p2p programs.
I think it would have made sense to put it as a nice side feature so that geeks see the technology and how it prevents buffer overflows, but they probably already know about it.
Do not look into laser with remaining eye.
Does this NX thing rely on the evil bit? If so, no wonder it doesn't work! *duck*
picpix image polls. create - share - vote. fun!
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.
Given that, in common parlance, most people don't know the differences between the various exploits "virus" is as good a word as any.
And if the NX bit were used for more than the stack, then it could protect against a lot of (non-trojan) viral activity too.
Lets face it most viruses today aren't even viruses. They are trojans, worms, and human-engeneering exploits. How often do you see an actual virus? You know a program that writes its code into another program. It's actually getting kind of rare. Now days it is whole applications delivering themselves to your computer through email and exploiting the existing code of crap like IE and Outlook by just telling those programs to run the evil code. Most exploits today are applets and packages.
All But Gone are the days of rewritten exe headers wiht appended code fragments, and programs appending themselves to other programs in memory.
Quite frankly if all the non-code memory regions in my computer were non-execute down to the very last GDI region and printer buffer, the classic virus would be dead. The IE hacks and the trojans and the worms would still be here because certian stupid programs will do arbitrarily complex things at the behest of remote entities, but that isn't a virus. Thats bad design comming home to roost.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
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
...then I actually RTFA.So it appears that the complaint wasn't against the claim NX "protects against viruses", the complaint was that the advertisements did not make necessary disclaimers like "requires special operating system support". This seems definitely reasonable on the regulators' part.
This said, I have heard it claimed that NX technology is rediculously easy to circumvent. Specifically, I saw a long post by Linus Tourvalds somewhere in which he noted that NX provided protection against some classes of buffer overflow attacks, but not all, and then outlined various ways in which someone attempting a buffer overflow under Linux could potentially simply structure their buffer overflow so as to circumvent the protections NX offers. The post was very technical and I could not tell if the statements were general or just byproducts of the way Linux handles stack and such. Does WinXP suffer from these same problems with regard to the efficacy of an NX bit?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
There are ways around that. The true solution to the problem is to not overflow your buffers!
My other car is first.
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 was speaking to someone on a forum just recently, and they mentioned how their processor had "built in virus scanning." After a bit of an argument (he was quite convinced that it was truly virus scanning) I ended up correcting him, and simply explained that it could help stop a "bad program from tricking your computer into doing something it shouldn't."
... because it's definetly misleading to those who don't understand what it does and can easily become an issue of semantics for people who might confuse "virus protection" with "antivirus software." And in a world where the blue E on grandma's desktop = The Internet(TM) this may be happening more than it's apparent.
It's a shame that they couldn't come up with a better way to market this
Who doesn't like free music?
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).
On Windows systems, no, it's not buffer overflows that are the major problem and the CPU's capabilities with respect to flagging memory pages will do absolutely nothing. Humans install viruses on Windows systems. They fall for tricks, it's a social problem. Sure there are still some buffer overflow issues.
I can't say I think the NX bit is really that big a deal, it only makes things a little harder when you can't execute code on the stack since a stack overflow lets you return program execution to any address on the system you want. Often a cleverly designed system call or another non-stack user controlled data structure will still allow the attacker to gain control.
Still it really does provide some virus protection which is alot more than can be said about most commercials. I mean is the 'lemon strength cleanser' actually a better cleanser because of the lemon. Is 'oxygenation' or whatever really important for skin care.
Maybe they manage to stop all these types of advertising exageration over there, and if so my hat is off to them. At least if they can really manage to do it objectively. Often these sorts of rules aren't applied evenly, letting false but dear cultural assumptions slide by but blocking correct but disconerting claims. For instance I have no doubt that if we had these sort of tight 'truth in advertising' laws in the US we would find condom ads forced to produce 3 peer-reviewed studies for every claim they make while gun ads would be allow to imply or outright say that carrying a gun makes you safer. But maybe other countries can pull this off, after all I'm always amazed the U.K. can function so well without an explicit constitution so who knows. If they can do it objectively my hats off to them.
If you liked this thought maybe you would find my blog nice too:
No, the correct solution is not to allocate memory as both writable and executable; it's to initially allocate the memory as writable, dynamically recompile the code, then call mprotect(2) to change it from writable to executable.
Simply allocating it initially as both writable and executable needlessly opens your JIT to the possibility of exploits.
There is a much more effective technology around since about 1988. IBM's AS/400 (now called "iSeries 400" or "eServer i5") has a feature called "Pointer in memory protection".
Every time when the processor writes an address into memory (for example, return addresses stored in stack memory by subroutine calls) the memory location is marked as containing a valid address by using a "shadowed" flag, a 65th bit (one bit of ECC memory is used, so the machine does not need special memory modules, just standard ECC memory modules). If that memory location is overwritten with data, the CPU automatically clears the "shadowed" flag. If the CPU tries to use a pointer as a memory address, that was overwritten with data before, it automatically generates an interrupt.
This feature was originally not designed to be a buffer overflow protection, but it was neccessary, because the AS/400 uses a so-called "single level storage", where all applications use the same address space. Therefore, the machine needed some method to prevent applications from writing to arbitrary locations in memory, and that's why pointer-in-memory-protection was invented.
Actually, the memory is also segmented, one segment for every "object" created by a program. Most buffer overflows can not even overwrite an address, because a character array will have its own object boundary.
For example, the following code will typically not generate a buffer overflow on an AS/400:
int main(void)
{
char space_a[20];
char space_b[20];
int i;
for (i = 0; i < 100; i++)
{
space_a[i] = 'A';
}
for (i = 0; i < 100; i++)
{
space_b[i] = 'B';
}
}
Just try it out, it should not even crash.
I tried a lot of things like these on an AS/400 Mod. 170 running V5R2 using IBM ILE C compiler.
I think, pointer protection using shadow flags is the right way to prevent execution of code inserted by exploiting buffer overflows, because all other protection methods can't prevent return-into-libc exploits, but the pointer-in-memory-protection can, so IMHO it is the only *real* protection.
Further reading: "The inside story of the IBM iSeries" by Frank Soltis (a book about the architecture of the iSeries and the POWER processors)
Of course NX does not stop virusses and trojans. However, in itself it does only stop some memory corruption attacks, like simple stack overflows. But not many other types of memory corruption attacks.
NX is just one method to protect the integrity of the memory. What it basically does is that it allows an OS to implement separation between data and code in the memory of a running process. Many overflow and other attacks depend on writing data in the process memory and then executing it as if it was code. A virus or a trojan is usually a program. It depends on being run, not on memory corruption. Therefore protection against memory corruption brings you literally nothing.
NX in itself stops exploit writers for aproximately 15 minutes, which is the time it takes for them to adjust most of their overflows to make them work with NX. Only a hand full of attacks cannot be adjusted. So NX in itself doesn't bring you much, despite what the marketing departments of companies like AMD and Red Hat tell you.
The trick to provide good memory protection is not to only use NX, but to combine it with other protection methods. This is the approach taken by the PaX project http://pax.grsecurity.net/.
However, there are also some PaX imitations which, unfortunately, do not implement all of the PaX technology (even though some of them claim they do or claim to be even better). Examples are: MS-Windows SP2, Red-Hat's Exec-shield and OpenBSD's W^X.
Anyways, back from the technical intermezzo to AMD marketing. These guys have the same problem which people from the PaX project, exec-shield, OpenBSD and others who produce stuff like this have: Try to explain why this stuff is useful. If clever people like Linus don't get it, then how is one going to explain it to John Doe or the PHB's of this world? ``Memory corruption? Exploits? Buffer overflows?'' ``Woah! Brain overload!'' At least they have heard the word ``virus'' a few times and have learned that ``virus = bad''. So ``NX = good'', which cannot be explained to lusers, became ``NX = anti-virus = good''. Even if it is disabled by default, if you cannot motivate people to try to look for it, they never will.
Oh yes, these patches break things. Most programmers are spoiled. They think it is normal to mess around with memory in any way they like. Few of them understand that what is convenient for them, is also convenient for exploit writers. It's like MS-DOS programmers complaining about the file permissions on UNIX.
I hope AMD takes the challenge to produce better marketing, so more people start using this technology. Even though it is badly implemented in MS-Windows, it is a small step in the right direction.
Microsoft has anounced a new patch to stop social engineering... well acually its a minor addition to the windows xp firewall that may prevent a small portion of attacks... but people won't understand that...
VINCENT
Yeah, it's legal, but is ain't a
hundred percent legal. I mean you
can't walk into a restaurant, open
up a laptop, and start settin' NX bits.
You're only supposed to hack in
your home or certain designated places.
JULES
Those are internet cafes?
VINCENT
Yeah, it breaks down like this:
it's legal to buy it, it's legal to
own it and, if you're the
proprietor of an internet cafe, it's
legal to sell it. It's legal to
carry it, which doesn't really
matter 'cause -- get a load of this
-- if the cops stop you, it's
illegal for this to search you.
Searching you is a right that the
cops in Amsterdam don't have.
It's worth noting that on most OSes, Windows included, a program that writes code to memory and then expects it to be executable without any further intervention is buggy. Windows has required a system call to make the memory executable for a long time, it's just that it wasn't actually necessary before. The programs that NX breaks were always buggy, it's just that the bug was never exposed.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
Of course, the whole mess doesn't exist in the Dutch language anyway. We live in Nederland, we speak Nederlands, and we call ourselves Nederlanders - all perfectly regular. If I called myself a "Hollander" in Dutch, I would be indicating I was from either South Holland or North Holland. If I do the same in English people understand I'm from the Netherlands.
Oh, and if the audience is American, they know I'm from the capital of a country known as Kopenhagen ;-) Sorry about that, but you must understand that American tourists who are not only lost, but in fact at least two entire countries removed from where they think they are, are the stuff of legend in Europe ;-)