Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
AMD Security

Holland Bans AMD's 'Virus Protection' Campaign 330

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?"
This discussion has been archived. No new comments can be posted.

Holland Bans AMD's 'Virus Protection' Campaign

Comments Filter:
  • by LostCluster ( 625375 ) * on Wednesday December 29, 2004 @02:03AM (#11206732)
    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:Eh, whatever. (Score:3, Informative)

    by Tanktalus ( 794810 ) on Wednesday December 29, 2004 @02:12AM (#11206763) Journal

    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.

  • Not just for servers (Score:5, Informative)

    by gad_zuki! ( 70830 ) on Wednesday December 29, 2004 @02:14AM (#11206780)
    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.
  • by karniv0re ( 746499 ) on Wednesday December 29, 2004 @02:16AM (#11206787) Journal
    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, [wikipedia.org] as well as a nice article on the NX bit [wikipedia.org].
  • by Anonymous Coward on Wednesday December 29, 2004 @02:19AM (#11206799)
    Reclame Code Commissie of the Netherlands, an organization that regulates advertising in the country, recently said some or all AMD EVP radio ads were "too absolute and as a result misleading"

    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?

  • by Anonymous Coward on Wednesday December 29, 2004 @02:25AM (#11206826)
    The people behind X-bit Labs are Russian and Estonian, but don't let that stop you from taking a shot at Americans.
  • Re:Does it rely... (Score:5, Informative)

    by CoolGopher ( 142933 ) on Wednesday December 29, 2004 @02:30AM (#11206845)
    For those of you who don't remember the evil bit, it's RFC 3514 [faqs.org].
  • by choas ( 102419 ) on Wednesday December 29, 2004 @02:35AM (#11206871)
    Noord-Holland, Zuid-Holland, Zeeland,
    Friesland, Groningen, Brabant, Limburg,
    Drente, Overijssel, Gelderland, Utrecht
    and Flevoland. ... To be exact.

  • Re:Does it rely... (Score:2, Informative)

    by ip_fired ( 730445 ) on Wednesday December 29, 2004 @02:56AM (#11206952) Homepage
    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.
  • Re:Hum. (Score:4, Informative)

    by Anonymous Coward on Wednesday December 29, 2004 @02:58AM (#11206958)
    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.
  • by Anonymous Coward on Wednesday December 29, 2004 @03:01AM (#11206968)

    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:Honest Answer (Score:1, Informative)

    by Anonymous Coward on Wednesday December 29, 2004 @03:19AM (#11207039)
    Hmm, as far as I can tell Linux has no functionality where the "Start Menu", "User Switching", or the "middle mouse button" are concerned.

    However, perhaps in your ignorance you meant "GNU/Linux", though really I think you just mean GNU or more generally opensource.

    In which case here I am in Gnome2...Where is that Start Menu again?

    User switching? Oh yeah, I disabled that in Windows because it was so annoying (I mean, you have to do the windows update every day to stay safe, then you have to find whoever logged in to make sure they shut their apps down, etc).

    Middle mouse button? What useful feature does that have in Windows. At least I can paste with it in X, which is quite the timesaving feature.

    "etc" - Does that include FUD?

    The Golden Rule - "A Troll for a Troll"
  • Can understand.. (Score:2, Informative)

    by kaiwai ( 765866 ) on Wednesday December 29, 2004 @03:21AM (#11207043)
    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.
  • by Anonymous Coward on Wednesday December 29, 2004 @03:23AM (#11207052)
    Man, you really have no idea what you are talking about. In my practice (and it apparently not as limited as yours) linux software goes through a lot more stringent control than windows counter parts (say adobe or winamp or even the microsoft products). On the other hand if you look at the BSD front well buddy, OpenBSD is the only OS out there that can say that it has only 2 vulnerabilities found in it's over 5 year history. Plus it is light years ahead of the Windows kernel. It has encrypted virtual memory plus a whole bunch of other security goodies. I have yet to hear of a well mainained FreeBSD server that got hacked.

    Oh yeah and if you knew anything about system design you would also know that buffer overflows increase rather than decrease as your software base grows (i.e. "problem just gets lost in the systemic noise" this must be the most dilusionate thing that I have heard in a long time). First of all there is no such thing as *systemic noise* and second of all the more stuff you install the higher the chance for a buffer overflow in your system because it has to integrate all the newlly added dlls and make sure that they play nice (in layman's terms).
  • by tepples ( 727027 ) <tepples.gmail@com> on Wednesday December 29, 2004 @03:23AM (#11207053) Homepage Journal

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

  • by VertigoAce ( 257771 ) on Wednesday December 29, 2004 @03:31AM (#11207080)
    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).
  • by cablepokerface ( 718716 ) on Wednesday December 29, 2004 @04:27AM (#11207269)
    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.
  • by Anonymous Coward on Wednesday December 29, 2004 @05:01AM (#11207354)
    Some (many) of these compilers recompile on the fly and sometimes even jump back in the program to insert a later generated faster routine (useful in cases like a generic function, or multiple runs of the program)
  • Ah, here it is (Score:1, Informative)

    by Anonymous Coward on Wednesday December 29, 2004 @05:02AM (#11207364)
    This seems to be the post that hit the news:
    http://gathering.tweakers.net/forum/list_message/2 2383398#22383398 [tweakers.net]
  • by Anonymous Coward on Wednesday December 29, 2004 @05:36AM (#11207458)
    > This is akin to OpenBSD's W^X,

    Akin to ? W^X is the usage of this hardware feature. On platforms without a proper executable bit in the MMU, W^X becomes either difficult or impossible to implement.

    > which specifies that memory can be either Writable or eXecutable but never both.

    "never" is wrong here. You can explicitly request that memory is writable and executable using mprotect()
  • by lucason ( 795664 ) on Wednesday December 29, 2004 @05:56AM (#11207524) Homepage
    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.
  • by iamacat ( 583406 ) on Wednesday December 29, 2004 @06:24AM (#11207605)
    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.
  • by SillyNickName4me ( 760022 ) <dotslash@bartsplace.net> on Wednesday December 29, 2004 @07:07AM (#11207713) Homepage
    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.
  • by andreyw ( 798182 ) on Wednesday December 29, 2004 @07:24PM (#11214125) Homepage
    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.

    --------->
    (gdb) break main
    Breakpoint 1 at 0x8048d77: file nasm.c, line 150.
    (gdb) run
    Starting program: /home/andyw/nasm-0.98.38/nasm

    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: /home/andyw/a

    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.

The one day you'd sell your soul for something, souls are a glut.

Working...