I stand by my statement. If a 1Ghz machine with 512MB of RAM (for example) can't run XP well, my money is going to be on some sort of hardware problem. It might be a driver issue, which could be considered an XP problem if the driver is supplied by Microsoft. System cruft, while the fault of the OS, is not really germane to the discussion. Eventually, no matter what your specs, XP will succumb to cruft.
Anecdote time. Being the token geek in my family, it almost always falls to me to troubleshoot the family's computers, even if it's an operating system that I don't use. In the case of this story, that OS was Windows XP on an old beige-box. I don't know who built the box, but it initially worked great. 2Ghz, 512MB and decent quality hardware (while working on it, I noticed that the motherboard was an Asus.) Well, eventually, it just stopped working well. Opening programs took forever, redrawing windows might take up to a minute, etc. The computer was nigh unusable. When I was alerted to the problem, my first thought was malware, however due to the absurdly poor performance, a virus scan that should have taken 30 minutes tops was still going after 24 hours.
"Linux to the rescue!" I thought. I popped in a live cd and tried to run ClamAV. The machine was still crawling, though it was doing better. At this point, I modified my diagnosis to include the possibility of a failing hard drive/IDE cable/IDE controller, as Linux had been doing just fine before it had to touch the disk. A new cable didn't help. At this point, we decided that a new disk would be a good test of this diagnosis. We backed up what we could, popped in a new drive, and tried to install Windows.
Unsurprisingly (to anyone reading this and with an inkling of where I'm going) the computer was still slow. In Linux, the symptoms persisted--it ran fine until it had to touch the disk. At this point we started switching out or disabling everything we could. We disabled all of the onboard devices that we could. We popped in a new IDE controller. We put new RAM in the machine. We even found a motherboard we could swap out (after first verifying that it was working.) No dice. The only component we couldn't replace for free was the processor, and because of this, I can only assume that it was ultimately the problem. Getting a replacement was only marginally less expensive than buying a whole new off-the-shelf PC, which was our ultimate decision.
The point, though, is that something just made that computer run dog slow. All of the hypotheses we made were sound--a bad disk can make the computer run slower (for this reason, consumer grade Western Digital disks, for example, aren't suitable for RAID--their fail mode is to retry for several seconds, locking any processes requiring that disk, and causing many RAID controllers to assume that the disk has died and drop into degraded mode.) Bad RAM could have similar effects, though it's more likely to just cause a crash. A failing component can hang the machine any time it's probed. The fact that the machine started out its life working just fine showed me that the machine was quite capable of running Windows--but by the end of its life, it simply wasn't. XP didn't change in all that time, so it truly had to be hardware.
The UAE "nag" screens are not, in principle, any different from Ubuntu's sudo pop-ups. They're more ubiquitous because of the Windows software ecosystem's DOS pedigree. DOS was not an OS, it was more like a library of system access routines. Any process could access any resource on the system and do as it pleased. Windows software tends to be designed around that assumption. Too many things ought to take administrative privileges, perhaps. Under the circumstances, where the policy was being overlaid on a large body of existing software, perhaps a more coarsely grained privilege escalation procedure would have been better, but it would be impossible to avoid excessive prompting altogether. Well "excessive" is pretty subjective.
There are a couple of schools of thought here. One is that you prompt only once per program. That's the Unix way of doing things (in general) because while it's easy to give up privileges, it's pretty hard for a process to ask for higher privileges. So Unixy programs that need to be run as root will try to do all of their administrative tasks up front (such as binding to reserved ports) and then drop their privileges so that if they get exploited, the impact is reduced.
The Vista way of doing thing is to ask for permission before every administrative action. It was awful in the release candidates--Vista couldn't correctly detect coarse actions, so moving a file to a system directory caused several prompts as, behind the scenes, several administrative actions were being performed (create file, rename file, and if moving from an administrative directory, delete file.) From the user perspective, this is one operation, but because UAC hooks in at the API level, it's triggers multiple times. To be fair, I believe that Microsoft addressed some of this in the release version, but this still showcases the fundamental difference between Vista's UAC and Ubuntu's gksudo popups.
UAC with a limited user account would be awesome. UAC on administrator accounts is just silly--if you're administrator, you shouldn't be bothered by prompts. But then, I'm coming from a Unixy background, and OEMs who provide Windows to their customers still insist on making the default user "Administrator", even though Vista has this great privilege elevation scheme.
I would have had a lot of respect for Microsoft if they'd just told software makers to suck it up and fix their broken crap. Instead, they allowed endless UAC prompts that just numb the user to warnings.
That's a pity. Vista's security model was one of the best things they had going. Sure it hurt but at some point the apps would have been forced to conform. There are a lot of good things about Vista's security model. IE's sandbox is one. UAC is good, but only in theory. It's because so many apps don't conform that it fails. Users end up either disabling UAC or quickclicking just to get past the prompt. For UAC/Vista to be effective, Vista would have had to break compatibility with a LOT of applications. That's something that Microsoft has shown, time and again, that it's unwilling to do.
Vista's mistake was the built in DRM I'm sure they got kickbacks from the media moguls to include the DRM in Vista. That, in and of itself, might be enough to make it a success. Then, consider that they're starting to get into the content delivery game. No, DRM may be the bane of consumers, but as long as Microsoft has a near-monopoly, it makes sense for them to push it.
and whatever else they did to slow the thing to a crawl even with the visual effects disabled. Some of these issues were fixed long before SP1 came out. I haven't been keeping track, so I don't know the current state, but it does seem to be something that Microsoft is working on.
Had vista simply been XP with UAC and a prettier interface I would be going out of my way right now to get as many of my friends and clients to switch as quickly as possible. Well, given my feelings on UAC, I'm exactly the opposite. If Vista had been XP++, I couldn't recommend that anyone spend money upgrading.
Besides, most of the neat features of Vista were dropped before it was released. WinFS, PC-to-PC sync, Ultimate Add-ons (which they've admitted was a failure--it was included as a feature, but virtually no add-ons have been made available since its release). In addition, useful features from Windows XP were removed from Vista! http://en.wikipedia.org/wiki/Features_removed_from_Windows_Vista Most notably missing, in my opinion, is the ability to override Autorun using the shift key.
Everyone keeps throwing around endness of machines, but they're all using different definitions.
There are three overlapping issues here: 1) Endness of a machine purchased new today. 2) Endness of a machine purchased sometime before Vista was released (if they weren't targeting at least some of these, why bother releasing an upgrade version right away?) 3) Microsoft slapping "Vista-ready" or whatever on machines not capable of running Vista in a full-featured way.
The truth is, Vista runs fine on some machines in category 2, as long as it's got enough RAM and a graphics card capable of running whatever the glitzy 3D graphics stuff is called. However, with such a broad category (machines that were purchased before Vista came out), it's hard to judge how high- or low-end the machine is, and is thus largely pointless to try to discuss that.
Vista also runs fine on low-end machines in category 2, given the caveats (I disagree that 2GB of RAM is low-end today--there are plenty of machines configured by default with only 1GB, and a smattering few configured with 512MB.)
Category 3 has to do with machines which were capable of running Vista, but not capable of running the glitzy 3D. The question is whether or not such a machine is "Vista ready." I'm not really interested in arguing on this point, but it bears mentioning since it ties in with endness.
I get so tired of the "class system" of digits-in-your-user-id around here. Honestly, low-digit Slashdotters can be as stupid, ignorant, or just have a "senior moment" as much as high-digit Slashdotters.
I think that's ultimately the problem. With traditional physical formats, competing formats eventually die off as one format rises above the rest.
With set-top media centers, it seems like everyone and his brother is making one. If all of the content is available to all of them, then it mostly doesn't matter. But once a major studio gets enough of a donation to be exclusive to one device, it's going to be all over. We'll have another HDDVD/Bluray war where half of the consumers lose.
There's a reason for having standards. DRM tends to break that.
Ok. What about a system where the captcha is presented up front with nothing else on the page. Succeed, and you get to the full registration. The page could use Javascript to rotate the captcha image periodically, expiring the previous one each time.
There are other ideas that could go along with this. You could use Javascript to send kestrokes in the captcha text box back to the server, which could then use those keystrokes to determine how soon to expire the captcha. If the user types the first letter correctly, tack on a few seconds to the captcha. Gets the second letter right? Give them a few more seconds.
Of course, I don't really know the exact mechanism that these people use to farm out the captcha, and if shortening the life of the session would even make a damned bit of difference. I could certainly see a scenario where a website steals captchas only when a user visits their site, so that timing is effectively realtime. If that was the case, coming up with a way to make it harder to automatically farm would be important.
I wonder if asking the user to execute some arbitrary bit of Javascript would be effective. A quick search doesn't turn up many good javascript engines that aren't in browsers, though surely they must exist.
I can't deny that useful code has come from the OpenBSD team. I generally don't like the idea of using commodity x86 hardware for a router/firewall, though. To me, the usefulness is just too limited. For a home connection, it's really quite a bit of overkill, and for a medium to large number of users, you run into problems servicing customers if too many small packets are coming through. I think in the tests that I've seen, you can get down to about 512 byte packets before you start seeing loss, but of course any time you have a lot of small packets coming through, you'll degrade overall performance.
For home use, a cheap router running the firmware of your choice is great. If you really need BSD, a Soekris box won't set you back to much cash. For supporting any significant number of users, I'd definitely want an appliance.
Short timeouts on the captcha and/or using javascript to generate the images might help. I don't know if it's really this bad, but many captchas I've run across virtually never expire (they might expire when the PHP session does, but I've hit a page with a captcha, gone to the restroom and to get a soda, and come back to a still-valid captcha.)
If you had a reasonable time limit in which to solve the captcha, it would certainly make it harder to farm out.
Of course, Google's captcha was broken algorithmically, wasn't it?
OpenBSD is designed with security in mind. It's so secure that you can't run anything on it! Not running anything? Nothing can be hacked!
Seriously, I used to think that OpenBSD was the bees knees, but after struggling with a broken ports system and no supported upgrade path between major versions (the latter coupled with a short support cycle means that you're having to constantly install on new metal, test, deply, and decommission the old server), I'm just not interested any longer.
Maybe the situation has improved, but based upon the maintainer's disposition, I'd doubt it.
Unfair? If it's unfair, don't use them. Nobody's forcing you to.
Yeah, I think that their fees are outrageous, too. That's why I don't sell on eBay. You can sell on Amazon (who are more up-front about their fees) or just to local shops.
I suspect that was sarcasm. You know, the same kind of mentality that causes people to complain to eBay in droves when someone sells copies of Open Office on there.
It's pretty vague in the law about how much one must offend to be considered a repeat offender, and the policy itself is left to the ISP. It sounds like Yahoo was being particularly strict here.
Education is what's needed. I disagree. The first real step is divorcing trust and the ability to run software. The truth is all the software out there should be distrusted to some degree or another. We need to let users safely run software they don't trust, and I'm not talking about just trojans. I want to run Photoshop, but I don't really trust Adobe completely and I'm not too happy when I notice it trying to connect to some random ISP in Europe. I might want to run some random attachment in my e-mail. The OS should be facilitating my desire to run it without compromising my system and data. Until it does that you're just giving users two poor choices, don't run software or run it and take a big risk. How do you propose that the user decide whether to trust certain software without education? Do most users even know that Adobe phones home, and if not, shouldn't they be able to make an informed decision as to what's going on? Windows popping up a notice that some application is trying to access the Internet isn't going to be terribly useful information.
As for education, computers are not good enough yet that a small amount of education is good enough. It takes a lot of work to safely run software you don't trust. Installing and configuring a VM, starting it, getting the installer into it, running it, saving the state or resetting the VM as is appropriate. Realistically, 99% of people are just going to take a risk instead and hope for the best. Education is great, but lets wait until we can cover everything the user needs to know to do what they want safely in an hour or so. Well, most of the education I meant was in knowing what to trust. Do you trust that file that your friend sent you? Do you know enough to know that it might not be a picture just because it looks like one? Better technical options would be nice, but you still have to know which option to choose.
Realistically, there are probably better ways for the OS to help the user practice safe computing, but education is still going to be a vital part of the equation. I like the idea of an option to let the executable run in a sandbox.
I have to say that anecdotal evidence disagrees. Having worked quite a bit with various storm binaries and submitted them to various antivirus testing sites, its mutation seems to be consistently effective.
Apache vs IIS. Now never mention the "not targeted as much because it's not as popular" theory again. Apache is clearly more secure than IIS, so the argument isn't the same, but thanks for being an ass about it in your response.
I'm arguing that Windows, OS X, and Linux are architecturally comparable with regards to security. Given that situation, it only makes sense to target the higher market share.
There are certainly enough machines out there to create multi-thousand node botnets, but I'm supposed to believe that despite holding a roughly combined 10% marketshare, they're effectively not targeted at all? It's not fair to combine the two architectures when saying that--it definitely makes the numbers look bigger. At worst, a 50/50 split, you're now talking about 5% of the market share. Does it make sense to target 5% of the population if your goal is purely market penetration?
Worse, most of those Linux machines are servers. Servers tend to be more tightly locked down than workstations. People don't tend to browse the web on servers, nor do they tend to whimsically execute software on them.
OS X has historically had a tiny market share until very recently.
The main problem is that malware can mutate so damned fast. This arbitrarily chosen website from Google's search results for "storm mutates every" suggests that it mutates every 30 minutes. It also has the advantage that it can poll for updates with an extremly high frequency. There's just no way that antivirus software can compete with this. By the time they've updated their signatures, Storm's probably mutated a dozen times.
I'm going to get the pedantic point out of the way--the OS is always what controls access to various resources. It's just that some operating systems are more permissive than others.
Now that that's done, are you seriously saying that you can't, say, open a socket to a remote host on port 25 on OS X? Or that you have to do some magical incantation that tells OS X "No really, I'm not a virus, so it's ok for me to do this!" Or that code can't execute other code via various means (fork() for example?)
I get the feeling that you're focusing solely on the part of the virus that acts like a root kit in order to hide. As I said, there are other methods that can be used to hide, and the functions are so integral to any computing experience that I simply find it impossible to believe that OS X restricts them. Simple software like Lynx and SSH would not work without these abilities.
Well, Slashdot's new commenting system ate my post. The interesting bits were:
It's not that hard to execute a file in Linux, but yes, there are extra steps that you have to take. That's more of a barrier to adoption of Linux by average users than a barrier to virues, though. The percentage infection is unlikely to be significantly different simply based upon this.
Non-native executables? Isn't that how the Vista machine in pwn-to-own was hacked--an exploit in Flash? Are you suggesting that third-party software somehow doesn't count, or that it's less likely to be vulnerable in Linux? I'm genuinely curious, as I couldn't make heads-or-tails out of your last paragraph (I tried reading it five different times.)
When I ran Windows full time (probably 4 years or so ago, it's hard to keep track) I rarely had this problem. Most software that I used doesn't require advanced privileges to run, and it's getting better every day, from what I hear.
Well, since all applications in OSX (and BSD, and most true Unix variants) need to list themselves in various tables, be individually identifyable to the OS, and have strict limits on what APIs they can access from what kind of memory space (and what kind of memory space they can occupy) This sounds like a load of gibberish designed to confuse the user into believing you.
Nothing in OS X requires that executable code ask permission from the OS before it runs. You can test this yourself by writing some code, compiling it, and executing it.
What's more difficult, as I've said all throughout the comments in this article, is hiding from the OS. That doesn't mean that the virus is trivial to remove, though. There are plenty of tricks that the virus can use to avoid automatic detection, and since we're largely talking about users who aren't likely to inspect their system thoroughly themselves, that's enough.
They'll target Apple all they want, but if there's a virus in a Mac, it will be incredibly easy to spot and remove. Getting it in there can't be by accident either, it has to come from a very complicated set of tricks, and must involve users actually permitting the infection. Most Windows malware requires that the user be tricked into running software--in fact, that's the only known way that Kraken (the subject of this article) spreads.
Slashdot Mirror
I stand by my statement. If a 1Ghz machine with 512MB of RAM (for example) can't run XP well, my money is going to be on some sort of hardware problem. It might be a driver issue, which could be considered an XP problem if the driver is supplied by Microsoft. System cruft, while the fault of the OS, is not really germane to the discussion. Eventually, no matter what your specs, XP will succumb to cruft.
Anecdote time. Being the token geek in my family, it almost always falls to me to troubleshoot the family's computers, even if it's an operating system that I don't use. In the case of this story, that OS was Windows XP on an old beige-box. I don't know who built the box, but it initially worked great. 2Ghz, 512MB and decent quality hardware (while working on it, I noticed that the motherboard was an Asus.) Well, eventually, it just stopped working well. Opening programs took forever, redrawing windows might take up to a minute, etc. The computer was nigh unusable. When I was alerted to the problem, my first thought was malware, however due to the absurdly poor performance, a virus scan that should have taken 30 minutes tops was still going after 24 hours.
"Linux to the rescue!" I thought. I popped in a live cd and tried to run ClamAV. The machine was still crawling, though it was doing better. At this point, I modified my diagnosis to include the possibility of a failing hard drive/IDE cable/IDE controller, as Linux had been doing just fine before it had to touch the disk. A new cable didn't help. At this point, we decided that a new disk would be a good test of this diagnosis. We backed up what we could, popped in a new drive, and tried to install Windows.
Unsurprisingly (to anyone reading this and with an inkling of where I'm going) the computer was still slow. In Linux, the symptoms persisted--it ran fine until it had to touch the disk. At this point we started switching out or disabling everything we could. We disabled all of the onboard devices that we could. We popped in a new IDE controller. We put new RAM in the machine. We even found a motherboard we could swap out (after first verifying that it was working.) No dice. The only component we couldn't replace for free was the processor, and because of this, I can only assume that it was ultimately the problem. Getting a replacement was only marginally less expensive than buying a whole new off-the-shelf PC, which was our ultimate decision.
The point, though, is that something just made that computer run dog slow. All of the hypotheses we made were sound--a bad disk can make the computer run slower (for this reason, consumer grade Western Digital disks, for example, aren't suitable for RAID--their fail mode is to retry for several seconds, locking any processes requiring that disk, and causing many RAID controllers to assume that the disk has died and drop into degraded mode.) Bad RAM could have similar effects, though it's more likely to just cause a crash. A failing component can hang the machine any time it's probed. The fact that the machine started out its life working just fine showed me that the machine was quite capable of running Windows--but by the end of its life, it simply wasn't. XP didn't change in all that time, so it truly had to be hardware.
There are a couple of schools of thought here. One is that you prompt only once per program. That's the Unix way of doing things (in general) because while it's easy to give up privileges, it's pretty hard for a process to ask for higher privileges. So Unixy programs that need to be run as root will try to do all of their administrative tasks up front (such as binding to reserved ports) and then drop their privileges so that if they get exploited, the impact is reduced.
The Vista way of doing thing is to ask for permission before every administrative action. It was awful in the release candidates--Vista couldn't correctly detect coarse actions, so moving a file to a system directory caused several prompts as, behind the scenes, several administrative actions were being performed (create file, rename file, and if moving from an administrative directory, delete file.) From the user perspective, this is one operation, but because UAC hooks in at the API level, it's triggers multiple times. To be fair, I believe that Microsoft addressed some of this in the release version, but this still showcases the fundamental difference between Vista's UAC and Ubuntu's gksudo popups.
UAC with a limited user account would be awesome. UAC on administrator accounts is just silly--if you're administrator, you shouldn't be bothered by prompts. But then, I'm coming from a Unixy background, and OEMs who provide Windows to their customers still insist on making the default user "Administrator", even though Vista has this great privilege elevation scheme.
I would have had a lot of respect for Microsoft if they'd just told software makers to suck it up and fix their broken crap. Instead, they allowed endless UAC prompts that just numb the user to warnings.
Besides, most of the neat features of Vista were dropped before it was released. WinFS, PC-to-PC sync, Ultimate Add-ons (which they've admitted was a failure--it was included as a feature, but virtually no add-ons have been made available since its release). In addition, useful features from Windows XP were removed from Vista! http://en.wikipedia.org/wiki/Features_removed_from_Windows_Vista Most notably missing, in my opinion, is the ability to override Autorun using the shift key.
Are these machines with lots of RAM, because that was a caveat, too.
Generally speaking, if a 3 year old machine with enough RAM can't run Windows XP, I start thinking that there's a hardware fault somewhere.
Everyone keeps throwing around endness of machines, but they're all using different definitions.
There are three overlapping issues here:
1) Endness of a machine purchased new today.
2) Endness of a machine purchased sometime before Vista was released (if they weren't targeting at least some of these, why bother releasing an upgrade version right away?)
3) Microsoft slapping "Vista-ready" or whatever on machines not capable of running Vista in a full-featured way.
The truth is, Vista runs fine on some machines in category 2, as long as it's got enough RAM and a graphics card capable of running whatever the glitzy 3D graphics stuff is called. However, with such a broad category (machines that were purchased before Vista came out), it's hard to judge how high- or low-end the machine is, and is thus largely pointless to try to discuss that.
Vista also runs fine on low-end machines in category 2, given the caveats (I disagree that 2GB of RAM is low-end today--there are plenty of machines configured by default with only 1GB, and a smattering few configured with 512MB.)
Category 3 has to do with machines which were capable of running Vista, but not capable of running the glitzy 3D. The question is whether or not such a machine is "Vista ready." I'm not really interested in arguing on this point, but it bears mentioning since it ties in with endness.
I get so tired of the "class system" of digits-in-your-user-id around here. Honestly, low-digit Slashdotters can be as stupid, ignorant, or just have a "senior moment" as much as high-digit Slashdotters.
I think that's ultimately the problem. With traditional physical formats, competing formats eventually die off as one format rises above the rest.
With set-top media centers, it seems like everyone and his brother is making one. If all of the content is available to all of them, then it mostly doesn't matter. But once a major studio gets enough of a donation to be exclusive to one device, it's going to be all over. We'll have another HDDVD/Bluray war where half of the consumers lose.
There's a reason for having standards. DRM tends to break that.
Ok. What about a system where the captcha is presented up front with nothing else on the page. Succeed, and you get to the full registration. The page could use Javascript to rotate the captcha image periodically, expiring the previous one each time.
There are other ideas that could go along with this. You could use Javascript to send kestrokes in the captcha text box back to the server, which could then use those keystrokes to determine how soon to expire the captcha. If the user types the first letter correctly, tack on a few seconds to the captcha. Gets the second letter right? Give them a few more seconds.
Of course, I don't really know the exact mechanism that these people use to farm out the captcha, and if shortening the life of the session would even make a damned bit of difference. I could certainly see a scenario where a website steals captchas only when a user visits their site, so that timing is effectively realtime. If that was the case, coming up with a way to make it harder to automatically farm would be important.
I wonder if asking the user to execute some arbitrary bit of Javascript would be effective. A quick search doesn't turn up many good javascript engines that aren't in browsers, though surely they must exist.
I can't deny that useful code has come from the OpenBSD team. I generally don't like the idea of using commodity x86 hardware for a router/firewall, though. To me, the usefulness is just too limited. For a home connection, it's really quite a bit of overkill, and for a medium to large number of users, you run into problems servicing customers if too many small packets are coming through. I think in the tests that I've seen, you can get down to about 512 byte packets before you start seeing loss, but of course any time you have a lot of small packets coming through, you'll degrade overall performance.
For home use, a cheap router running the firmware of your choice is great. If you really need BSD, a Soekris box won't set you back to much cash. For supporting any significant number of users, I'd definitely want an appliance.
Short timeouts on the captcha and/or using javascript to generate the images might help. I don't know if it's really this bad, but many captchas I've run across virtually never expire (they might expire when the PHP session does, but I've hit a page with a captcha, gone to the restroom and to get a soda, and come back to a still-valid captcha.)
If you had a reasonable time limit in which to solve the captcha, it would certainly make it harder to farm out.
Of course, Google's captcha was broken algorithmically, wasn't it?
OpenBSD is designed with security in mind. It's so secure that you can't run anything on it! Not running anything? Nothing can be hacked!
Seriously, I used to think that OpenBSD was the bees knees, but after struggling with a broken ports system and no supported upgrade path between major versions (the latter coupled with a short support cycle means that you're having to constantly install on new metal, test, deply, and decommission the old server), I'm just not interested any longer.
Maybe the situation has improved, but based upon the maintainer's disposition, I'd doubt it.
Those are certainly concerns, but that doesn't mean that you can't use Craigslist until such time as those fees become mandatory.
Unfair? If it's unfair, don't use them. Nobody's forcing you to.
Yeah, I think that their fees are outrageous, too. That's why I don't sell on eBay. You can sell on Amazon (who are more up-front about their fees) or just to local shops.
Or maybe it makes sense that such a requirement would be anticompetitive?
I suspect that was sarcasm. You know, the same kind of mentality that causes people to complain to eBay in droves when someone sells copies of Open Office on there.
It's pretty vague in the law about how much one must offend to be considered a repeat offender, and the policy itself is left to the ISP. It sounds like Yahoo was being particularly strict here.
Definitely something I'll check out. Thanks!
Realistically, there are probably better ways for the OS to help the user practice safe computing, but education is still going to be a vital part of the equation. I like the idea of an option to let the executable run in a sandbox.
I have to say that anecdotal evidence disagrees. Having worked quite a bit with various storm binaries and submitted them to various antivirus testing sites, its mutation seems to be consistently effective.
I'm arguing that Windows, OS X, and Linux are architecturally comparable with regards to security. Given that situation, it only makes sense to target the higher market share. There are certainly enough machines out there to create multi-thousand node botnets, but I'm supposed to believe that despite holding a roughly combined 10% marketshare, they're effectively not targeted at all? It's not fair to combine the two architectures when saying that--it definitely makes the numbers look bigger. At worst, a 50/50 split, you're now talking about 5% of the market share. Does it make sense to target 5% of the population if your goal is purely market penetration?
Worse, most of those Linux machines are servers. Servers tend to be more tightly locked down than workstations. People don't tend to browse the web on servers, nor do they tend to whimsically execute software on them.
OS X has historically had a tiny market share until very recently.
The main problem is that malware can mutate so damned fast. This arbitrarily chosen website from Google's search results for "storm mutates every" suggests that it mutates every 30 minutes. It also has the advantage that it can poll for updates with an extremly high frequency. There's just no way that antivirus software can compete with this. By the time they've updated their signatures, Storm's probably mutated a dozen times.
I'm going to get the pedantic point out of the way--the OS is always what controls access to various resources. It's just that some operating systems are more permissive than others.
Now that that's done, are you seriously saying that you can't, say, open a socket to a remote host on port 25 on OS X? Or that you have to do some magical incantation that tells OS X "No really, I'm not a virus, so it's ok for me to do this!" Or that code can't execute other code via various means (fork() for example?)
I get the feeling that you're focusing solely on the part of the virus that acts like a root kit in order to hide. As I said, there are other methods that can be used to hide, and the functions are so integral to any computing experience that I simply find it impossible to believe that OS X restricts them. Simple software like Lynx and SSH would not work without these abilities.
Well, Slashdot's new commenting system ate my post. The interesting bits were:
It's not that hard to execute a file in Linux, but yes, there are extra steps that you have to take. That's more of a barrier to adoption of Linux by average users than a barrier to virues, though. The percentage infection is unlikely to be significantly different simply based upon this.
Non-native executables? Isn't that how the Vista machine in pwn-to-own was hacked--an exploit in Flash? Are you suggesting that third-party software somehow doesn't count, or that it's less likely to be vulnerable in Linux? I'm genuinely curious, as I couldn't make heads-or-tails out of your last paragraph (I tried reading it five different times.)
When I ran Windows full time (probably 4 years or so ago, it's hard to keep track) I rarely had this problem. Most software that I used doesn't require advanced privileges to run, and it's getting better every day, from what I hear.
Nothing in OS X requires that executable code ask permission from the OS before it runs. You can test this yourself by writing some code, compiling it, and executing it.
What's more difficult, as I've said all throughout the comments in this article, is hiding from the OS. That doesn't mean that the virus is trivial to remove, though. There are plenty of tricks that the virus can use to avoid automatic detection, and since we're largely talking about users who aren't likely to inspect their system thoroughly themselves, that's enough. They'll target Apple all they want, but if there's a virus in a Mac, it will be incredibly easy to spot and remove. Getting it in there can't be by accident either, it has to come from a very complicated set of tricks, and must involve users actually permitting the infection. Most Windows malware requires that the user be tricked into running software--in fact, that's the only known way that Kraken (the subject of this article) spreads.