[TETENAL]

http://www.amd.com/us-en/assets/cont...ection_VNR.wmv

Does anybody know how the AMD virus protection that is talked about here works technically?

[King Bob On The Cob]

Well, I'm assuming 2 things.

a) WMV is evil and thou shalt not link to it.
b) They're talking about the execute bit, which would mean that code that is executable HAS to be set that way by the compiler. It prevents buffer overflow attacks that cause some of the worst damage (they can allow someone to escalate privileges and execute arbitrary code just by running the exploit.)

[OreoCookie]

This is an old story for workstation-class cpus. OpenBSD has a kind of software implementation of this, they put executable code into one half of the memory, data in the other, and allow execution only of things which are located in the executable half.

[ghporter]

As mentioned in the news clip, a lot of exploits against Windows take advantage of unchecked buffers and capitalize on an application filling a buffer beyond its size, thus saving code in a different part of memory that supposedly will allow that code to be executed. XP service pack 2 and AMD's Athlon 64 both appear to check the size of a destination buffer and disable anything that tries to store data past the end of the buffer-SP2 thorugh simply stopping the fill and I believe the Athlon does it by preventing the fill entirely.

As Oreo says, this isn't really new, but it is good that it's being done at both the OS and hardware levels.

[Sarc]

kernel code is sopposed to prevent buffer overflow attacks as well ...
http://www.trusteddebian.org/demo.html

[ghporter]

Linux and other *nix OSs (including Mac OS X) do a much better job of avoiding buffer overflow problems than Windows. This is probably because they are not built from "legacy code" that is adapted to tasks it was never written for, as much of Windows is.

[King Bob On The Cob]

Originally Posted by ghporter

Linux and other *nix OSs (including Mac OS X) do a much better job of avoiding buffer overflow problems than Windows. This is probably because they are not built from "legacy code" that is adapted to tasks it was never written for, as much of Windows is.

Are you saying *NIX is not legacy and NT is?
Now don't get me wrong, I'm a huge Apple fanatic, but this blatant mis-information needs to stop. OS X is more secure for a number of reasons (doesn't come with 30 billion services on by default, requires Admin password to install stuff into the OS, ect) but pretty much the only reason we get security patches is because of buffer overflow errors being found in the open source side of things.

[OreoCookie]

Originally Posted by King Bob On The Cob

Are you saying *NIX is not legacy and NT is?
Now don't get me wrong, I'm a huge Apple fanatic, but this blatant mis-information needs to stop. OS X is more secure for a number of reasons (doesn't come with 30 billion services on by default, requires Admin password to install stuff into the OS, ect) but pretty much the only reason we get security patches is because of buffer overflow errors being found in the open source side of things.

No, it goes even further. I wouldn't even say it is due to legacy compatibility with NT. Just an example. Windows NT up to 3.5 had its window manager running on top of the kernel which cost performance, obviously. NT 4.0+ did integrate that into the kernel, improving performance. On the other hand, if you can compromise the window manager, you are already in kernel space which gives a perpetrator many more options to choose from.

[ghporter]

The "legacy code" I'm talking about can come all the way from DOS 3. Microsoft reuses code chunks very freely-and pieces of code that were never intended to go on a computer that could communicate with other computers often have gaping holes that can cause serious problems. For purposes of this discussion, I'd almost call NT "current code." Unfortunately I can't since not all of NT (any flavor) is new code.

In contrast, Unix and its variants are all written intentionally to allow computers to communicate with each other, and such things as "unchecked buffers" are pretty much unheardof. Plus all of the variations on Linux are scoped out by a very large number of fanatics who live to "make their contribution" to the OS. Here "fanatic" is not intended to be derogatory; the folks that review Linux kernel code are simply exceptionally passionate about it.