I've got an ITS system that I occasionally fire up in an emulator if I'm feeling really retro. I don't actually use it for anything, though.
There are a number of people at my workplace who still use their old SymbolicsLISP Machines on a daily basis. They swear that there has never been a better development environment, and that it's really a tragedy that lispms failed in the marketplace.
You do realize this argument assumes that people like Fyodor will never, ever, ever find a way around this particular problem?
Possibly, but the basis of our entire crypto system relies on very similar assumptions. If we were too worried that maybe somebody somewhere someday might think of a way to find a shortcut for something that today is considered very hard, we'd have problems much bigger than worrying about how much time it takes to map a LAN.
You also realize this argument depends on IPv6 addresses being assigned in a non-predictable manner?
Not really. Even if you can predict what the next valid IP address might be, there's no guarantee that there's anything listening on that address. The current standard for IPv6 address autoconfiguration on Ethernet right now bases the host component of an address on the interfaces's MAC address. That might make things a little bit easier to predict, since certain ranges of MAC addresses are reserved or otherwise unused, but there's still a ton of address space to be scanned.
Or, to put this a differently, I've seen how long it takes a scanner to walk through an IPv4/16. A/64 is a whole lot bigger no matter how you look at it.
Doesn't matter if your router supports IPv6 if your ISP does not.
Sure it does. The whole point, and what makes it so cool, is that the AirPort sets up 6-to-4 tunnelling automatically. So you *can* have IPv6 connectivity even if your ISP doesn't provide it.
I don't know. I've had a Chumby since they first became available, and I've never seen an add or anything else that I didn't explicitly request.
It's awfully nice to have a nice little (ntp-synched!) alarm clock that can also display news headlines, weather, etc. I wish it had a good browser, though. Maybe it does at this point.
I completely agree that it was a horrible decision on Kurt's part. No matter what, you don't go mucking in the random number generator code of a crypto library unless you're really sure you know what you're doing. IMO Kurt also screwed up by committing the fix to the public Debian openssl svn repository before it was publicly announced. Debian, Ubuntu, and others were still trying to assess the impact of the problem at that point, and weren't ready to publish it. I was surprised by this, as I've dealt with Kurt in the past regarding embargoed security issues and found him to be very responsible and thorough.
No, he posted a question openssl-dev, which is a mailing list for people writing software that uses OpenSSL
Incorrect, no matter what Ben claims. According to http://www.openssl.org/support/, openssl-dev is for the developers of openssl itself. To quote the list description:
Discussions on development of the OpenSSL library. Not for application development questions!
So yes, perhaps Kurt could have been more explicit in his description of what he was trying to do, but he was definitely using the appropriate address to reach the developers.
Imagine if Microsoft reserved the right to modify any software for Windows in any way it saw fit! Yet that's exactly what Debian (and Fedora and Mandrake and Ubuntu) said to me - they reserve the right to make any modifications they like to the software they ship, and if upstream don't like it, tough luck.
It's true; the building is broken by design. I do work in the Stata Center, and it is as bad as everyone says it is.
All these wonderful posts make me want to resurrect the stata-haters mailing list that somebody set up when we first moved in. Maybe at this point we could get some of the higher up MIT executives to join, now that they've seen the light and started hating the building along with us poor souls who have to try to work in it.
Comcast is in many different cities - each office running independently of all others. Which offices are blocking bittorrent? I use it all the time, on Comcast, without any trouble. I have more issues at work (with traffic shaping junk) than Comcast. So, I do not see how this is a company-wide problem. It may be something only used in problematic areas.
My experience is comparable to this. I downloaded a CentOS DVD image via bittorrent over my Boston-area Comcast connection the other night and was rather surprised at just how quick it was. Well over 10 Mb/s, with no apparent interruptions. I don't doubt that some machine or even human at Comcast's NOC noticed that I was using bittorrent, but they didn't do anything about. But, of course, "the plural of anecdote is not data". This was just my rather limited experience. Maybe next time I try to download an ISO image, it'll fail mysteriously...
Hmm. It occurs to me that there is another cable ISP in the area, and DSL is available. Maybe they're actually afraid of competition. I wonder if my experiences would be different if Comcast had an effective monopoly on the market in this area.
so for those on the network, the internet2 network sort of works as if it were part of the regular internet backbone? does that mean p2p between two people from different universities on the network could go across internet2? hmm...
Yes, barring local policies restricting such traffic, all IP travelling between major US academic and research sites goes over I2 automatically, without the users ever needing to know it. Given that it typically costs a whole lot less to send traffic over I2 than over a commercial link, it's pretty uncommon to come across a site that restricts I2 traffic.
Here's a traceroute from a random box at MIT to Cal Tech's web server. Note the hostnames of the various intermediate hops:
lore:~$ traceroute www.caltech.edu traceroute to www.caltech.edu (131.215.220.4), 30 hops max, 52 byte packets 1 misc-2-3.haven.csail.mit.edu (128.30.28.4) 0.493 ms 0.269 ms 0.240 ms 2 haven.trantor.csail.mit.edu (128.30.0.253) 0.368 ms 0.303 ms 0.240 ms 3 B24-RTR-2-CSAIL.MIT.EDU (18.4.7.1) 0.366 ms 0.325 ms 0.241 ms 4 EXTERNAL-RTR-1-BACKBONE.MIT.EDU (18.168.0.18) 0.616 ms 42.011 ms 0.717 ms 5 EXTERNAL-RTR-2-BACKBONE.MIT.EDU (18.168.0.27) 0.992 ms 2.902 ms 2.988 ms 6 207.210.143.109 (207.210.143.109) 0.835 ms 0.973 ms 0.606 ms 7 nox300gw1-Vl-803-NoX.nox.org (192.5.89.238) 0.745 ms 0.889 ms 0.616 ms 8 nox300gw1-PEER-NoX-INTERNET2-192-5-89-222.nox.org (192.5.89.222) 8.361 ms 5.694 ms 6.110 ms 9 so-0-0-0.0.rtr.wash.net.internet2.edu (64.57.28.11) 10.733 ms 10.868 ms 11.358 ms 10 so-0-0-0.0.rtr.atla.net.internet2.edu (64.57.28.6) 24.975 ms 24.662 ms 43.963 ms 11 hstnng-atlang.abilene.ucaid.edu (198.32.8.33) 45.840 ms 46.525 ms 45.713 ms 12 losang-hstnng.abilene.ucaid.edu (198.32.8.21) 82.692 ms 77.419 ms 77.820 ms 13 hpr-lax-gsr1--abilene-LA-10ge.cenic.net (137.164.25.2) 78.441 ms 77.683 ms 77.943 ms 14 lax-hpr.losnettos-hpr.cenic.net (137.164.27.246) 77.820 ms 77.857 ms 77.818 ms 15 Booth-RSW.ilan.caltech.edu (131.215.254.253) 77.818 ms 77.888 ms 77.819 ms 16 walt.caltech.edu (131.215.220.2) 78.818 ms 77.912 ms 77.815 ms
Wouldn't it be pretty trivial to
cp/mnt/cdrom/md5/sbin/
each night before running the tool? Or, as someone else suggested, leave md5 on with another name? I'm sure most rootkits wouldn't notice if 'zsh' was actually a copy of 'md5.'
Yes, it would be trivial. Unfortunately, it wouldn't do you much good these days. Modern rootkits (on Windows, Linux, what have you), are kernel based. It doesn't matter how trusted your md5, ls, ps, and other binaries are if your kernel is not reporting accurate information.
Look the main thing is whether a vendor/source gets it right or not.
Definitely. There are open source projects that get it very wrong (mozilla is actually a good example of one) and proprietary vendors who get it right (just take a look at Sun's patch sets).
The reality is there's a lot of software out there, you must be amazing if you can generate your own custom security patches you need for all the software that needs fixing.
No, I'm not amazing, but the open source community really is. Where I think open source is really better is that, even if the upstream developer gets it wrong, there's a whole community of people whose shared resources can go a long way toward isolating the necessary changes for a security fix in an otherwise large and potentially undocumented source code patch. This happens all the time within the vendor-sec mailing list, where most notable open source operating system vendors collaborate to isolate, identify, and patch specific security problems in open source software. I don't need to do all the work myself, I have lots of help.
It's easier to just test the patched stuff first (and/or use the workarounds and wait a brief while for OTHERS to use the patched stuff first) and cope with the mess if stuff passes the tests but doesn't pass real use - which should be rare.
Fortunately, the providers of most of the software I need to support disagree with you. nVidia is a notable exception, and I find that unfortunate. There will be no peer review of their security fix, no ports of the fix to other versions of their code, and no chance to look for similar coding errors elsewhere in their code.
So I really don't see how your "patch source, install rebuilt packages" method is superior to "install packages that someone else built" in terms of "not going to break anything".
What you are saying sounds quite ridiculous actually - you are confident you aren't going to break anything just because it's a "simple patch" to open source... As if open source is some kind of magic that miraculously prevents anything from breaking.
You completely misunderstood what I'm saying. I don't claim that all security fixes are "simple patches" with open source. I'm saying that I can apply a patch that only provides the security fix if I choose to do that. With open source, I have the ability to apply the security fix to whatever version of the software I'm running, because I have the freedom to examine and study both the source and the patch. I'm not forced to install a new version of the software, complete with a new list of features, maybe some API changes, maybe some other bug fixes, maybe some new optimizations, all of which are quite likely to break compatibility with existing software.
If what I'm saying sounds so rediculous, then why do nearly all OSS distrubutors (linux distributions, *BSD, etc) do exactly that? Why did Ubuntu put the effort into fixing the security problems in OpenSSL 0.9.7e for CVE-2006-2940 in Ubuntu 5.04 when they could have simply released the upstream version 0.7.9l? They did this because they are releasing a security update to an existing version of their software, not a new version of their software that just happens to fix security problems that existed in an older version.
The only difference supposedly is that the fix could be faster if it's opensource. BUT even that's not guaranteed - not that many people understand the big picture enough to make a decent fix
It's not just about timeliness. It's also about releasing a security fix that can (at least in theory) be ported to other versions of the software. nVidia is claiming that version 9.625 of their Linux drivers fix the problem. Well, that's great, but I really don't want to upgrade the several hundred workstations that I'm responsible for to a new driver. Ideally, I would apply a simple patch to the source I'm currently using, built updated packages, and install them, restarting X where necessary. I can do that and be fairly confident that I'm not going to break anything. Certainly I would be more confident than I will be when I push out 9.625. As an enterprise customer, this sort of thing is important to me, and it's exactly this sort of thing that makes me prefer open source.
Their other option was to stop patching the hell out of Firefox and do what every other distro does - get with the program.
Get with the program? Are you serious? Should we not patch Linux either? How 'bout X?
You should read Matthew Garrett's recent blog entry about why it's a good thing (for the Mozilla Corp, Debian, and the user community at large) for Debian (or anybody else) to be allowed to distribute patches. http://mjg59.livejournal.com/68112.html
Also, you should probably read this post to the Fedora devel list that shows that Mozilla's trademark policies are a real problem not just for Debian but for other distributors as well.
I don't know about Debian, but FreeBSD didn't issue an advisory until the day after this went public. We have a very strict policy about making sure that security updates won't break anything, and OpenSSL's original patch was broken and not fixed until a day later.
It wasn't really per se, but it did contain some unnecessary code. None of it was major, and I don't think it would have caused any problems, but the revised patch, which we in Debian also used, touched fewer files and was generally simpler.
Wow, that was like almost a month ago. All the major, and most of the minor, OS vendors and Linux distributors have long since announced released fixes. Why's it on slashdot now?
It also needs to be noted that the impact of this bug is not nearly as wide as a slashdot front-page headline might suggest. The FreeBSD security advisory has some good info on why. To quote: (emphasis mine)
RSA public keys may use a variety of public exponents, of which 3, 17, and
65537 are most common. As a result of a number of known attacks, most keys
generated recently use a public exponent of at least 65537. ...
OpenSSL will incorrectly report some invalid signatures as valid. When
an RSA public exponent of 3 is used, or more generally when a small public
exponent is used with a relatively large modulus (e.g., a public exponent
of 17 with a 4096-bit modulus), an attacker can construct a signature which
OpenSSL will accept as a valid PKCS#1 v1.5 signature.
So yeah, there may be some vulnerable sites out there, but they were already weaker than they should have been, and most sites are likely unaffected. That, coupled with the simplicity of the fix (both as provided in source form and from the OS vendors) makes this a non-story.
As good as the Debian security team is, they are frankly terrible with the kernel.
The servers compromised, in both cases, were not running kernels supported by the debian security team. The Debian sysadmin people typically roll their own kernels for use on Debian.org machines. In fact, had the default stable kernel been used, the machine would not have been vulnerable to this exploit. See http://lists.debian.org/debian-news/debian-news-20 06/msg00030.html for more info. (In short, 2.6.8 is not vulnerable.) The compomised server was running a custom 2.6.16.18 kernel, and was thus vulnerable. It has since been upgraded to a custom 2.6.17.4 kernel. If you're going to knock anybody in this case, knock the Debian sysadmins for not keeping up with security on their own machines, or for having policies in place that allow weak passwords to lead to any kind of access. But don't knock the Debian security team.
The Debian security team has fixed 98 kernel security bugs since sarge was first released. Refer to changelogs for the kernel-source-2.6.8 versions 4sarge1, 4sarge2, and 4sarge3 for details if you need them. What more do you want?
No, American football and baseball have constant breaks because the advertisers demand it (and the owners are only interested in profit). Americans have been conditioned to see regular commercial breaks as acceptable or even desirable. No matter what baseball fanatics say, it's not like there's anything to 'digest' about some no-hoper batter being caught out, and it shouldn't take five minutes for the next man to come up to bat.
I disagree. Both of those games (baseball, more so) existed and thrived long before television advertisers were around to care. While the breaks are certainly convenient for advertisers, and the advertisers are forcing more and more advertisement into shorter breaks, the games were most certainly not designed with television advertisement in mind.
Note how the most popular televised sport plays for 45 minutes without any breaks. I don't see fans complaining that they didn't stop after 20 minutes for analysis, replays and commercials.
Sure, but this game is hardly popular in the US. These gaming tournaments are largely (almost entirely?) going after US audiences. My original point, that online gaming is simply not watchable for most US viewers, still stands. Additionally, in soccer the action is around the ball. That's not the case in most video games, meaning that soccer is easier to watch than video games, and is still not popular in the US.
Televised gaming might get off the ground if they designed a game from scratch to be suitable for TV. Not some FPS where you can see less than 1% of the playing area at one time, and the enemies are cartoon monsters.
Maybe. But none of the major televised sports were designed for TV, so why do the televised video games need to be? What I think will happen, eventually, is that some creative mind will come up with a competitive game that's really fun to play and just happens to also be fun to watch. I don't know what it will look like, and I'm not even sure if it'll be an FPS.
I just think it's too early. You just don't have the momentum that sports competition has. Even though gaming has broad appeal, the fact is that for most people, watching someone else play a videogame is about as exciting as watching the dog take a shit on the lawn. That will change eventually, it really can be entertaining, but people just aren't used to it yet. You can't have a professional gaming league without money, and you can't have money without sponsors, and you can't have sponsors without interest.
I think part of it also has to do with exactly how people watch these various events. Constant action is desirable in gaming, but viewers want breaks for analysis, replays, commentary, etc. Look at how baseball and American football are presented on TV. There's some action, then there's a pause that gives time for the viewers to digest and enjoy what they've seen, aided by whole mess of commentary and slow motion replays. Somehow there needs to be a bridge to keep gaming interesting for both spectators and players. I'm not sure what that bridge looks like. I can't imagine how to keep CTF or Onslaught (the two UT2004 modes I play the most) interesting for viewers. They're too fast-paced and there's action all over the place.
Sure, but in doing so you're taking a risk that the thing you're removing really is that worm, and not some mutation with some shared symptoms, or potentially even something much nastier that deliberately masquerades as a well-known worm to make you think you're safe. If you're system's been compromised, how do you know you're really dealing with what you think you're dealing with?
My point was that, while the risk has alwasy been present, it has grown over the past couple of years due to more sophisticated techniques for hiding and with greater incentive to do so. Cleaning up an infected machine takes more time and skill, and is often not worth it, while a few years ago it may have been more reasonable.
You could never recover a compromised system reliably anyway. Once someone's got through your security to a certain level, you can't trust anything - including security tools and diagnostic information - that runs at that level or above. For a typical desktop PC or office server, that basically means you can't trust anything left on the system.
Sort of, but not always. Worms and other automated tools get a lot of scrutiny and are pretty well understood in terms of what they do to your system. If you keep up with the latest info on a given piece of malware, you know how to remove it. Where you can't assume anything is the case where something more devious than a simple worm breaks in. These are the more common cases now that we have people building for-profit botnets. They've got a financial incentive to stay hidden and they try very hard to do it. It used to be that the common Windows worm was easy to clean up. That's no longer the case, and that's basically the gist of this article.
Slashdot Mirror
I've got an ITS system that I occasionally fire up in an emulator if I'm feeling really retro. I don't actually use it for anything, though.
There are a number of people at my workplace who still use their old Symbolics LISP Machines on a daily basis. They swear that there has never been a better development environment, and that it's really a tragedy that lispms failed in the marketplace.
noah
You do realize this argument assumes that people like Fyodor will never, ever, ever find a way around this particular problem?
Possibly, but the basis of our entire crypto system relies on very similar assumptions. If we were too worried that maybe somebody somewhere someday might think of a way to find a shortcut for something that today is considered very hard, we'd have problems much bigger than worrying about how much time it takes to map a LAN.
You also realize this argument depends on IPv6 addresses being assigned in a non-predictable manner?
Not really. Even if you can predict what the next valid IP address might be, there's no guarantee that there's anything listening on that address. The current standard for IPv6 address autoconfiguration on Ethernet right now bases the host component of an address on the interfaces's MAC address. That might make things a little bit easier to predict, since certain ranges of MAC addresses are reserved or otherwise unused, but there's still a ton of address space to be scanned.
Or, to put this a differently, I've seen how long it takes a scanner to walk through an IPv4 /16. A /64 is a whole lot bigger no matter how you look at it.
noah
Doesn't matter if your router supports IPv6 if your ISP does not.
Sure it does. The whole point, and what makes it so cool, is that the AirPort sets up 6-to-4 tunnelling automatically. So you *can* have IPv6 connectivity even if your ISP doesn't provide it.
noah
It's awfully nice to have a nice little (ntp-synched!) alarm clock that can also display news headlines, weather, etc. I wish it had a good browser, though. Maybe it does at this point.
noah
noah
Incorrect, no matter what Ben claims. According to http://www.openssl.org/support/, openssl-dev is for the developers of openssl itself. To quote the list description: Discussions on development of the OpenSSL library. Not for application development questions!
So yes, perhaps Kurt could have been more explicit in his description of what he was trying to do, but he was definitely using the appropriate address to reach the developers.
noah
Though, as has been pointed out elsewhere, the Debian package maintainer did raise this issue with the openssl developers, and was basically told "go ahead, it's OK."
The DSA contains a link to http://security.debian.org/project/extra/dowkd/dowkd.pl.gz, which can examine an ssh authorized_keys file (among other things) and let you know which, if any, keys are weak.
All these wonderful posts make me want to resurrect the stata-haters mailing list that somebody set up when we first moved in. Maybe at this point we could get some of the higher up MIT executives to join, now that they've seen the light and started hating the building along with us poor souls who have to try to work in it.
noah
My experience is comparable to this. I downloaded a CentOS DVD image via bittorrent over my Boston-area Comcast connection the other night and was rather surprised at just how quick it was. Well over 10 Mb/s, with no apparent interruptions. I don't doubt that some machine or even human at Comcast's NOC noticed that I was using bittorrent, but they didn't do anything about. But, of course, "the plural of anecdote is not data". This was just my rather limited experience. Maybe next time I try to download an ISO image, it'll fail mysteriously...
Hmm. It occurs to me that there is another cable ISP in the area, and DSL is available. Maybe they're actually afraid of competition. I wonder if my experiences would be different if Comcast had an effective monopoly on the market in this area.
noah
so for those on the network, the internet2 network sort of works as if it were part of the regular internet backbone? does that mean p2p between two people from different universities on the network could go across internet2? hmm...
Yes, barring local policies restricting such traffic, all IP travelling between major US academic and research sites goes over I2 automatically, without the users ever needing to know it. Given that it typically costs a whole lot less to send traffic over I2 than over a commercial link, it's pretty uncommon to come across a site that restricts I2 traffic.
Here's a traceroute from a random box at MIT to Cal Tech's web server. Note the hostnames of the various intermediate hops:
noahhttp://web.mit.edu/admissions/
http://www.admissions.caltech.edu/
http://www.stanford.edu/dept/uga/
and the list goes on...
cp
each night before running the tool? Or, as someone else suggested, leave md5 on with another name? I'm sure most rootkits wouldn't notice if 'zsh' was actually a copy of 'md5.'
Yes, it would be trivial. Unfortunately, it wouldn't do you much good these days. Modern rootkits (on Windows, Linux, what have you), are kernel based. It doesn't matter how trusted your md5, ls, ps, and other binaries are if your kernel is not reporting accurate information.
See e.g. http://www.la-samhna.de/library/rootkits/index.htm l for example.
noah
# mount -o remount,rw /readonly/partition
So that won't help you...
You could also built a monolithic kernel and not allow modules at all. Kind of hard to insert a corrupt module if the kernel isn't modular!
That won't help either: http://doc.bughunter.net/rootkit-backdoor/kmem-pat ching.html Most modern kernel-level rootkits do not depend on the ability to dynamically load modules.
noah
Definitely. There are open source projects that get it very wrong (mozilla is actually a good example of one) and proprietary vendors who get it right (just take a look at Sun's patch sets).
The reality is there's a lot of software out there, you must be amazing if you can generate your own custom security patches you need for all the software that needs fixing.
No, I'm not amazing, but the open source community really is. Where I think open source is really better is that, even if the upstream developer gets it wrong, there's a whole community of people whose shared resources can go a long way toward isolating the necessary changes for a security fix in an otherwise large and potentially undocumented source code patch. This happens all the time within the vendor-sec mailing list, where most notable open source operating system vendors collaborate to isolate, identify, and patch specific security problems in open source software. I don't need to do all the work myself, I have lots of help.
It's easier to just test the patched stuff first (and/or use the workarounds and wait a brief while for OTHERS to use the patched stuff first) and cope with the mess if stuff passes the tests but doesn't pass real use - which should be rare.
Fortunately, the providers of most of the software I need to support disagree with you. nVidia is a notable exception, and I find that unfortunate. There will be no peer review of their security fix, no ports of the fix to other versions of their code, and no chance to look for similar coding errors elsewhere in their code.
noah
What you are saying sounds quite ridiculous actually - you are confident you aren't going to break anything just because it's a "simple patch" to open source... As if open source is some kind of magic that miraculously prevents anything from breaking.
You completely misunderstood what I'm saying. I don't claim that all security fixes are "simple patches" with open source. I'm saying that I can apply a patch that only provides the security fix if I choose to do that. With open source, I have the ability to apply the security fix to whatever version of the software I'm running, because I have the freedom to examine and study both the source and the patch. I'm not forced to install a new version of the software, complete with a new list of features, maybe some API changes, maybe some other bug fixes, maybe some new optimizations, all of which are quite likely to break compatibility with existing software.
If what I'm saying sounds so rediculous, then why do nearly all OSS distrubutors (linux distributions, *BSD, etc) do exactly that? Why did Ubuntu put the effort into fixing the security problems in OpenSSL 0.9.7e for CVE-2006-2940 in Ubuntu 5.04 when they could have simply released the upstream version 0.7.9l? They did this because they are releasing a security update to an existing version of their software, not a new version of their software that just happens to fix security problems that existed in an older version.
noah
It's not just about timeliness. It's also about releasing a security fix that can (at least in theory) be ported to other versions of the software. nVidia is claiming that version 9.625 of their Linux drivers fix the problem. Well, that's great, but I really don't want to upgrade the several hundred workstations that I'm responsible for to a new driver. Ideally, I would apply a simple patch to the source I'm currently using, built updated packages, and install them, restarting X where necessary. I can do that and be fairly confident that I'm not going to break anything. Certainly I would be more confident than I will be when I push out 9.625. As an enterprise customer, this sort of thing is important to me, and it's exactly this sort of thing that makes me prefer open source.
noah
Get with the program? Are you serious? Should we not patch Linux either? How 'bout X?
You should read Matthew Garrett's recent blog entry about why it's a good thing (for the Mozilla Corp, Debian, and the user community at large) for Debian (or anybody else) to be allowed to distribute patches. http://mjg59.livejournal.com/68112.html
Also, you should probably read this post to the Fedora devel list that shows that Mozilla's trademark policies are a real problem not just for Debian but for other distributors as well.
noah
It wasn't really per se, but it did contain some unnecessary code. None of it was major, and I don't think it would have caused any problems, but the revised patch, which we in Debian also used, touched fewer files and was generally simpler.
noah
It also needs to be noted that the impact of this bug is not nearly as wide as a slashdot front-page headline might suggest. The FreeBSD security advisory has some good info on why. To quote: (emphasis mine)
So yeah, there may be some vulnerable sites out there, but they were already weaker than they should have been, and most sites are likely unaffected. That, coupled with the simplicity of the fix (both as provided in source form and from the OS vendors) makes this a non-story.
noah
The servers compromised, in both cases, were not running kernels supported by the debian security team. The Debian sysadmin people typically roll their own kernels for use on Debian.org machines. In fact, had the default stable kernel been used, the machine would not have been vulnerable to this exploit. See http://lists.debian.org/debian-news/debian-news-20 06/msg00030.html for more info. (In short, 2.6.8 is not vulnerable.) The compomised server was running a custom 2.6.16.18 kernel, and was thus vulnerable. It has since been upgraded to a custom 2.6.17.4 kernel. If you're going to knock anybody in this case, knock the Debian sysadmins for not keeping up with security on their own machines, or for having policies in place that allow weak passwords to lead to any kind of access. But don't knock the Debian security team.
The Debian security team has fixed 98 kernel security bugs since sarge was first released. Refer to changelogs for the kernel-source-2.6.8 versions 4sarge1, 4sarge2, and 4sarge3 for details if you need them. What more do you want?
noah
I disagree. Both of those games (baseball, more so) existed and thrived long before television advertisers were around to care. While the breaks are certainly convenient for advertisers, and the advertisers are forcing more and more advertisement into shorter breaks, the games were most certainly not designed with television advertisement in mind.
Note how the most popular televised sport plays for 45 minutes without any breaks. I don't see fans complaining that they didn't stop after 20 minutes for analysis, replays and commercials.
Sure, but this game is hardly popular in the US. These gaming tournaments are largely (almost entirely?) going after US audiences. My original point, that online gaming is simply not watchable for most US viewers, still stands. Additionally, in soccer the action is around the ball. That's not the case in most video games, meaning that soccer is easier to watch than video games, and is still not popular in the US.
Televised gaming might get off the ground if they designed a game from scratch to be suitable for TV. Not some FPS where you can see less than 1% of the playing area at one time, and the enemies are cartoon monsters.
Maybe. But none of the major televised sports were designed for TV, so why do the televised video games need to be? What I think will happen, eventually, is that some creative mind will come up with a competitive game that's really fun to play and just happens to also be fun to watch. I don't know what it will look like, and I'm not even sure if it'll be an FPS.
noah
I think part of it also has to do with exactly how people watch these various events. Constant action is desirable in gaming, but viewers want breaks for analysis, replays, commentary, etc. Look at how baseball and American football are presented on TV. There's some action, then there's a pause that gives time for the viewers to digest and enjoy what they've seen, aided by whole mess of commentary and slow motion replays. Somehow there needs to be a bridge to keep gaming interesting for both spectators and players. I'm not sure what that bridge looks like. I can't imagine how to keep CTF or Onslaught (the two UT2004 modes I play the most) interesting for viewers. They're too fast-paced and there's action all over the place.
noah
My point was that, while the risk has alwasy been present, it has grown over the past couple of years due to more sophisticated techniques for hiding and with greater incentive to do so. Cleaning up an infected machine takes more time and skill, and is often not worth it, while a few years ago it may have been more reasonable.
noah
Sort of, but not always. Worms and other automated tools get a lot of scrutiny and are pretty well understood in terms of what they do to your system. If you keep up with the latest info on a given piece of malware, you know how to remove it. Where you can't assume anything is the case where something more devious than a simple worm breaks in. These are the more common cases now that we have people building for-profit botnets. They've got a financial incentive to stay hidden and they try very hard to do it. It used to be that the common Windows worm was easy to clean up. That's no longer the case, and that's basically the gist of this article.
noah