"He also talks a bit about attack trees." but doesn't discuss them thoroughly. I wish somebody would. I *really* wish there were a Web site devoted to them--something like design patterns. Perhaps powered by a Wiki.
Where they're even known about, say by people who have read Secrets and Lies (Schneir 2000), far too many developers are forced to reinvent the wheel. This hurts security in a fundamental way. All too often, they've never been heard of. I'm glad they're getting some mention, on any level.
Their biggest mistake was Itanium. Designed in Oregon, in partnership with HP (also from a US campus, but I forget where). That design effort sucked enormous resources, even for a company the size of Intel, and Intel wasn't as large, what, ten years ago? Nor was offshoring in general so common.
"Intel deserves its current course straight into the dumper. And they no longer have the technical talent to do anything great anymore; it's questionable if they have the ability to reverse the course they're on."
They're far from in the dumper. They've a large pile of cash, and revenue. Talent is on the market and available to them, even if they really did currently lack the internal talent to do anything great any more. Which I *very* seriously doubt.
"Why don't you buy a sun workstation and drop a gamer card in instead? You'll save a few hundred dollars and end up with an opteron instead of an athlon."
The parent clearly stated the need for commodity hardware and support in several countries. This is hardly a solution. It sounds as if the guy needs so support a high level of support for his app, and needs a vendor that at least arguably has the capability of 24/7 phone and mail support, short time to CE on site, etc. Sun, HP, IBM, Red Hat, Dell, etc., have support contract infrastructure to support this. Does your gaming card vendor? Also, you could end in a position where your card and systems vendors are just pointing fingers at teach other, while the system stays down. Sourcing all hardware in the system from a single vendor can have it's advantages. It's not necessarily all downside.
As skandalfo suspects, his employer "isn't the only one considering this case."
"Lamers won't buy 64 bit pcs when 32bit systems are cheap."
You might want to watch how you throw the term "lamer" about. There's no reason to pay the extra cost for 64 bit systems until you need them. Currently, their largest advantage lies in address space. Unless your application(s) needs more than 2^32 = 4GB RAM (and you're going to open your wallet for it) you could actually hurt both execution speed and the user experience in general by moving to 64 bit.
Performance: 32 bit apps quite often run *slower* on 64 bit systems, at least until rebuilt and possibly tweaked. Which the vendor might be slow to do, for any number of reasons. Not everyone is self-sustaining in the real world.
User experience (other than the above): Say you now have a 64 bit Web browser. Are all the plugins you require, likely from an assortment of vendors, all 64 bit? Or do you lose functionality? This is just one example.
I use the term 'vendor' in terms of 'whoever the software comes from'. I'm not implying anything about open- v. closed-source, free as in beer or speech, etc.
"thats true but remember there is a lot more wastage in the conversion of primary energy to electricity than there is in just piping you gas."
Agreed that this is very likely the case, as it's difficult to see how the electrons get to my place without generator and transmission losses, etc. But I see those losses as a problem for the utility providers. There's nothing I can do to directly influence anything at that level, so I can't take any ownership of the problem.
I *can* write a few letters and e-mail to the government, and I've done that much.
Mostly, I'm counting on the market to chase the power utilities into efficiency. I live in the US, and realize that this is not am entirely sane to thing to do. Yes, I'm embarrassed about that.
BTW, plugwash, did you ever get the 'security patches against the generic Linux kernel' problem sorted? It's an interesting problem.
I'd agree with the Java side of things being buggy. I see it as code tossed over the wall. Weird, since that's the side that wants to play well with enterprise (multiple OSs, wide geographic spread, etc.--the old def) computing. The last place you'd expect to see code tossed over the wall. Also (I'm a security guy) Java is supposed to be very secure, but how many Tomcat servers have been replaced due to vulnerabilities? A lot. Maybe most. Also some JVMs, which should rude us *all* out.
I don't recommend Apache 2.x to clients, unless they have pretty specific needs that would overcome some serious migration issues. These do exist, but how long was mod_perl dysfunctional in 2.x? Yeah, quite a while. I still hear of problems.
Migrating existing Perl apps was a practical impossibility for a long time, for a lot of people, unless you changed the dev environment completely. Changing to a Java environment can be an ugly thought for a lot of OSS folk. Their reasons may be religious or rational, but they are most often present. No doubt you have your own opinions about pre-fork, etc., perform on your own hardware.
I have my own lists of things I don't like about Apache 2.x, and things that are stunningly cool. I won't go into it here, as I already feel badly about the cheap-shot security dig above. You could argue that 2.x has a better security future, as it will gain steadily more eyeballs, and I'd have nothing but some weird anecdotal evidence to fight that battle with, which is usually major lossage.
The Apache 1.x versions still get things done for a lot of people. There's a lot of infrastructure already built around even deploying it. I know I have a lot of scripts written that do various things with downloading, patching, packaging, and provisioning. Certainly I want a way to reliably query a system regarding exactly what modules are installed, much less trying to parse the config file, which even an Apache developer has problems with.
Last time I looked, that was hard, compared to 1.3.x. If I need to look again, somebody slap me. I'm grinding on some server fingerprinting and management code. Doing Apache right is important, so I won't mind at all. Really. Yes, I will release the code under the GPL. You may not want it, though. It's intended to show MS shops the basics by building a basic Linux/Unix lab infrastructure.
Yes, I know this is supposed to be about the Foundation, not the Web server. IMHO, the Foundation problems arise due to management being overly involved with corporate interests.
I agree completely. I live in the northern US, and my place is small but well insulated. I've lived in this location for a long time, and a good guesstimate is that I avoid running the heating system for a couple of weeks per year, at least, just by changing some of the CFLs back to incandescent. This also tends to increase the overall intensity of the lighting. Eliminating some of that winter gloom (where I live, we could export winter gloom) tends to give me some sort of a small psychological boost as well.
However, another variable is that I'm home a lot more than most, as most of my gigs involve me being on one end of an ssh connection. Sometimes this is across multiple timezones, so I work a lot of strange night hours. Not everyone's going to get the same level of benefit, but there are probably quite a few people that might want to reinstall some of those incandescents during the winter.
cdn-programmer was right on the money when he pointed out that, "Now a standard incandecent heater (light bulb) is upwards of 90% efficient. IE - when you run your incandecent heater you leak about 10% or so of the energy in the visible spectrum while the vast majority of the energy is retained as usable heat. Much of the visible light falls on walls and floors and furniture and people and pets and most of this energy is also salvaged eventually as heat. Only that small portion which leaks out of windows is actually lost."
RFID absolutely can be a privacy risk. You might want to do some research there, Scooter. At least to the level of looking at the results of a quick Web search. WSIS is aware of the issues, and promised at the 2003 meeting that RFID would not be used at the 2005 meeting. The promise was not kept, but Stallman quite possibly travelled many thousands of miles, *at their invitation*, expecting that their promise would be kept. So who was rude?
I disagree with Stallman on several issues. This isn't one of them.
I am *not* claiming that knowing this has anything to do with being a geek, but FYI, some netstats, such as GNU's, have [-c|--continuous] [seconds]. If you don't specify a delay, it updates once per second. It's often enough to spot trivial scans.
Re:How do I set up a newsserver of my own?
on
Requiem for Usenet
·
· Score: 1
I actually thought of setting one up as a service to clients. Not to pull from an upstream provider, but just as means of providing a client-to-client discussion group for some software. I bagged the idea when I realized that better than half would have had to add firewall rules, etc., which they probably wouldn't have been willing to do.
Others, in even slightly different circumstances, might find doing this idea useful. There are several benefits that you might realize. It's still not out of the question that I might do it.
News clients with vulnerabilities. Remember how many times MS Outlook and Express have contained the means to hose you, been fixed, and had the same problems come back? That lead to mail previews needing to be turned off, etc., as standard procedure for anyone that wanted to keep their system clean(er) long(er). Both of these apps, and others, have also had problems with their News components.
More recently we've just seen this sort of thing with IM clients (AIM). Again. Web browsers, ditto. Since approximately forever.
The days of not being able to get a virus (or other malware) without a conscious effort to download and run an executable are long gone, my friend. It's the first line of defense (and an extremely good one) but it's not nearly enough.
"There is no reason for having root servers." and "Additionaly every one should be allowed to use the root servers they want."
You don't see any sort of conflict here?
. isn't just some engineering convenience. It's how dupes are avoided at the DNS request level. Sure you can replicate the DNS database. If your willing to either lose built in synchronization, or add delays in when changes to it become available to DNS requests from users.
You will also introduce some huge security issues. Hint: why is allowing zone transfers from your DNS server considered something to control?
"Additionaly every one should be allowed to use the root servers they want." again: There's nothing technical in the way of using whatever . you want to, right now. The reasons it's not done as a practical matter is pretty well summarized in what I've said above.
Britain used to be queen of the seas and control 25% of the world's land area. For a brief period in history. Then it all fell apart in a very short period of time. Maintaining great success on the world stage is also an issue. I'm perfectly willing to admit that how long the US will remain successful at this is an open question.
But to reduce something this complex to "...the reason for your power is plain, dumb luck. You were in the right place at the right time." is simplistic thinking.
I'm not Britain- or UK-bashing here. The four non-US Web sites I visit regularly are all.uk news sites (BBC, Timesonline, Guardian, Register). The UK is certainly (though too slowly) influencing us for the better in the important beer realm. I've worked fairly closely with some Brit security guy counterparts. In general terms, I'm a UK fan.
Yuck. Well, at least many of the more popular extensions get at least some degree of user testing, for whatever that's worth. Not too much, IMHO. That's nearly always a far better test for functionality than security.
When I had to keep one Win machine in my cube I tried to keep the extension count to a minimum. I also had to run some other things I wasn't too comfortable with, but luckily I also had to have a Linux machine for development work. So I used that for connecting to the Unix machines, where security was most important (large closed-source Unix servers, Checkpoint Firewall-1, which ran on a stripped OpenBSD, etc.).
This definitely wasn't an environment where you'd want to risk having a keylogger installed.
Obviously, anything that went to the cloud was done from that Linux machine as well. We had lots of people running Win getting various bits of spyware, etc., installed, giving the MIS folk problems to chase. I never had a problem.
You would not believe the problems I had with their support for Enterprise backup in a mixed HP-UX/Win environment, a couple of years ago. And for a while, I get getting the same guy at HP-UX support, on several issues, who was absolutely useless. I think about half of those calls ended up in escalation. Some other times, they were just freaking outstanding. These were both max support contracts, BTW.
Just goes to show that anyone can have a string of bad experiences with any vendor, I guess.
Everything I've seen says that all communication involving your newly-hosed machine is outgoing--the phone home bit. I'm not aware of anyone having found any way that Sony employees or any automated Sony software can gain remote admin access. In fact, the EULA says that *you* have to keep the software updated, not that you had to allow Sony to do it remotely. Though it *is* tough to have any faith in that EULA, I'd think that if any listener had been found (particularly if it circumvented XP's SP2 firewall, and it would need that capability to be at all reliable, unless it used something like IRC) the hue and cry would rightfully have been even greater.
I haven't seen anything about the phone-home capability being anything beyond reporting (which is quite sufficiently horrible, by itself). Going further than this would be pretty extreme, even given what Sony's already done. Remember the furor over MS software activation, and phoning home? MS never attempted to delete pirated software, etc. I suspect they'd love to have done it. But the consequences of a coding error leading to failure to recognize a valid product key, or something of that nature, would have been huge. I'm thinking it's probably the same with Sony. If you are anyone has evidence to the contrary, I hope it gets out to a very large audience, ASAP.
Or perhaps you were referring to the botnet reference I made? If so, that's about spam-borne malware that joins the #sony channel on one of five hardcoded IRC servers. It's not something from Sony. It's just random Bad Guys leveraging Sony's, er, well, 'error' doesn't quite cover something of this magnitude.
So far as this being on Windows v. Unix/Linux, I think the generic term 'rootkit' is good enough. No complaints there. 'Adminkit' sounds a bit hokey.
What does concern me is that rootkits are relatively new in the Win world, having gotten their start in the Unix world. While they're rapidly moving into the Win world, they're still less common. Certainly this is the largest splash they've made in the popular press, and it isn't even a rootkit!
Given that relative newness, Win people are likely to have less experience with what actually constitutes a rootkit, the exact nature of the threat, best defense practices, etc. The way to start the learning process is *not* with an incorrect definition what that the thing even *is*.
Starting like that would seem a good way to end up with two different, mutually exclusive definitions, making life that much tougher for security folk who already have quite a bit on their plates. If you're not part of that world, you would not believe how many hours go into trying to keep up with all the research papers, security alerts, white papers written in vendor-speak (these guys often attempt to redefine things on the fly), etc.
You are correct. It is not a rootkit. But not for the reason you stated. If it makes you feel any better, icydog and bluGill didn't get it right, either. The term is from Unix, and I'm a Unix/Linux security guy, so I'm going to stay in that context: what rootkit really means.
Say you've just rooted a system. In order, you want to 1) hide your presence, and 2) make sure you have a way back in if 1) fails.
To hide your presence, you do things like clean log files, and install Trojaned versions of various system tools, such as the 'ps' process lister and the 'ls' file lister. Maybe you don't stop with Trojans. Maybe you load kernel modules, and hook system calls. That isn't a requirement for a rootkit, though. It's a technique. Nor is it a requirement to include a replication mechanism, which would tend to give you away. This isn't a worm, it's a means of hiding yourself and maintaining access.
What you do on the system is then up to you. Maybe you're attempting to compromise other systems, but that's not a requirement, either. Maybe you only wanted this machine because it has huge disk capacity or something. Maybe you don't want it for anything at the moment, and are just checking it's resources and their usage patterns, to determine how you might best employ it in future, without revealing yourself.
Specific attack tools, etc., are not part of the definition, though you definitely have a means of hiding them. Or pretty much anything else. You have a way back in if the original security vulnerability is patched.
You are now the worst nightmare of many sysadmins of business and government installations (hosts + network). Many of these guys would actually much rather you did launch a worm or something. Then you're findable.
It gets much deeper than this (it's a career in itself)--but the two requirements are those above. Sony's DRM software didn't provide a way back in. It was a screwup of epic proportions, and the first piece of mallware (Backdoor.IRC.Synd.A) known to be leveraging it was found in a spam message on the 9th.
But that's an IRC backdoor, meaning the system will most likely become part of a Botnet. Again, easier to find. And, again, that remote access component is not part of Sony's DRM screwup.
I one or another/. post about this, someone recommended double-quoting rootkit. He or she was dead-on.
Maybe not in the US, under this administration, but a probe has been ordered in Italy. See my post above.
Italian criminal probe requested
on
Bad Day To Be Sony
·
· Score: 5, Informative
It's widely published that legal actions have begun in California, New York, and Italy. The Italian situation is not just some class-action lawsuit. A complaint was filed with a criminal investigation unit last Friday.
"The complaint alleges that XCP violates a number of Italy's computer security laws by causing damage to users' systems and by acting in the same way as malicious software, according to Andrea Monti, chairman of the ALCEI-EFI. "What Sony did qualifies as a criminal offense under Italian law," he said in an e-mail interview.
Should police determine that a crime has been committed, prosecutors will be required to begin criminal proceedings against Sony, Monti said."
Re:PS3? No thanks, Sony; you screwed the pooch
on
Bad Day To Be Sony
·
· Score: 1
" If Microsoft had engineered an operating system with the maximum security that allowed for performance and basically stayed out of the users way, this wouldn't be a problem."
They didn't even have to design for maximum security. In this case, they only needed to avoid doing something as brain damaged as basing Active-X security on code signing.
Criminal prosecution? I hope you're not counting on a Bush administration Department of Justice. Maybe Massachusetts, or one of the other hold-out states from the antitrust case. Of course, many of those Attorneys General are probably out of office by now.
Slashdot Mirror
Can the rumors be true? Is CowboyNeal really Rupert Murdoch?
On a more serious note, you might have a look at http://www.outfoxed.org/
"He also talks a bit about attack trees." but doesn't discuss them thoroughly. I wish somebody would. I *really* wish there were a Web site devoted to them--something like design patterns. Perhaps powered by a Wiki.
Where they're even known about, say by people who have read Secrets and Lies (Schneir 2000), far too many developers are forced to reinvent the wheel. This hurts security in a fundamental way. All too often, they've never been heard of. I'm glad they're getting some mention, on any level.
Their biggest mistake was Itanium. Designed in Oregon, in partnership with HP (also from a US campus, but I forget where). That design effort sucked enormous resources, even for a company the size of Intel, and Intel wasn't as large, what, ten years ago? Nor was offshoring in general so common.
"Intel deserves its current course straight into the dumper. And they no longer have the technical talent to do anything great anymore; it's questionable if they have the ability to reverse the course they're on."
They're far from in the dumper. They've a large pile of cash, and revenue. Talent is on the market and available to them, even if they really did currently lack the internal talent to do anything great any more. Which I *very* seriously doubt.
"Why don't you buy a sun workstation and drop a gamer card in instead? You'll save a few hundred dollars and end up with an opteron instead of an athlon."
The parent clearly stated the need for commodity hardware and support in several countries. This is hardly a solution. It sounds as if the guy needs so support a high level of support for his app, and needs a vendor that at least arguably has the capability of 24/7 phone and mail support, short time to CE on site, etc. Sun, HP, IBM, Red Hat, Dell, etc., have support contract infrastructure to support this. Does your gaming card vendor? Also, you could end in a position where your card and systems vendors are just pointing fingers at teach other, while the system stays down. Sourcing all hardware in the system from a single vendor can have it's advantages. It's not necessarily all downside.
As skandalfo suspects, his employer "isn't the only one considering this case."
"Lamers won't buy 64 bit pcs when 32bit systems are cheap."
You might want to watch how you throw the term "lamer" about. There's no reason to pay the extra cost for 64 bit systems until you need them. Currently, their largest advantage lies in address space. Unless your application(s) needs more than 2^32 = 4GB RAM (and you're going to open your wallet for it) you could actually hurt both execution speed and the user experience in general by moving to 64 bit.
Performance: 32 bit apps quite often run *slower* on 64 bit systems, at least until rebuilt and possibly tweaked. Which the vendor might be slow to do, for any number of reasons. Not everyone is self-sustaining in the real world.
User experience (other than the above): Say you now have a 64 bit Web browser. Are all the plugins you require, likely from an assortment of vendors, all 64 bit? Or do you lose functionality? This is just one example.
I use the term 'vendor' in terms of 'whoever the software comes from'. I'm not implying anything about open- v. closed-source, free as in beer or speech, etc.
"thats true but remember there is a lot more wastage in the conversion of primary energy to electricity than there is in just piping you gas."
Agreed that this is very likely the case, as it's difficult to see how the electrons get to my place without generator and transmission losses, etc. But I see those losses as a problem for the utility providers. There's nothing I can do to directly influence anything at that level, so I can't take any ownership of the problem.
I *can* write a few letters and e-mail to the government, and I've done that much.
Mostly, I'm counting on the market to chase the power utilities into efficiency. I live in the US, and realize that this is not am entirely sane to thing to do. Yes, I'm embarrassed about that.
BTW, plugwash, did you ever get the 'security patches against the generic Linux kernel' problem sorted? It's an interesting problem.
I'd agree with the Java side of things being buggy. I see it as code tossed over the wall. Weird, since that's the side that wants to play well with enterprise (multiple OSs, wide geographic spread, etc.--the old def) computing. The last place you'd expect to see code tossed over the wall. Also (I'm a security guy) Java is supposed to be very secure, but how many Tomcat servers have been replaced due to vulnerabilities? A lot. Maybe most. Also some JVMs, which should rude us *all* out.
I don't recommend Apache 2.x to clients, unless they have pretty specific needs that would overcome some serious migration issues. These do exist, but how long was mod_perl dysfunctional in 2.x? Yeah, quite a while. I still hear of problems.
Migrating existing Perl apps was a practical impossibility for a long time, for a lot of people, unless you changed the dev environment completely. Changing to a Java environment can be an ugly thought for a lot of OSS folk. Their reasons may be religious or rational, but they are most often present. No doubt you have your own opinions about pre-fork, etc., perform on your own hardware.
I have my own lists of things I don't like about Apache 2.x, and things that are stunningly cool. I won't go into it here, as I already feel badly about the cheap-shot security dig above. You could argue that 2.x has a better security future, as it will gain steadily more eyeballs, and I'd have nothing but some weird anecdotal evidence to fight that battle with, which is usually major lossage.
The Apache 1.x versions still get things done for a lot of people. There's a lot of infrastructure already built around even deploying it. I know I have a lot of scripts written that do various things with downloading, patching, packaging, and provisioning. Certainly I want a way to reliably query a system regarding exactly what modules are installed, much less trying to parse the config file, which even an Apache developer has problems with.
Last time I looked, that was hard, compared to 1.3.x. If I need to look again, somebody slap me. I'm grinding on some server fingerprinting and management code. Doing Apache right is important, so I won't mind at all. Really. Yes, I will release the code under the GPL. You may not want it, though. It's intended to show MS shops the basics by building a basic Linux/Unix lab infrastructure.
Yes, I know this is supposed to be about the Foundation, not the Web server. IMHO, the Foundation problems arise due to management being overly involved with corporate interests.
I agree completely. I live in the northern US, and my place is small but well insulated. I've lived in this location for a long time, and a good guesstimate is that I avoid running the heating system for a couple of weeks per year, at least, just by changing some of the CFLs back to incandescent. This also tends to increase the overall intensity of the lighting. Eliminating some of that winter gloom (where I live, we could export winter gloom) tends to give me some sort of a small psychological boost as well.
However, another variable is that I'm home a lot more than most, as most of my gigs involve me being on one end of an ssh connection. Sometimes this is across multiple timezones, so I work a lot of strange night hours. Not everyone's going to get the same level of benefit, but there are probably quite a few people that might want to reinstall some of those incandescents during the winter.
cdn-programmer was right on the money when he pointed out that, "Now a standard incandecent heater (light bulb) is upwards of 90% efficient. IE - when you run your incandecent heater you leak about 10% or so of the energy in the visible spectrum while the vast majority of the energy is retained as usable heat. Much of the visible light falls on walls and floors and furniture and people and pets and most of this energy is also salvaged eventually as heat. Only that small portion which leaks out of windows is actually lost."
RFID absolutely can be a privacy risk. You might want to do some research there, Scooter. At least to the level of looking at the results of a quick Web search. WSIS is aware of the issues, and promised at the 2003 meeting that RFID would not be used at the 2005 meeting. The promise was not kept, but Stallman quite possibly travelled many thousands of miles, *at their invitation*, expecting that their promise would be kept. So who was rude?
I disagree with Stallman on several issues. This isn't one of them.
I am *not* claiming that knowing this has anything to do with being a geek, but FYI, some netstats, such as GNU's, have [-c|--continuous] [seconds]. If you don't specify a delay, it updates once per second. It's often enough to spot trivial scans.
Please mod parent up.
I actually thought of setting one up as a service to clients. Not to pull from an upstream provider, but just as means of providing a client-to-client discussion group for some software. I bagged the idea when I realized that better than half would have had to add firewall rules, etc., which they probably wouldn't have been willing to do.
Others, in even slightly different circumstances, might find doing this idea useful. There are several benefits that you might realize. It's still not out of the question that I might do it.
News clients with vulnerabilities. Remember how many times MS Outlook and Express have contained the means to hose you, been fixed, and had the same problems come back? That lead to mail previews needing to be turned off, etc., as standard procedure for anyone that wanted to keep their system clean(er) long(er). Both of these apps, and others, have also had problems with their News components.
More recently we've just seen this sort of thing with IM clients (AIM). Again. Web browsers, ditto. Since approximately forever.
The days of not being able to get a virus (or other malware) without a conscious
effort to download and run an executable are long gone, my friend. It's the first line of defense (and an extremely good one) but it's not nearly enough.
Just wear the thong over the jeans.
"There is no reason for having root servers." and "Additionaly every one should be allowed to use the root servers they want."
You don't see any sort of conflict here?
. isn't just some engineering convenience. It's how dupes are avoided at the DNS request level. Sure you can replicate the DNS database. If your willing to either lose built in synchronization, or add delays in when changes to it become available to DNS requests from users.
You will also introduce some huge security issues. Hint: why is allowing zone transfers from your DNS server considered something to control?
"Additionaly every one should be allowed to use the root servers they want." again: There's nothing technical in the way of using whatever . you want to, right now. The reasons it's not done as a practical matter is pretty well summarized in what I've said above.
Britain used to be queen of the seas and control 25% of the world's land area. For a brief period in history. Then it all fell apart in a very short period of time. Maintaining great success on the world stage is also an issue. I'm perfectly willing to admit that how long the US will remain successful at this is an open question.
.uk news sites (BBC, Timesonline, Guardian, Register). The UK is certainly (though too slowly) influencing us for the better in the important beer realm. I've worked fairly closely with some Brit security guy counterparts. In general terms, I'm a UK fan.
But to reduce something this complex to "...the reason for your power is plain, dumb luck. You were in the right place at the right time." is simplistic thinking.
I'm not Britain- or UK-bashing here. The four non-US Web sites I visit regularly are all
Damn you, meringuoid, now you've given Microsoft the idea!
Yuck. Well, at least many of the more popular extensions get at least some degree of user testing, for whatever that's worth. Not too much, IMHO. That's nearly always a far better test for functionality than security.
When I had to keep one Win machine in my cube I tried to keep the extension count to a minimum. I also had to run some other things I wasn't too comfortable with, but luckily I also had to have a Linux machine for development work. So I used that for connecting to the Unix machines, where security was most important (large closed-source Unix servers, Checkpoint Firewall-1, which ran on a stripped OpenBSD, etc.).
This definitely wasn't an environment where you'd want to risk having a keylogger installed.
Obviously, anything that went to the cloud was done from that Linux machine as well. We had lots of people running Win getting various bits of spyware, etc., installed, giving the MIS folk problems to chase. I never had a problem.
Veritas?!
You would not believe the problems I had with their support for Enterprise backup in a mixed HP-UX/Win environment, a couple of years ago. And for a while, I get getting the same guy at HP-UX support, on several issues, who was absolutely useless. I think about half of those calls ended up in escalation. Some other times, they were just freaking outstanding. These were both max support contracts, BTW.
Just goes to show that anyone can have a string of bad experiences with any vendor, I guess.
Everything I've seen says that all communication involving your newly-hosed machine is outgoing--the phone home bit. I'm not aware of anyone having found any way that Sony employees or any automated Sony software can gain remote admin access. In fact, the EULA says that *you* have to keep the software updated, not that you had to allow Sony to do it remotely. Though it *is* tough to have any faith in that EULA, I'd think that if any listener had been found (particularly if it circumvented XP's SP2 firewall, and it would need that capability to be at all reliable, unless it used something like IRC) the hue and cry would rightfully have been even greater.
I haven't seen anything about the phone-home capability being anything beyond reporting (which is quite sufficiently horrible, by itself). Going further than this would be pretty extreme, even given what Sony's already done. Remember the furor over MS software activation, and phoning home? MS never attempted to delete pirated software, etc. I suspect they'd love to have done it. But the consequences of a coding error leading to failure to recognize a valid product key, or something of that nature, would have been huge. I'm thinking it's probably the same with Sony. If you are anyone has evidence to the contrary, I hope it gets out to a very large audience, ASAP.
Or perhaps you were referring to the botnet reference I made? If so, that's about spam-borne malware that joins the #sony channel on one of five hardcoded IRC servers. It's not something from Sony. It's just random Bad Guys leveraging Sony's, er, well, 'error' doesn't quite cover something of this magnitude.
So far as this being on Windows v. Unix/Linux, I think the generic term 'rootkit' is good enough. No complaints there. 'Adminkit' sounds a bit hokey.
What does concern me is that rootkits are relatively new in the Win world, having gotten their start in the Unix world. While they're rapidly moving into the Win world, they're still less common. Certainly this is the largest splash they've made in the popular press, and it isn't even a rootkit!
Given that relative newness, Win people are likely to have less experience with what actually constitutes a rootkit, the exact nature of the threat, best defense practices, etc. The way to start the learning process is *not* with an incorrect definition what that the thing even *is*.
Starting like that would seem a good way to end up with two different, mutually exclusive definitions, making life that much tougher for security folk who already have quite a bit on their plates. If you're not part of that world, you would not believe how many hours go into trying to keep up with all the research papers, security alerts, white papers written in vendor-speak (these guys often attempt to redefine things on the fly), etc.
Confusion over terms is the last thing we need.
You are correct. It is not a rootkit. But not for the reason you stated. If it makes you feel any better, icydog and bluGill didn't get it right, either. The term is from Unix, and I'm a Unix/Linux security guy, so I'm going to stay in that context: what rootkit really means.
/. post about this, someone recommended double-quoting rootkit. He or she was dead-on.
Say you've just rooted a system. In order, you want to 1) hide your presence, and 2) make sure you have a way back in if 1) fails.
To hide your presence, you do things like clean log files, and install Trojaned versions of various system tools, such as the 'ps' process lister and the 'ls' file lister. Maybe you don't stop with Trojans. Maybe you load kernel modules, and hook system calls. That isn't a requirement for a rootkit, though. It's a technique. Nor is it a requirement to include a replication mechanism, which would tend to give you away. This isn't a worm, it's a means of hiding yourself and maintaining access.
What you do on the system is then up to you. Maybe you're attempting to compromise other systems, but that's not a requirement, either. Maybe you only wanted this machine because it has huge disk capacity or something. Maybe you don't want it for anything at the moment, and are just checking it's resources and their usage patterns, to determine how you might best employ it in future, without revealing yourself.
Specific attack tools, etc., are not part of the definition, though you definitely have a means of hiding them. Or pretty much anything else. You have a way back in if the original security vulnerability is patched.
You are now the worst nightmare of many sysadmins of business and government installations (hosts + network). Many of these guys would actually much rather you did launch a worm or something. Then you're findable.
It gets much deeper than this (it's a career in itself)--but the two requirements are those above. Sony's DRM software didn't provide a way back in. It was a screwup of epic proportions, and the first piece of mallware (Backdoor.IRC.Synd.A) known to be leveraging it was found in a spam message on the 9th.
But that's an IRC backdoor, meaning the system will most likely become part of a Botnet. Again, easier to find. And, again, that remote access component is not part of Sony's DRM screwup.
I one or another
Maybe not in the US, under this administration, but a probe has been ordered in Italy. See my post above.
It's widely published that legal actions have begun in California, New York, and Italy. The Italian situation is not just some class-action lawsuit. A complaint was filed with a criminal investigation unit last Friday.
i ty/story/0,10801,106064,00.html?source=NLT_PM&nid= 106064
"The complaint alleges that XCP violates a number of Italy's computer security laws by causing damage to users' systems and by acting in the same way as malicious software, according to Andrea Monti, chairman of the ALCEI-EFI. "What Sony did qualifies as a criminal offense under Italian law," he said in an e-mail interview.
Should police determine that a crime has been committed, prosecutors will be required to begin criminal proceedings against Sony, Monti said."
Sony has declined to comment.
From:
http://www.computerworld.com/securitytopics/secur
" If Microsoft had engineered an operating system with the maximum security that allowed for performance and basically stayed out of the users way, this wouldn't be a problem."
They didn't even have to design for maximum security. In this case, they only needed to avoid doing something as brain damaged as basing Active-X security on code signing.
Criminal prosecution? I hope you're not counting on a Bush administration Department of Justice. Maybe Massachusetts, or one of the other hold-out states from the antitrust case. Of course, many of those Attorneys General are probably out of office by now.
That's OK, there are enough scum sucking lawyers out there to cover both bases. :)