The most often heard scream I'm aware of is the "sound of ultimate suffering" from The Princess Bride. I've heard it in dozens of movies, and in South Park (every time a scene in Hell begins).
Example: Free Software developers produce a high quality computing platform, and sell it for profit. Proprietary development company decides that the competition is eroding their sales, takes this product, and adds some sort of compatibility layer for their proprietary software. Perhaps this is the ability to run software in their scripting language on this platform. Their implementation remains proprietary. They begin marketing this new platform, advertising that it has all of the features and stability of your Free Software platform, plus the ability to run a number of proprietary applications. The proprietary company has not had to pay for development of the base platform, so they sell their product for less than the Free Software developers. The market, seeing no advantage to the Free Software distribution, buys from the proprietary company. The Free Software developers don't make money, and their distribution eventually fails to gain significant market share. As they fade into obscurity, the proprietary development company weens customers off of the no-longer-successful platform based on Free Software, and on to their proprietary platform (or not, doesn't matter to the Free Software developers who haven't got any money), where customers can continue running their applications.
The Free Software developers have lost. Customers have lost. It is the nature of some people to pursue immediate benefit above long-term benefit. These people exist in the market, and vote with their dollars. Their tendency toward immediate benefit hurts the ecology of the market.
"Max" was definitely harsh, but he's not entirely out of line. cd9660.util *is* a SUID binary, and one would expect educated developers to take that into account and carefully validate any and all input. It's just what you *do* in a SUID program.
This type of attack is nothing new, and this vulnerability may be an indication that security isn't being taken seriously.
So... Darwin users/developers. Does this problem affect the open source Darwin? Just how many SUID binaries do you find on Darwin?
The potential for exploit doesn't require you to insert a CD. It may be exploitable by command line arguments. If so, then there may be a vector for an attacker to begin privilege escalation if he can achieve access to a local account, in which case this would present a full root vulnerability to a remote user.
What qualifies the password file as brain damage? It's not that different from LDAP support on Linux and Unix systems. On those, LDAP will be used before/etc/passwd. The passwd file is just a fallback for uids only defined locally, or when LDAP is down.
Where can a long time Linux user find documentation on Solaris? I'd really love to find something that compared solaris administration functions to, say, Red Hat functions.
I've set up a Solaris box or two, and was horribly confused by the init system. Not because I don't understand how it works, but because I refuse to believe that sun doesn't include a tool to manage that horrible abomination. All the same, I couldn't find one.
I'd also like some sort of reference for the services that are started by default. There are a lot of them, and their names do not help anyone figure out what they're for. I'm almost as worried that they're required for normal system operation as I am that they're a security risk.
Seems like IBM had a working version of this technology when they released SASH in Oct. '99. Given IBM's patenting practices, I wonder who got to this patent first?
Installation time, not counting file downloads which don't require my intervention anyways, is on the order of 20 minutes or less
You won't be disappointed by anaconda. My install times are generally < 5 minutes when I do a network based install.
but many are assuming a GUI interface is preferred.
This "assumption" is only true if 1) you install X, which you don't have to 2) you're installing locally, using CD's. If you're setting up servers, you're probably going to use kickstart to do a network based install. X is one of the most common interfaces to Unix systems. It's ridiculous to pretend that an installer that doesn't configure X is ready for mass consumption. Ready for use by network system admins, sure. That's about as far as it'd get...
And it's cross platform too!
So's anaconda.
There are advantages with this, but there are always disadvantages to a homogeneous environment.
Uh... generally when people talk about the disadvantages to a homogenous environment, they're talking about security issues that come up when all of the members of the environment have the same vulnerabilities. Can you name one disadvantage to a complete, easy to use installer that's consistant across hardware platforms and distributions? Nothing comes to my mind....
the ascii-codes are 230, 248 and 229 for small letters, and 198, 216 and 197 for capitals.
ASCII only covers 7 bit values. Those are the decimal values of an encoding other than ASCII.
Most likely, slashdot has chosen not to support non-ASCII text because there's no context that conveys what non-ASCII encoding they're actually in. The only way that slashdot can fix this, and remain readable to everyone, would be to allow characters that compose valid UTF-8 stings to be included in posts. Your character codes "230, 248 and 229" would not be allowed. However, "303 246", "305 223", and "303 245" would.
it seems to me to make more sense to have the distro maintainer run his/her own CA and issue certs to package maintainers...No mucking about with the web 'o trust
What makes you think there's a difference between x509 keys signing additional x509 keys (which is how a CA issues certs) and a GPG key signing additional GPG keys?
Everyone here knows if windowsupdate.microsoft.com had been compromised
Don't remember specifically which worm compromised that system, but I know that the windowsupdate systems were definitely affected by one of the worms during the last year.
You know what's funnier than that? I have *never*, not once, been to a presentation where an MS representative was demoing some new piece of MS software and not seen at least one BSOD.
Seems like there's always some guy in the back that yells "IT'S NOT A BUG, IT'S A FEATURE", too.
Three down, eight to go (Debian installs on *11* architectures).
My point was simply that anaconda IS cross platform. It would be easier to add support for a new achitecture to the existing modular software than to write a new system from scratch.
the article explained why the existing efforts weren't good enough for Debian's purposes
And those reasons didn't convince me that this was worthwhile. It reeked of NIH. All of the requirements listed were provided by several other installers that are available and GPL licensed.
Stability, in terms of having a consistant platform for an extended period of time, is worth a lot. This is particularly true when you've got a limited staff trying to support hundreds of terminals around a large campus. Distributions that you can "download for free" don't offer the guaranteed, extended lifetime that you're going to get from RHEL. At least, not with continuing security updates.
Is it just me, or does the Debian project as a whole seem to have the nastiest case of NIH ever?
Lets see... installer needs to work on multiple architectures. Anaconda is used on all of PPC (Yellowdog), x86, s390. I think that's good evidence that it fits the bill.
Installer should to work on everything from serial cable to graphical interfaces. I've used anaconda on RLX blades with a serial interface, and my workstations with graphical interfaces.
Installer should handle CDROM, HTTP, FTP, NFS, hard drive sources for the install media. Yep, anaconda does those.
And furthermore, the idea that "nobody has more expertise in porting software to different platforms than the Debian project" is pompous and ludicrous. I don't have to say anything other than "NetBSD" as an answer to that.
Red Hat's employees have commented that when they seriously thought about joining the Debian project when they were planning the future of their hobbyist/developer distribution, but decided that it probably wouldn't work out. Articles like this remind me why.
I seriously doubt that the Debian team even looked at the available GPL licensed installers before deciding to write their own from scratch.
I don't have the same degree of confidence that the "developer community" will have the resources (time, machines and testing methodology) to maintain the same level of quality
If I were to guess, I'd say you've never run Debian, and never known anyone who has.
To that, I'll add that Red Hat will continue to be involved in the QA process for Fedora Core releases. Their Enterprise offering is going to be based on these releases, and they'd have a hell of a time convincing customers that they can base a good stable product on a distribution that sucks.
You may be reading too much in to the statements on the Fedora site. For instance, the fact that there's no support from the company might seem frightening, but that's been the case with Red Hat Linux for several years now. The Enterprise line is the only one with commercial support available.
The fact that Fedora will incorporate new technology before Enterprise does does not mean that Fedora will be beta-level software. It means that Enterprise is a much slower moving platform, for the benefit of application vendors like Oracle. Fedora will continue to go through all of the QA that Red Hat Linux ever was. (ntp 4.2 was removed from the distro, in favor of 4.1 because 4.2 wasn't working. Just like you'd expect).
You might choose to switch to Mandrake. That decision is up to you. I'd do so slowly, though, and with plenty of testing. I've never really heard great things about Mandrake's stability.
My plan for the time being is to continue using RHL 7.3 (as we have for some time), with support from FedoraLegacy. If that group needs manpower, I'll probably end up involving myself to make sure that we get the support for our servers that we need. We'll continue that for as long as it takes for Fedora Core to prove itself, or to fail to do so. I expect the former, but maintain plans in case of the latter.
I don't really know how popular this digest authentication is
Not very. It only works if your server has a plaintext equivalent of your password. It's useless if you're authenticating against LDAP, for instance. Usually you'll end up using Basic authentication (plain text password) over SSL.
Slashdot Mirror
The most often heard scream I'm aware of is the "sound of ultimate suffering" from The Princess Bride. I've heard it in dozens of movies, and in South Park (every time a scene in Hell begins).
You could also drop the length checks entirely, and stat the file indicated by the arg. If it's a block device, the arg is valid.
How could it be used against them?
Example: Free Software developers produce a high quality computing platform, and sell it for profit. Proprietary development company decides that the competition is eroding their sales, takes this product, and adds some sort of compatibility layer for their proprietary software. Perhaps this is the ability to run software in their scripting language on this platform. Their implementation remains proprietary. They begin marketing this new platform, advertising that it has all of the features and stability of your Free Software platform, plus the ability to run a number of proprietary applications. The proprietary company has not had to pay for development of the base platform, so they sell their product for less than the Free Software developers. The market, seeing no advantage to the Free Software distribution, buys from the proprietary company. The Free Software developers don't make money, and their distribution eventually fails to gain significant market share. As they fade into obscurity, the proprietary development company weens customers off of the no-longer-successful platform based on Free Software, and on to their proprietary platform (or not, doesn't matter to the Free Software developers who haven't got any money), where customers can continue running their applications.
The Free Software developers have lost. Customers have lost. It is the nature of some people to pursue immediate benefit above long-term benefit. These people exist in the market, and vote with their dollars. Their tendency toward immediate benefit hurts the ecology of the market.
"Max" was definitely harsh, but he's not entirely out of line. cd9660.util *is* a SUID binary, and one would expect educated developers to take that into account and carefully validate any and all input. It's just what you *do* in a SUID program.
This type of attack is nothing new, and this vulnerability may be an indication that security isn't being taken seriously.
So... Darwin users/developers. Does this problem affect the open source Darwin? Just how many SUID binaries do you find on Darwin?
The potential for exploit doesn't require you to insert a CD. It may be exploitable by command line arguments. If so, then there may be a vector for an attacker to begin privilege escalation if he can achieve access to a local account, in which case this would present a full root vulnerability to a remote user.
What qualifies the password file as brain damage? It's not that different from LDAP support on Linux and Unix systems. On those, LDAP will be used before /etc/passwd. The passwd file is just a fallback for uids only defined locally, or when LDAP is down.
Where can a long time Linux user find documentation on Solaris? I'd really love to find something that compared solaris administration functions to, say, Red Hat functions.
I've set up a Solaris box or two, and was horribly confused by the init system. Not because I don't understand how it works, but because I refuse to believe that sun doesn't include a tool to manage that horrible abomination. All the same, I couldn't find one.
I'd also like some sort of reference for the services that are started by default. There are a lot of them, and their names do not help anyone figure out what they're for. I'm almost as worried that they're required for normal system operation as I am that they're a security risk.
Seems like IBM had a working version of this technology when they released SASH in Oct. '99. Given IBM's patenting practices, I wonder who got to this patent first?
xfsdump is definitely smarter because of DMAPI, and is safe to use on live filesystems.
Maybe a hybrid of Anaconda + dselect would be nice, if rolled into 1
Anaconda does dependency resolution. So does "up2date". The current version of up2date also supports apt and yum repositories. There you go...
If there were a bug in Debian's installer, would you ask the Debian team to provide you with a fix, or would you install Red Hat Linux?
Tell me again how it helps to have a variety of installers.
Installation time, not counting file downloads which don't require my intervention anyways, is on the order of 20 minutes or less
You won't be disappointed by anaconda. My install times are generally < 5 minutes when I do a network based install.
but many are assuming a GUI interface is preferred.
This "assumption" is only true if 1) you install X, which you don't have to 2) you're installing locally, using CD's. If you're setting up servers, you're probably going to use kickstart to do a network based install. X is one of the most common interfaces to Unix systems. It's ridiculous to pretend that an installer that doesn't configure X is ready for mass consumption. Ready for use by network system admins, sure. That's about as far as it'd get...
And it's cross platform too!
So's anaconda.
There are advantages with this, but there are always disadvantages to a homogeneous environment.
Uh... generally when people talk about the disadvantages to a homogenous environment, they're talking about security issues that come up when all of the members of the environment have the same vulnerabilities. Can you name one disadvantage to a complete, easy to use installer that's consistant across hardware platforms and distributions? Nothing comes to my mind....
the ascii-codes are 230, 248 and 229 for small letters, and 198, 216 and 197 for capitals.
ASCII only covers 7 bit values. Those are the decimal values of an encoding other than ASCII.
Most likely, slashdot has chosen not to support non-ASCII text because there's no context that conveys what non-ASCII encoding they're actually in. The only way that slashdot can fix this, and remain readable to everyone, would be to allow characters that compose valid UTF-8 stings to be included in posts. Your character codes "230, 248 and 229" would not be allowed. However, "303 246", "305 223", and "303 245" would.
it seems to me to make more sense to have the distro maintainer run his/her own CA and issue certs to package maintainers...No mucking about with the web 'o trust
What makes you think there's a difference between x509 keys signing additional x509 keys (which is how a CA issues certs) and a GPG key signing additional GPG keys?
Everyone here knows if windowsupdate.microsoft.com had been compromised
Don't remember specifically which worm compromised that system, but I know that the windowsupdate systems were definitely affected by one of the worms during the last year.
You know what's funnier than that? I have *never*, not once, been to a presentation where an MS representative was demoing some new piece of MS software and not seen at least one BSOD.
Seems like there's always some guy in the back that yells "IT'S NOT A BUG, IT'S A FEATURE", too.
Three down, eight to go (Debian installs on *11* architectures).
My point was simply that anaconda IS cross platform. It would be easier to add support for a new achitecture to the existing modular software than to write a new system from scratch.
the article explained why the existing efforts weren't good enough for Debian's purposes
And those reasons didn't convince me that this was worthwhile. It reeked of NIH. All of the requirements listed were provided by several other installers that are available and GPL licensed.
Stability, in terms of having a consistant platform for an extended period of time, is worth a lot. This is particularly true when you've got a limited staff trying to support hundreds of terminals around a large campus. Distributions that you can "download for free" don't offer the guaranteed, extended lifetime that you're going to get from RHEL. At least, not with continuing security updates.
Is it just me, or does the Debian project as a whole seem to have the nastiest case of NIH ever?
Lets see... installer needs to work on multiple architectures. Anaconda is used on all of PPC (Yellowdog), x86, s390. I think that's good evidence that it fits the bill.
Installer should to work on everything from serial cable to graphical interfaces. I've used anaconda on RLX blades with a serial interface, and my workstations with graphical interfaces.
Installer should handle CDROM, HTTP, FTP, NFS, hard drive sources for the install media. Yep, anaconda does those.
And furthermore, the idea that "nobody has more expertise in porting software to different platforms than the Debian project" is pompous and ludicrous. I don't have to say anything other than "NetBSD" as an answer to that.
Red Hat's employees have commented that when they seriously thought about joining the Debian project when they were planning the future of their hobbyist/developer distribution, but decided that it probably wouldn't work out. Articles like this remind me why.
I seriously doubt that the Debian team even looked at the available GPL licensed installers before deciding to write their own from scratch.
I don't have the same degree of confidence that the "developer community" will have the resources (time, machines and testing methodology) to maintain the same level of quality
If I were to guess, I'd say you've never run Debian, and never known anyone who has.
To that, I'll add that Red Hat will continue to be involved in the QA process for Fedora Core releases. Their Enterprise offering is going to be based on these releases, and they'd have a hell of a time convincing customers that they can base a good stable product on a distribution that sucks.
Probably that the implementation consists of two parts. The larger part of these is O(1), and there's a small O(n) operation involved.
I'm guessing.
You may be reading too much in to the statements on the Fedora site. For instance, the fact that there's no support from the company might seem frightening, but that's been the case with Red Hat Linux for several years now. The Enterprise line is the only one with commercial support available.
The fact that Fedora will incorporate new technology before Enterprise does does not mean that Fedora will be beta-level software. It means that Enterprise is a much slower moving platform, for the benefit of application vendors like Oracle. Fedora will continue to go through all of the QA that Red Hat Linux ever was. (ntp 4.2 was removed from the distro, in favor of 4.1 because 4.2 wasn't working. Just like you'd expect).
You might choose to switch to Mandrake. That decision is up to you. I'd do so slowly, though, and with plenty of testing. I've never really heard great things about Mandrake's stability.
My plan for the time being is to continue using RHL 7.3 (as we have for some time), with support from FedoraLegacy. If that group needs manpower, I'll probably end up involving myself to make sure that we get the support for our servers that we need. We'll continue that for as long as it takes for Fedora Core to prove itself, or to fail to do so. I expect the former, but maintain plans in case of the latter.
I don't really know how popular this digest authentication is
Not very. It only works if your server has a plaintext equivalent of your password. It's useless if you're authenticating against LDAP, for instance. Usually you'll end up using Basic authentication (plain text password) over SSL.
Here is a snippet of XHTML you can paste into a page.
' ></a>
' alt='Hacker logo' /></a>
<a href='http://www.catb.org/hacker-emblem/'>
<img src='http://www.catb.org/hacker-emblem/glider.png
The astute will notice that the above is not valid XHTML. It should be:
<a href='http://www.catb.org/hacker-emblem/'>
<img src='http://www.catb.org/hacker-emblem/glider.png
Actually the password is base64 encoded, to be safe over 7bit media. It's still very much "plain text".