Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems Software Windows Hardware

Virus Writers Look Ahead: Target 64-bit Windows 205

Posted by timothy from the yes-ma'am-just-testing-your-alarm-system dept.
Ashcrow writes "A new virus, named W64.Shruggle.1318 by Symantec, is being 'tested' on AMD64 machines running 64-bit Windows. While it is not currently a danger to 64-bit Windows users, it does show that virus writers are looking toward the future. The exploitable software in questions is currently unreleased outside of beta. News.com has the full article."
This discussion has been archived. No new comments can be posted.

Virus Writers Look Ahead: Target 64-bit Windows More

Virus Writers Look Ahead: Target 64-bit Windows

Comments Filter:

  • Interesting. (Score:5, Interesting)

    by London Bus ( 803556 ) on Tuesday August 24, 2004 @03:34AM (#10053940)
    I hadn't realised that there were sufficiently many fundamental changes to a 64-bit system as compared to a 32-bit system that meant that a virus written for one wouldn't work on the other. What's so different? How does a different integer or word size affect the functioning of a virus so greatly, when interoperability is such a priority?

    • Re:Interesting. (Score:5, Informative)

      by random_culchie ( 759439 ) on Tuesday August 24, 2004 @03:39AM (#10053962) Homepage Journal
      Well I'm sure its a concern when they are trying to cause stack overflows and the like.
      Since the memory is shifted around in bigger chuncks they will have to readadjust their code to pump more useless data to reach the memory address they want.
      Many exploits / worms are made with specific memory locations in mind inorder to inject malicious code into them.

      • Re:Interesting. (Score:5, Informative)

        by vi (editor) ( 791442 ) on Tuesday August 24, 2004 @04:30AM (#10054126)
        A virus doesn't need any stack overflow as it spreads by the user executing infected programs.
        The techniques you describe are usually used by worms.

        • Re:Interesting. (Score:3, Interesting)

          by pjt33 ( 739471 )
          I know that, and you know that, but the general public doesn't. Therefore anti-virus companies (whose products include firewalls and e-mail filters to protect against some worms) just use the word virus indiscriminantly. Meh.

      • Re:Interesting. (Score:4, Informative)

        by Zeever ( 215572 ) on Tuesday August 24, 2004 @07:57AM (#10054894)
        Actually, those kind of attacks are precisely what the new NX bit (http://en.wikipedia.org/wiki/NX [wikipedia.org]) tries to defeat. In IA32 pages in memory can be read and written, if they can be read, the can be executed (making possible the classic buffer overflow attack).
        In AMD64 (and some other architectures) pages have one more permission: they can be read, written AND executed.. and pages in the data section of a program (where you store all dynamic data, variables, arrays, etc. and buffer overflow exploits) have the NX (not execute) bit set by default.

        • Re:Interesting. (Score:2, Interesting)

          by gibson_81 ( 135261 )
          IIRC, this has been present in MMUs since the 486 (maybe 386 too) ... Don't know why it was never used ... mem pages there had the classic "RWX" permissions ... I can understand why that couldn't be used in Linux (since other CPUs might not support it), but why Windows ignores those bits is beyond me ...

          • Re:Interesting. (Score:4, Informative)

            by ultranova ( 717540 ) on Tuesday August 24, 2004 @10:39AM (#10056830)

            I can understand why that couldn't be used in Linux (since other CPUs might not support it)

            Um, you do realize that Linux contains quite a bit of architechture-specific stuff, which can be enabled or disabled at configure time ? Such as support for SMP or NUMA, for example...

            Coming to think about it, I don't think a 32-bit processor would be much amused being treated like 64-bit one, and yet Linux supports both...

    • Re:Interesting. (Score:5, Interesting)

      by dagoalieman ( 198402 ) on Tuesday August 24, 2004 @03:50AM (#10054005) Homepage
      As I understand it, and I hope if I'm wrong someone does so and gets a +5 mod... I'm going to be very general and semantic, I'm sure you'll see the point, but details as always are better. :)

      While software is made to be compatible, and Windows has code written into it to help with compatibility, as well as the processors have extensions. Windows also has code in order to take advantage of the 64 bit processor abilities to their fullest. While there's compatibility options available, most of the code that Windows executes was made for 64bit CPU (I should say most of the *compiled* code... I'm not sure how much of a rewrite was needed for porting, as opposed to compiler changes.)

      With new code comes new holes, obviously. And the same can be said for third party softwares- that new code which takes advantage of the processors to its fullest will have some new code (extending through compilation, of course).

      I would say, though, it wouldn't surprise me to find out that the programs themselves are really quite incompatible, but the files themselves are written for maximum compatibility. Pop one in an email, and it works on a 32 bit based machine I mean.

      As an aside, I wonder if this is an attack on AMD's compatibility, or 64 bit code in general.. I note that the article mentions AMD with specitivity, not Intel.

      • AMD's compatibility (Score:5, Insightful)

        by dpilot ( 134227 ) on Tuesday August 24, 2004 @07:09AM (#10054595) Homepage Journal
        AMD has the NX bit, and ISTR that Intel doesn't have it on their IA32e, or whatever the heck they call it, and that they reserved NX for IA-64. The NX bit makes the job more demanding for virus and worm writers, so I would expect AMD to give them additional concerns.
        • This was only true for a very short period of time on paper, and is no longer true on the consumer market. The first IA-32e/EM64T enabled Pentium 4 Intel is shipping is the P4 "Prescott" Model F, which is based off of the E-0 core. The E-0 core not only supports EM64T(which was added in the D-0 core for Xeons), but eXecute Disable(XD) support, Intel's version of NX, was added in the latest core(AnandTech [anandtech.com] has the full details). We should see the first P4F's this September.
      • For the record, I didn't mean to write that sounding like an AYB post. Jeesh. Let me repost with grammatical and sensical corrections: (DO NOT MOD THIS COMMENT!)
        =================
        As I understand it, and I hope if I'm wrong someone corrects me and gets a +5 mod... I'm going to be very general and semantic, I'm sure you'll see the point, but details as always are better. :)

        While software is made to be compatible, Windows has code written into it to help with compatibility, as well as the processors have ex
    • I'm going to write a library that I can port around to different operating systems and have all users install. Then the virus makers can just write against that library and have their viruses run against all platforms. Of course, this means distributing the virus in source code form and compiling it on the target computer, but I'm sure users would be more than happy to take that step for you. ;)

      • Re:To make things easier (Score:5, Funny)

        by mr_z_beeblebrox ( 591077 ) on Tuesday August 24, 2004 @06:59AM (#10054553) Journal
        Of course, this means distributing the virus in source code form and compiling it on the target computer, but I'm sure users would be more than happy to take that step for you.

        I can hear that conversation now: "I can't run this Anna Kornokova Simulator"
        "Call Bob he is a linux user, he can help you"
        "Hey Bob, I got the Anna K sim and..."
        "You know that will be a virus"
        "No, it's different THIS time. Tell me again the magic words, I am sure it'll be okay"
        "SIGH, dot slash config...MAKE....MAKE INSTALL"

    • 3 reasons.... (Score:5, Informative)

      by DrYak ( 748999 ) on Tuesday August 24, 2004 @07:15AM (#10054635) Homepage
      1. First most important technology :
      AMD64 processors have NX extension [wikipedia.org].
      Which [quoting wikipedia] : "stands for "no execute", a technology used in CPUs such as Sun's Sparc, Transmeta's Efficeon, and newer 64-bit x86 processors to prevent code from being executed on areas of memory flagged with an NX bit. This feature signifigantly lowers the probability of crackers exploiting buffer overflows and increases overall system security.".
      This technology is only supported in newer OSes like Windows XP 64 and Windows XP SP2. It wasn't supported before (exemple in Windows XP SP1 or in Windows 2000).
      So before all, a new AMD64-compatible virus, has to cope with new forms of protection.

      2. Binary compatibility.
      This is going to be more technical.
      AMD64 (and Intel's clone "EMT64") are an extension over the standart 32bits inscruction set (IA-32).
      So yes, AMD64 could run any 32bit code natively, unlike Itanium (which can only emulate it, with some hardware assistance).

      BUT : A worm isn't your average spread-sheet application. It doesn't always run stand-alone.
      In order to perform some operation, like infecting a computer without user attention, or gaining administrator privileges, or hacking some kernel stuff to help its replication, the worm must inject code inside OTHER application.

      And even if the virus is 32bit, if it infects a 64-bits OS, odds are the applications in which the virus must inject code (e-mail client, kernel, etc...) will be 64bits application.

      64bit bit binary code isn't necessary exactly the same as 32bit. Some binary code may be interpreted as different instruction depending on whether the memory segment (the application) was tagged as "16bit code", "32bit code" or "64bit code".
      The processor can run all of this "dialects" natively in hardware, but may be expecting a different dialect because the application is tagged as 64bits and the injected code was intended for 32bits systems.

      Denpending on the implementation (i don't know AMD64 well enough), when loading data into pointer register, the 32bit code running in 64bit application could either :
      - only override the lower 32 bits of the pointer, keeping intect the upper 32 bits.
      i.e.: load 0x00001234 into a register whose value is 0x0012345601234567, will give you 0x0012345600001234) a different location than expected by the virus, and the machine would crash instead of being infected.

      - read pas the lenght of the instruction in code memory.
      simplified exemple :
      if code is "LOAD into pointer 0x00001234, then ADD 500 to register B".
      the pointer will be loaded with garbage data "0x0001234, then ADD", and the processor will try to execute code form "500 to register B" which doesn't mean anything, and the machine would crash instead of being infected.

      (some useful link about 64bit architecture) [wikipedia.org].

      3. Memory model :

      Last but not least, memory organisation is different between a 32bits and a 64bits OS.
      So worm should use different exploits to inject code into different places.

  • It sucks to be Microsoft knowing you are the #1 target for these people. I wish they didn't make it so easy...
    • Then, from a biology perspective, when a cell is cancerous (growing without an off switch) some chemotherapy is in order, right? Whether it's chips or software, someone is going to pursue or craft a knee-capping piece of code. Maybe not many attacks are going specifically after Intel's wares, since it seems the code running in their chips is not (from what I gather) crippling Linux running on the same CPUs that ms windows (lower-casing/deprecation intentional) -based computers.

      Maybe this cracking and hacki

  • Beta testing (Score:5, Funny)

    by Anonymous Coward on Tuesday August 24, 2004 @03:36AM (#10053949)
    Where can I sign up for beta testing!?

  • I always suspected (Score:3, Funny)

    by aussie_a ( 778472 ) on Tuesday August 24, 2004 @03:38AM (#10053960) Journal
    but now I know. It IS those damn virus protectors making the viruses. I always said if there weren't any viruses the virus protectors would be out of business and they wouldn't allow it. This is the proof.

  • This just in... (Score:3, Funny)

    by AnimeFreak ( 223792 ) on Tuesday August 24, 2004 @03:39AM (#10053964) Homepage
    ...a virus has been created for the 68000! Virus writers are thinking in the past! It's called W32@Lame.

  • Phew! (Score:4, Funny)

    by MisterLawyer ( 770687 ) <<mikelawyer> <at> <gmail.com>> on Tuesday August 24, 2004 @03:44AM (#10053981)
    While it is not currently a danger to 64-bit Windows users, it does show that virus writers are looking toward the future.

    Phew! I was worried that all those hordes of current 64-bit Windows users would be at danger.

    • Re:Phew! (Score:3, Funny)

      by mkosmul ( 673296 )
      While it is not currently a danger to 64-bit Windows users, it does show that virus writers are looking toward the future.
      Maybe the virus is also a beta, so it still lacks some functionality the retail version is going to have.

  • This shows once again (Score:5, Insightful)

    by Anonymous Coward on Tuesday August 24, 2004 @03:44AM (#10053983)
    that Windows is just targeted because it is so popular, not because of inherent security problems.

    After all Windows 64-bit is allready installed on millions and millions of machines so it is only natural that hackers attack it instead of those few machines that run 64-bit Linux.

    Oh, wait...

    Nevermind.

  • conspiracy? (Score:4, Insightful)

    by rixdaffy ( 138224 ) * on Tuesday August 24, 2004 @03:46AM (#10053993) Homepage
    Sometimes it is almost as if antivirus companies hire people to write all those "proof of concept" virusses, just to make sure that they don't loose any marketshare and they have another good reason to have their spread through press releases...

    Ricardo.

    • Re:conspiracy? (Score:2, Interesting)

      by Anonymous Coward
      "almost"?

      I have seen several virus warnings in computer mags that go "This virus has currenly not been spotted outside of $ANTIVIRUSCOMPANY's labs".

      Well, how did it get in there, if not from the outside? It was made in there.

      • Re:conspiracy? (Score:3, Interesting)

        by Anonymous Coward
        Unless it somehow infected their computers or their systems were targeted maybe??? I know of a few virus authors who turned from black-hat to white-hat instead of spend time in jail, that isn't a bad thing. Where will you find the really great, if misguided geniuses? John Carmack wanted to be a phreak in the early bbs days.

      • Re:conspiracy? (Score:5, Informative)

        by flonker ( 526111 ) on Tuesday August 24, 2004 @04:39AM (#10054149)
        Virus writers will frequently submit their own virus to the AV companies, to get it listed in the AV software. They don't release it into the wild, out of ethics, but they get some ego gratification and acknowledgement. When AV companies claim they detect a huge number of viruses, most of the viruses they detect have never been seen in the wild. It's a good thing too, as most viruses in the wild are very simple things. Some proof of concept viruses can be extremely hard to detect and remove.
  • "The virus supports vectored exception handling to avoid crashing during infections."

    Maybe this is a good thing.
    Those viruses will show developers how to write better code. :->

    Seriously though, vulnerabilities will grow in proportion to the complexity of our systems.

  • oldschool (Score:5, Informative)

    by prockcore ( 543967 ) on Tuesday August 24, 2004 @03:51AM (#10054009)
    This is an oldschool virus, it works by appending itself to the end of an .EXE, the Linux "proof-of-concept" viruses worked this same way.

    MS actually has some safeguards to prevent this thing, but it could use some minor tweaks to make it even better.

    I propose that XP should require you to create a user account by default.

    I propose that all software should be distributed as .MSI files instead of .exe installers. (They work the same, double click the .MSI and it runs MS's Installer, but the MSI can't run arbitrary code.. it works like an RPM in this regard).

    The installer should prompt for the Admin password and install the .exe so that only admin can write to it.

    Any .exe not installed by the MS Installer should be marked as "dirty", and windows should refuse to run it.

    This would prevent this type of virus. Coupled with XP64s support for NX, you'd actually have some semblance of security.

    • Re:oldschool (Score:3, Insightful)

      by Dogers ( 446369 ) *
      ..causing Jonny Public and his family endless grief, making them stick to windows 2000 or 98.

      The general public are stupid and would not even be able to handle that level of security! They'd want to know why their new mouse cursors can't be installed, why their IE search bar needs a password, etc, etc

      • Re:oldschool (Score:5, Insightful)

        by prockcore ( 543967 ) on Tuesday August 24, 2004 @04:20AM (#10054100)

        The general public are stupid and would not even be able to handle that level of security! They'd want to know why their new mouse cursors can't be installed, why their IE search bar needs a password, etc, etc

        Good. It's time for the general public to suck it up.

        If the general public can handle OSX (and presumably they can), then they can handle this. OSX installers require the admin password.

        • Re:oldschool (Score:2, Insightful)

          by samael ( 12612 )
          It's time for the general public to suck it up.

          Nobody ever made money with that kind of attitude...

        • Lol the general public can't handle OSX (Score:5, Interesting)

          by SmallFurryCreature ( 593017 ) on Tuesday August 24, 2004 @06:41AM (#10054513) Journal
          The average Apple user I have met isn't a computer whizkid. However there is a huge difference with the unwashed windows hords. The Apple user KNOWS he is a computer moron. Most of them therefore do little things like read the goddamn fucking manual. They are also less likely to be upset about safeguards. (just check with your local emergcency crew, it isn't the 2 left hands doctor who decides to do a bit of DIY who cuts of his thumb. It is the DIYer who think he knows it all and thinks safety catches are for wimps)

          The problem with windows isn't that its users are stupid and don't know shit. The problem is that MS has chosen to encourage these computer morons to feel like they know what they are doing and has given them enough rope to hang themselves with.

          It makes people feel good and gives helpdesk monkeys around the world fulltime employment.

          Remember, virusses, trojans, spyware ARE GOOD for the local economy.

          • I don't know much about Mac, but you're right about who causes the problems. I've helped several "morons" with Windows, but the worst were the "morons" who thought they knew what they were doing - and didn't!

          • The average Apple user I have met isn't a computer whizkid. However there is a huge difference with the unwashed windows hords. The Apple user KNOWS he is a computer moron. Most of them therefore do little things like read the goddamn fucking manual.

            It probably helps that Apple has some of the best manuals in the industry.

            I'd add a huge caveat to your generalization. OS X has attracted a whole lot of really intelligent people with its *BSD-based underpinnings. Their hardware and software is exceedingl

    • Re:oldschool (Score:3, Insightful)

      by iainl ( 136759 )
      I was almost with you, right up to the "Any .exe not installed by the MS Installer should be marked as "dirty", and windows should refuse to run it" comment.

      I understand your concern, but this would break compatibility with absolutely everything, which would be enough to make people avoid upgrading. I agree that it would make virus-writers lives more difficult, but its at too high a price on the user's experience.

      Maybe an alternative would be an Admin-controlled "install mode" - drop into that, and for th

    • Re:oldschool (Score:2, Informative)

      by LiquidCoooled ( 634315 )
      If you impliment everything exactly as you say, then viruses and trojans will just get packaged inside msi files.

      As long as there are executable entry points, malicious code will unfortunately always find a way to run.

      The best we can do is limit the damage they can cause, and requiring users to run in user space has been proven to be a good defence. Granted, its not foolproof at the moment, but we have to build on what works.

    • Re:oldschool (Score:2, Informative)

      by Anonymous Coward
      An MSI file can't run arbitary code? You're kidding; the Microsoft Installer Engine has an entire scripting language and full access to the registry and filesystem. MSI files created with installer creation tools such as Install Shield have their own, even more powerful scripting capabilities; you could write a complete application with it if you were perverse enough.

    • I agree, forget Joe (L)user (Score:5, Interesting)

      by panurge ( 573432 ) on Tuesday August 24, 2004 @04:45AM (#10054166)
      W64 is an opportunity to move away from the whole "the system has to be insecure because Joe Sixpack is stupid" syndrome. If OS X can drop down a window asking for an admin password before installing updates, so can W64. W64 will be supposed to be a professional OS, for Turing's sake. Why can't MS simply use a few $$ of the billions to produce a nice "read this first" poster to explain to newbies how their nice new security system works, and how it will make using the computer so much more pleasant?

      Tinfoil hat time: perhaps all the FUD about SP2 problems, users unwilling to update etc. is just being put out by spammers and malware merchants.

      I agree there is a problem, especially with people who think they are creative. I'm afraid I was positively delighted when the author Louis de Bernieres lost the first 60 pages of his new novel becaue he had failed to make a backup, and complained that he didn't expect to have to make backups, he wasn't a computer expert (or words to that effect). People need to understand that failure to learn the basics can result in pain and distress.

    • Re:oldschool (Score:5, Informative)

      by mlock ( 648386 ) on Tuesday August 24, 2004 @05:28AM (#10054293)
      > I propose that all software should be distributed
      > as .MSI files instead of .exe installers. (They
      > work the same, double click the .MSI and it runs
      > MS's Installer, but the MSI can't run arbitrary
      > code.. it works like an RPM in this regard).
      Sorry, doesn't work.

      MSI files can embed DLL's, and these can be called during setup.
      http://msdn.microsoft.com/library/en-us/ms i/setup/ adding_launch_to_the_customaction_and_binary_table s.asp

      Like the post-conf scripts in RPM and DEB :-)


      • >Like the post-conf scripts in RPM and DEB :-)

        I always thought this was a bad idea and should be replaced by various triggers.
    • Any .exe not installed by the MS Installer should be marked as "dirty", and windows should refuse to run it.

      I guess not EVERYONE does development work...
      You couldn't use anything compiled from source, though...
    • What about programs that need no installation to run, such as the wonderful Popcorn [ultrafunk.com] and other such 1-exe no-registry crap programs?
    • I propose that XP should require you to create a user account by default.

      Woah, woah slow down sparky! I know what you're getting at but last I checked there's no graceful way to switch users back and forth while the system is running. That being said there are not-so-graceful ways (perhaps one of Microsoft's many mascots would be willing to help), but switching back and forth isn't as simple as a shortcut with an F key. This isn't Linux. One computer, One user, One operating system. Microsoft.
    • MSI can't run arbitrary code.. it works like an RPM in this regard

      A .rpm file certainly can execute arbitrary code on installation and uninstallation. The postinstall script can call an arbitrary executable from the package you just installed. You can even have triggers, such that one package gets to execute some code when another package is installed.

  • Wow! Beta Viruses! (Score:2, Interesting)

    by ArbiterOne ( 715233 )
    Speaking of proof-of-concept (RTFA), could this be the first virus to attack a product that's still in beta?

    Actually, this doesn't really make a lot of sense. If the entire point of a virus is to cause widespread destruction, then doesn't it make more sense to write a virus for 32bit computers?

    • Ìf you did RTFA you would see that the virus was a proof of concept released on an antivirus newsgroup.
      In other words these people have discovered the problem and given it some publicity by making a basicly useless virus. Their intent is not malicious
      Its like the first virus for the .NET platform. It existed just because it could.

  • Viruses (Score:4, Interesting)

    by Un0r1g1nal ( 711750 ) on Tuesday August 24, 2004 @04:04AM (#10054051)
    Although I thoroughly disagree with these malicious programs, and any virus of any discription, they do encourage people to create neater code and to develop better code that is invulnerable to these kinds of exploits. One could always hypothesise about how much we may or may not have developed programming code without having to spend money on prevention of these exploits.

    • Re:Viruses (Score:4, Informative)

      by DrSkwid ( 118965 ) on Tuesday August 24, 2004 @04:25AM (#10054117) Journal
      and any virus of any discription[sic]

      If you had any sense you'd notice that the "virus" in question was written by anti-virus people as a way to demonstrate a vulnerability of the w64 platform.

      Do you find road car crash tests equally repugnant?

      One could always hypothesise about how much we may or may not have developed programming code without having to spend money on prevention of these exploits.

      As long as there are systems there will be exploits; be it computers, social security, passports, education - such is the way of the dragon.

    • Re:Viruses (Score:3, Informative)

      by morzel ( 62033 )

      Although I thoroughly disagree with these malicious programs, and any virus of any discription, they do encourage people to create neater code and to develop better code that is invulnerable to these kinds of exploits.

      Dude... It's a virus [wikipedia.org], not a worm [wikipedia.org].
      You can write your code as secure and neat and clean as you want, that doesn't protect you from a virus that injects some code into your compiled executable.

      Operating systems may be part of the solution, but IIRC we are weary of proposed solutions (ie: TPC

  • This mal"ware" will probably have a better beta test cycle than most of the soft"ware" released these days. It'll be idiot proof, so anyone can get infected...

    - No need to call us, we'll infect you.

  • typical (Score:2, Insightful)

    by Anonymous Coward
    As usual, there are few calls to shoot the damn writers of the viruses ... the true problem.

    If it wasn't for the criminals, most windows 'problems' wouldn't be an issue at all.

    before you whine at me, and incorrectly call me flamebait for disagreeing with your somehow more enlightened views about the great good those virus writers do with their vandalism ...

    what do you think of grafitti? do you like it when you look outside in the morning and see some bastard's tag painted on your building?

    You fools trea

  • In unrelated news... (Score:3, Interesting)

    by MickyJ ( 188652 ) on Tuesday August 24, 2004 @05:21AM (#10054274) Homepage Journal
    ...anti-virus company profits are down.

  • Sourcecode (Score:4, Funny)

    by MikeDX ( 560598 ) on Tuesday August 24, 2004 @05:22AM (#10054275) Journal
    I bet the code is something like this:

    while(windows) {
    infect();
    }
  • ..oh no, I missed the "named by" bit.
    Makes you wonder though...

  • Yay! (Score:2, Interesting)

    by kg_o.O ( 802342 )
    Hardware stack protection, finally, after all these years! All praise AMD! ;]

  • here's the grain of salt (Score:5, Interesting)

    by maxpublic ( 450413 ) on Tuesday August 24, 2004 @06:39AM (#10054503) Homepage
    Some years ago I contracted with Symantec for about five months and worked closely with several of their departments, including the folks who did tech support for their anti-virus software. During that time Symantec offered a cash bounty to any techie who brought in a virus 'from the wild' that wasn't covered by the their antivirus software.

    It was common knowledge that many of these 'wild' viruses were actually, in fact, written by the support staff themselves in order to collect on the bounty. But Symantec didn't care because this just allowed them to enlarge their virus definition file and show their customers why it was important to subscribe to their update service. From my point of view it was a "wink, wink, nudge, nudge" sort of thing.

    This was one of just many things about Symantec which disgusted me so much that after that contract I refused to work with them ever again. I don't know if they still have an update service for their anti-virus software, but it wouldn't surprise me if many of our future 64-bit viruses came directly from employees of Symantec itself.

    It's a great business model: release the viruses, then sell the software that combats those viruses. Unethical and illegal, but a solid money-maker for those who don't care about such trivial things.

    Max
    • If you have any proof of this, it's a huge story that the media would go ape-shit over. Seriously, it would be a public service, too.

    • Re:here's the grain of salt (Score:4, Informative)

      by Anonymous Coward on Tuesday August 24, 2004 @09:09AM (#10055592)
      But Symantec didn't care because this just allowed them to enlarge their virus definition file and show their customers why it was important to subscribe to their update service

      This common accusation is a hoax. All major virus detection houses signed a mutual agreement to share their virus research. At one point, all these compagnies decided they would compete on features, ease of use and so forth, but not on virus coverage.

      They did so in part to better protect their consumer, but also to dodge the baseless accusation made above.
      • They did so in part to better protect their consumer, but also to dodge the baseless accusation made above.

        I don't know how they do business nowadays, but this was the way things were done when I contracted for them. I know, I was there. You can say whatever you want about this being a "hoax" or a "baseless accusation", but it doesn't change what I know to be true.

        The only thing I'll say further on the matter is that this occurred over seven years ago. It's possible that the company changed it's modus
  • "it does show that virus writers are looking toward the future"

    Not to insult the journalistic talent that is Timothy, but seriously guy, you need to come up with a better introduction to an article that isn't full of utter stupidity. Nothing pisses me off, or makes me reel in laughter more than a muckraker introducing an article in the wrong manner.
  • I do not understand this.
    What's the "proof of concept"?
    So someone wrote a program that looks for files that are executables and adds some code to the end that does the same thing?
    Does it promote itself to run with system permissions, or only user-level perms?
    As near as I can tell, the writer went to some trouble to limit his program so that it can only propagate on a particular machine and OS, and called it a '64 bit virus'.
    On the other hand, maybe I just don't get it.

Slashdot Top Deals

I had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham

Close