Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security IT

Attacking Sandboxes 110

Posted by kdawson from the just-another-brick-in-the-wall dept.
SkiifGeek writes "Many anti-malware applications use a sandbox as a tool to help identify potentially malicious software. Now knowledge is spreading about techniques and methods that can allow sandboxed software to target the sandbox itself (and by extension the application that applied it). While attacks that specifically target sandboxing applications are probably a little way off, this technology can be considered the logical extension of techniques and procedures to identify the presence of hosted systems (VMWare, Virtual PC, etc.)."
This discussion has been archived. No new comments can be posted.

Attacking Sandboxes More

Attacking Sandboxes

Comments Filter:

  • Enter the Sandbox (Score:2, Funny)

    by Anonymous Coward
    So when will we be able to attack the Matrix?

  • Sandbox the sandbox (Score:4, Funny)

    by robo_mojo ( 997193 ) on Sunday July 15, 2007 @08:08PM (#19871733)
    That's ok. We can just sandbox the sandbox and still be safe.

    • Re:Sandbox the sandbox (Score:5, Funny)

      by langelgjm ( 860756 ) on Sunday July 15, 2007 @08:19PM (#19871833) Journal
      But who will sandbox the sandboxers?

    • Re:Sandbox the sandbox (Score:5, Funny)

      by GizmoToy ( 450886 ) on Sunday July 15, 2007 @08:23PM (#19871861) Homepage
      You know, this was marked as Funny but I wouldn't be surprised if this was suggested as a solution at some point. "Hell, just wrap it in another (insecure) layer and it'll be fine."

      • Re:Sandbox the sandbox (Score:5, Interesting)

        by CastrTroy ( 595695 ) on Sunday July 15, 2007 @09:47PM (#19872345)
        Sounds like the security methods most online banking systems use. Here's the current layers:
        • password
        • mother's maiden name/ what's you're favourite movie
        • secret picture
        • randomized keypad for entiring password

        It's all layers of useless crap piled on top of eachother which doesn't stop the real problem of people falling for stupid fishing sites, and entering a password in a site that looks like their bank's. If they really wanted to add real security they'd hand out RSA key fobs to everyone instead of adding layers of stuff that makes it look more secure but actually isn't.

        • Re: (Score:3, Insightful)

          by billcopc ( 196330 )
          So you're saying the RSA key fob isn't another useless insecure layer of crap ? Have you even HEARD their sales pitch ?

          • Re:Sandbox the sandbox (Score:4, Insightful)

            by Poltras ( 680608 ) on Sunday July 15, 2007 @11:20PM (#19872827) Homepage
            as long as USERS don't understand it, yes it is useless. Secure the communication and provide X509 certs all you want, if the user think it's a bank, he will enter his password.

            • Re: (Score:3, Insightful)

              by mcrbids ( 148650 )
              as long as USERS don't understand it, yes it is useless. Secure the communication and provide X509 certs all you want, if the user think it's a bank, he will enter his password.

              I don't think you understand what he's really saying - you could hand out RSA key fobs and/or client certificates that authenticate the browser to the bank. Without that, the password would/could be utterly useless.

              If the bank uses the key fob, you can't enter by password alone. If the bank uses client certificates, then that must be

              • Re: (Score:2, Interesting)

                by 0xygen ( 595606 )
                How does prevent the existing real time man in the middle attack?

                e.g. user visits phisherman's site, phisherman's server visits bank, passes on RSA auth request to user's browser, user's browser passes auth request back to phisherman, who passes it to bank. Phisherman now logged on as user?

                • Re: (Score:2)

                  by mcrbids ( 148650 )
                  How does prevent the existing real time man in the middle attack?

                  This question belies a misunderstanding of public-key cryptography. With public cryptography (often called dual-key cryptography) the only thing exposed is a public key, which can only be used to encrypt. Without the matching private key, anything encrypted with the public key is indecipherable.

                  Thus, the man-in-the-middle attack is prevented.

                  • Re: (Score:1)

                    by 0xygen ( 595606 )
                    Sorry, you are indeed correct if we assume they are handing out private keys.

                    When you said "RSA key fobs" I instantly thought of RSA SecurID tokens, which believe do not provide this as a feature, so would leave the mentioned hole open. However private keys clearly are provided by the RSA Smart Key range, which, as you say, would stop the MITM.

                    Does anyone know if RSA Smart Keys (or equivalent) actually integrate with browsers easily?
              • '' I don't think you understand what he's really saying - you could hand out RSA key fobs and/or client certificates that authenticate the browser to the bank. Without that, the password would/could be utterly useless. ''

                A very low-tech approach would be this: On your paper bank statement that you receive every month, print a list of twenty 10-digit access codes. Each access code can be only used by you, in the following month, and only once. One month delay so you can tell your bank if the statement didn't
                • So what do you propose to do after you log in twenty times in a month?
                  • Here in Finland we have a system where the bank sends 80 one-time passwords to the customer along with 18 reusable passwords. To log on into the bank's website you need your customer id with the one-time password. To do anything in the website, eg pay the bills or do a money transfer to another account, you need to accept the transaction with one of the reusable passwords. When you've reached 60th or so of the passwords the bank sends you a list of the next 80 passwords. I feel it's secure and quite easy t
                • I think that would really tee off the users. Having to keep your statement around for a month? I throw mine out as soon as I verify that there is roughly the expected amount of money in my account.

                  Plus banks are trying to push people to electronic statements. They're actually more secure, since mail theft is a very common method of obtaining personal information.

                  I would also appreciate it if they didn't let someone log in use "bill" pay, which I had never previously used, to send himself (well probably s
                  • Every single bank I've dealt with, has done some sort of semi-secure bill registration. In some cases I even had to call a human being to add a bill to my account. If someone breaks into my online banking, the worst they could do is overpay my bills. That's very evil, but it doesn't benefit the intruder much at all, save for the sadistic pleasure of giving my money to my worst enemy: Rogers Telecom. If your bank lets anyone send money anywhere, you need to start shopping for a new bank.

                    Mind you, I'm in
                    • I was at BofA at the time, lured in by their student accounts with no fees and forgiven overdraft fees. Of course I dropped them after that incident.

                      For anyone in the US reading this, I would recommend finding a credit union. Since they are owned by the members, they are generally more responsive, offer lower rate mortgages to long time customers, etc. Also your money is lent out to people like you, based on whatever criteria for which you can find a credit union including: your religion, your local regi
              • Phishers can still MITM two-factor authentication. OTP methods, like SecurID, and smartcard authentication (hardware-based client X.509 certs), can be forwarded on to a bank if you get the user to go to a bogus site.

        • Re: (Score:3, Informative)

          by arminw ( 717974 )
          ..... If they really wanted to add real security they'd hand out RSA key fobs to everyone......

          Does that mean the use is restricted to the users own computers or any others that has the correct interface and software which is able to send the key-fob data to the bank's server at the correct time?

          A password will work with *any* computer, but a piece of hardware, whether key-fob or biometric scanner will only work with a computer that has the correct software installed on it. That software would have to be st

          • Re: (Score:2)

            by TheLink ( 130905 )
            No. It's restricted to people who can submit the correct username and password, and correct number from the keyfob, in the three fields on the bank's login form, within X minutes for when the number from the keyfob is valid.

            Alternatively, if you have a smart keyfob, you punch in your password (cached for say 5 minutes) and then out comes some new number which you then use to log in.

            There are plenty of other alternatives - ask the crypto people.

            Still you do not want to be using an untrusted computer since on

        • Re: (Score:2, Funny)

          by Mike89 ( 1006497 )

          falling for stupid fishing sites
          Yeah, somehow these places always manage to hook me with their bait.
        • "If they really wanted to add real security they'd hand out RSA key fobs to everyone instead of adding layers of stuff that makes it look more secure but actually isn't."

          Bah, all banks in the Netherlands, and most of Europe, do this. Either that or they rely on mobile devices or one time codes to do secure login and transaction authentication. If they didn't, I would switch banks. Although the security devices here are delivered by a company named Vasco. The devices are not connected to the PC as you indee
          • Are such things legislated into existence, or are the people running EU banks just that much more informed about what the real solutions are? Are there different laws for who is held accountable when money goes missing from someone's account? It seems to me like the US/Canadian banks are just trying to make things cheaper, and that, left to make their own decisions, the European banks would have the same crappy security. Is there any reason that the European banks would have something like this. Is it s

      • Re: (Score:2, Interesting)

        by Meski ( 774546 )
        When the real layer is equally insecure, how will you know you have reached it?

    • Re: (Score:1)

      by Gregb05 ( 754217 )
      This article seems to be a bit of FUD to me.
      Most of the sandboxed systems it refers to in the article are anti(virus/spyware/malware) programs. If the machine is already compromised with some malware, there's no real incentive for a virus to become active only when Symantec's VM runs across them. If it's already on the system, there's no limit to the damage a file could do through other (more direct) methods.

      Referring to a cousin comment, it's probably better for the malware to lay low when scanned rathe

      • Re: (Score:3, Insightful)

        by Miseph ( 979059 )
        Because the AV/S/M app is frequently able to obtain all sorts of wacky permissions and access, it could be viable to piggyback on it into otherwise secure systems. For example, if an AV was set up such that it could scan encrypted data, then exploiting it to get past the encryption could be feasible.
    • What you need to run, in order to overcome sandboxing, is my handy
      utility called Cats(TM). It will effectively pollute any benefits of
      sandboxing. In addition, it will spawn child processes Kittens(TM) to
      further confuse the processes.

  • Serves us right (Score:3, Funny)

    by jimbug ( 1119529 ) on Sunday July 15, 2007 @08:13PM (#19871777)
    for building a box out of sand. what were we thinking?

  • Old news (Score:4, Informative)

    by Nick_taken ( 1090721 ) on Sunday July 15, 2007 @08:18PM (#19871819)
    Theres a simple detection program called RedPill that probes a simple method to do so, vmware leaves a lot of registry keys on windows, VirtualBox lacks supports for hardware breakpoints, cpu cycles counts is another way to detect virtualization, and some packed malware dont even run on virtual machines because of memory management, software packed with armadillo do not run on vbox and it used to fail on vmware player until they fixed that bug.

    "Thwarting Virtual Machine Detection" is a nice paper on virtual machine detection.

    • Re: (Score:3, Insightful)

      by QuantumG ( 50515 )
      It's pretty trivial to find a dozen ways to detect a virtual machine, just make a project that generates some random bytes and then jump to the bytes. Put the program in a script that calls it over and over again with a seed for the random number generator. When the VM crashes, look at the last seed that was used. Run the program again with that seed to confirm it is repeatable. This also happens to be a good way to detect if your VM is any good and fix it when it isn't. Unfortunately, many things are

    • Re: (Score:2, Interesting)

      by AndroidCat ( 229562 )
      I remember when Lotus 1-2-3 had code designed to crash if was run with debug.

  • Strike vs Counterstrike (Score:5, Insightful)

    by mcrbids ( 148650 ) on Sunday July 15, 2007 @08:18PM (#19871821) Journal
    There will never, ever be an end to this.

    As long as people are imperfect (and they always will be) there will be measures, countermeasures, and counter-counter measures. New techniques will make old ones obsolete, and even newer techniques will make the once-new techniques no longer apply.

    With this understanding, any technology that can outsurvive more than one or two iterations of other products in the same field becomes "venerable" and "stable".

    Which makes now a particularly good time to appreciate the guys who worked out the spec for TCP/IP some 30 (?) years ago. Despite going from mainframes, to minis, to PCs, and now on to the era of ubiquitous computing, the basic concepts and ideas behind the TCP/IP specification continue to hold steady and useful. They managed to come up with a technology, that whatever flaws have actually been found, hasn't come up against any real show-stoppers. None.

    To which I can only say: WOW.

    • Re: (Score:2)

      by QuantumG ( 50515 )
      uhhh.. TCP hijacking is almost just as easy now as it was 10 years ago. Back then you didn't have a whole lot of switches (they were much more expensive than hubs) so you could sniff packets for other hosts easier, but the act of hijacking TCP connections is still a major flaw in the protocol. We just work around it.

      • Back then you didn't have a whole lot of switches (they were much more expensive than hubs) so you could sniff packets for other hosts easier,

        Would that really be considered a flaw in TCP/IP though? That's really Ethernet's (L2/L1) fault, TCP/UDP (Layer 4) and IP (Layer 3) aren't really involved with hubs/non-L3 switches (Layer 1 and 2 respectively).

        On another note:

        How many of the major flaws/security issues have been entirelly the fault of the protocol's specification? I honestly don't know, I usually don

        • Re: (Score:3, Insightful)

          by QuantumG ( 50515 )
          It's not about being able to sniff packets. That just makes it more applicable because, back then, you didn't need to be upstream. Today, if you're upstream of an end point you can hijack a TCP connection.

      • I thought that TCP hijacking was possible because of vulnerbilities in Sequence number generation in some TCP implementations, which have now been fixed?

      • Re:Strike vs Counterstrike (Score:4, Insightful)

        by mcrbids ( 148650 ) on Monday July 16, 2007 @03:12AM (#19873909) Journal
        TCP hijacking is almost just as easy now as it was 10 years ago.

        It may be even easier. Who cares? However you look at it, TCP is doing its job. If you want to prevent against hijacking, the layered topology of the communication stack lets you prevent that at a higher level. (EG: Using encryption - which can be interrupted, but not hijacked)

        TCP hijacking is merely a side effect of a missing layer in the stack of your application.

      • Re: (Score:2)

        by TheLink ( 130905 )
        If you can't do blind hijacking then TCP is fine and doing it's job.

        Just use SSL if you want more security. There's no point paying the extra cost of encryption when you don't need it.

        You need to do lots of extra stuff (check certs etc) if you do not want to be hijacked by MITM attacks.
    • People will start to think of sandboxes like they do fire walls. (Hay its wallz of fires! hay im no0b!)

      hahahahahahhahahahahaha

      I hate when people do that.
    • I'd have to say that's because they designed a solution that was compact, well defined, and didn't overreach and try to solve world hunger. They just designed a solution to the problem at hand. When your project starts trying to solve problems that you didn't start out to solve, that's where issues creep in. It's the /other/ downside to feature creep. Creeping features have creeping bugs. I'm a sucker for well compartmentalized and focused design.

    • Re: (Score:2)

      by Errtu76 ( 776778 )
      CS .. now WoW ... are you sure you're posting in the right thread?

    • There will never, ever be an end to this.
      It all depends on the host architecture: if it's properly engineered, then malware wouldn't even be a possibility. But as it is right now, PC operating systems are random bits of code thrown together without a clear architecture with security in mind. The overall PC architecture does not lend a hand to security.

  • Once again, they didn't read the article. (Score:5, Insightful)

    by Cafe Alpha ( 891670 ) on Sunday July 15, 2007 @08:28PM (#19871883) Journal
    The article didn't say that they've found code that attacks sandboxes, it said that they've found code that detects a sandbox (VMWare for instance) and plays innocent so as to avoid detection through the sandbox.

    It also said that software has been found that detects when it's attached to a debugger. Big deal, copy protection schemes have been doing that for decades.

    The article then goes on to FUD that code that attacks the sand box "must" be coming.

    Oh, it must be coming. Uhuh.

    • Re: (Score:2)

      by xigxag ( 167441 )
      Interesting. So is there a way to SIMULATE running in a sandbox - in terms of a simple program could be installed by Joe Idiot and use up very few cpu cycles, so that the malware would believe the system was being sandboxed and thus behave innocently?

      • Re: (Score:2)

        by TheLink ( 130905 )
        Sure that's called running stuff in a sandbox with hardware sandbox support.

        Just wait till Intel VT and AMD Pacifica improve.
    • The article didn't say that they've found code that attacks sandboxes, it said that they've found code that detects a sandbox (VMWare for instance) and plays innocent so as to avoid detection through the sandbox.

      How long before someone codes up a hack to make a real instance appear to be a sandbox so that malware will go dormant?

      LK

    • The article then goes on to FUD that code that attacks the sand box "must" be coming.

      Verbing weirds acronyms.
    • Right, but if you think about how a person would determine if software was bad...

      Imagine that an "analyst" is either not allowed to use automated tools or that s/he doesn't have any (but if s/he doesn't have any, why do this? Just bear with me...). If the analyst looks at each instruction and maps them all out, the analyst would then be able to see if the software is benevolent or malevolent. The analyst could also see if the software attempts to determine if it's running in a VM, etc.

      This is why I

  • Umm... yes? And? (Score:5, Interesting)

    by Opportunist ( 166417 ) on Sunday July 15, 2007 @08:43PM (#19871985)
    That malware detects VMs is old news. I'd wager about 60% of current malware has VM detection built in. About as many have debugger detection. Some overlapping allowed.

    So far, malware that "breaks out" of the sandbox would be new to me (though I'd be grateful for a sample). Though, seriously, why not run a VM with Windows (to analyze) on a box running Linux? I'd be very interested if someone manages to do the feat of creating a piece of malware that manages to break out of the sandbox and then run on a machine with a completely different operating system.

    If you wanna throw another stick between the malware's feet, run the VM on a non-i386 architecture. If someone manages to break out of THAT and manages to hijack my machine, he really earned it and should get it.

    • I'd wager about 60% of current malware

      Are you saying that you own over 60% of current malware?

    • why not run a VM with Windows (to analyze) on a box running Linux? I'd be very interested if someone manages to do the feat of creating a piece of malware that manages to break out of the sandbox and then run on a machine with a completely different operating system.

      you are right, the point of using virtualization is to isolate applications from one another and the host operating system, but that is not the only security feature provided by virtualization.

      the article fails to mention that most virtualiz

    • "If you wanna throw another stick between the malware's feet, run the VM on a non-i386 architecture. If someone manages to break out of THAT and manages to hijack my machine, he really earned it and should get it."

      I don't see what kind of difference this makes. It's pretty easy to compile stuff to run on multiple platforms. I don't see how it is any more difficult to break out of a virtual box running xxx and infect yyy than it is to break out of xxx and infect xxx. Much of the same VM code - including bugs
      • The tricky part is to compile malware that runs on one architecture yet has the ability to infect another architecture. Yes, it's possible. What you'd have to do is to create malware that runs on the target (host) architecture, then wrap it in code for the VM'ed architecture.

        Simply recompiling won't cut it, though. You have to roll two very heterogenous binaries into one. The lengths you'd have to go to to create something like this tell me that we'll never see more of that than a PoC.

        Malware is a business.
  • Stuff like this will make VMWare, Parallels, and others improve their product so it becomes difficult (if not impossible) to detect that the host is virtual.

    By the same token, it suggests a new attack against malware.... find out what makes a piece of malware think it's running on a VM and then make a physical machine react the same way. The possibilities are endless here.
    • Well, it isn't the point of VMWare and Parallels to ensure that it isn't detectable. A simple check of the video card driver or something else similar will show that it is indeed a virtual machine. If you wanted to build a VM that was much harder to detect, then it could be done. But instead VMWare et al have other priorities such as increasing the efficiency and adding management functions. If you have malware installed on your ESX server, then you got more issues then whether or not it can detect that

      • Re: (Score:2)

        by arminw ( 717974 )
        ........A simple check of the video card driver or something else similar will show that it is indeed a virtual machine.......

        Not if the VM is emulates the actual HARDWARE accurately. Ultimately, if the emulation software is written to behave EXACTLY the same way the hardware it is emulating, there can be no SURE way any software running under that emulator can determine whether it is running on real hardware or not. Modern microprocessors are combinations of hardware and software also. The software part is
        • Not if the VM is emulates the actual HARDWARE accurately.

          VMWare emulates the same video and sound cards. All one has to do is check for the specified hardware. Look for the hardware emulated by VMWare and if you find it, turn off certain "functionality".

          LK

          • Re: (Score:2)

            by arminw ( 717974 )
            ......All one has to do is check for the specified hardware. Look for the hardware emulated by VMWare and if you find it, turn off certain "functionality"......

            If that were done, then the real hardware in other systems would also be detected. That means if the VM emulated really popular hardware, the detector would give many false indications for the real hardware the potential malware would otherwise infect..
            • That means if the VM emulated really popular hardware, the detector would give many false indications for the real hardware the potential malware would otherwise infect..

              That's a big if. VMWare emulates less common hardware. How many people do you know who still use S3 video cards?

              LK

    • Re: (Score:2)

      by kma ( 2898 )
      Stuff like this will make VMWare, Parallels, and others improve their product so it becomes difficult (if not impossible) to detect that the host is virtual.

      Why would it be an improvement on our (I work for VMware) products to make them undetectable? To the extent that malware disables itself in the presence of a VMM, VMMs only become more attractive for production use. Not all PCs are alike, and we make no effort to hide it, and yet the world continues in peace. We don't make any effort to hide the chipse
      • I see it as an improvement in the entire virtual machine evolution. Why can't virtualized machines emulate any given set of hardware? I want to look like a P3, or a P4, or something newer? It would be nice to make random piece of hardware visible or invisible to allow the virtual machine access to hardware (or not) as desired. I'd like to ability to hide from my software that it's been virtualized.

        As to VMWare, it's a great product, I've bought it and I use it, but the way it virtualizes CD's/DVD's, USB
  • To detech VMware, it's almost trivial. VMware can be detected with a built-in backdoor. The backdoor is a configurable setting that's on a lot of times. Programs like VMware Tools use it to enhance KVM operations. An easier check would be to look on the system to see if your network driver is the VMware NIC drivers.

    "Piercing the abstraction" as they call it in the business, however, is much more difficult especially on a VM running on top of VMware's ESX, which don't actually interact with the guest OS
    • Setup a callgate, call it, the exceptions generated will be subtlety wrong. There's a lot of real weird stuff in the Intel instruction set that VMWare doesn't even try to emulate because the only OS that uses even 1% of it is OS2.

      These are so called WONTFIX bugs.. all VMs have them. There ain't enough hours in the day to worry about every nook and cranny of the x86 architecture.
  • So the little tykes are refusing to play nice in the sand box, so add some sand toys. I always wanted one of those little shovel things.

  • Question to those who sandbox (Score:1, Interesting)

    by Anonymous Coward
    Malware's built-in detection makes hell of the casual e-sleuth's investigation techniques, and there seems only one sure-fire way to make sure malware behaves as you wish; keep it on a real system. I'm mostly speaking of network-oriented malware (ie: botnet clients), where you don't really care so much about what goes on with the infected system, so much as what occurs during the control/attack phase.

    So, does anyone know of a particularly home-friendly way to handle a real-hardware box? I'm not sure of the
  • Comment removed based on user account deletion

  • Detecting virtualization? (Score:4, Funny)

    by macemoneta ( 154740 ) on Sunday July 15, 2007 @11:19PM (#19872821) Homepage
    Being able to detect virtualization would be great, if the technique can be generically applied [wikipedia.org].

    There is no spoon [wikipedia.org]

  • I've always said it, and I'll keep saying it until malware takes my baby away, but every time someone makes a smarter anti-virus, some teenager will create a better virus. It's the computer equivalent to pesticide: it kills one batch of bugs, but the next generation grows immune.

    Meanwhile, I avoid ALL forms of anti-malware tools, and magically I rarely get infected. When I do, I notice pretty quickly because I actually pay attention to what my PC is doing. If a certain task (or game) is used to running s

    • Re:Arms race for nothing (Score:4, Interesting)

      by dbIII ( 701233 ) on Monday July 16, 2007 @12:25AM (#19873193)

      Meanwhile, I avoid ALL forms of anti-malware tools, and magically I rarely get infected. When I do

      Isn't once enough for anyone? You did format and restore from a known good backup or install media afterwards didn't you? There's a tendency lately to trust that whoever had full control of your PC did nothing but run a set script and blindly hope that there is nothing else on there. I've played with various removal tools when people have given me compromised machines and different tools gave me different answers the other tools could not detect - perhaps there were some things neither could detect, hard to be sure especially when you are booting from a compromised system.

      Fdisk it from orbit - it's the only way to be sure.

      • Re:Arms race for nothing (Score:5, Insightful)

        by bmo ( 77928 ) on Monday July 16, 2007 @01:42AM (#19873549)
        "Fdisk it from orbit - it's the only way to be sure."

        Even Microsoft agrees with you. You can't "clean" a compromized machine.

        http://www.microsoft.com/technet/community/columns /secmgmt/sm0504.mspx [microsoft.com]

        That goes for other OSes too.

        --
        BMO
        • That article goes a bit too far:

          You can't clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that tell the installer lies.

          How exactly are these tools going to start running, when the system is booted to the install CD rather than the hard drive? I mean, by that logic the attacker could have tools in place to tell fdisk lies, too, so the only option is to literally incinerate the disk and buy a new one. Unless

    • If more people could self-police their PC like me, it would put a dent in both the virus and anti-virus businesses and as a result, it would slow the evolution of malware.

      Yeah, I did things that way for a long time myself. It's gotten to the point, however, at which things I trusted in the past are becoming littered with infectious software. I had no problems for years until fairly recently.

      If two kids are fighting over a silly toy, when you take away the toy, they find something else to occupy them.

      • Actually if anti-virus peddlers are "creating the market", so to speak, that makes it easier to beat them up because they get doubly hurt by each unprotected PC; they lose a victim and a customer at the same time, but talking paranoid won't help at all. It doesn't matter who writes the viruses, what matters is that there is a financial incentive to do it. If we can take away that incentive, we take away the motivation behind this underground industry.

        If McDonalds weren't making tons of money selling their
  • Ha!

    I always know there are security problems with sandboxes - and all the cats on the world surely know how to break them:
    cat /dev/colon >/proc/virtual/1
  • In MY sandbox?

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close