One noticable thing from the Debian breach is that we never knew anything about who did it.
Don't accuse an individual of perpetrating a security penetration unless you are doing so to the police and ultimately the district attorney. Just saying "X did it" outside of that context will get you sued, and you will lose because no conviction exists. The accused has the right to be tried by a jury of their peers, after all.
The situation is different when you are talking about a security problem - not an individual - that may effect you. Yes, the entire problem this time has been in Red Hat's communications. When they communicate this way, they leave you with no way to verify what the problem actually was. And security is not about trusting others, you have to be able to verify yourself, because just trusting puts a potential failure point in your security system - not everyone is trustworthy, and big companies with conflicted interest are rather low on the list of potentially trustworthy entities. Consider HP, bigger than Red Hat, and the fact that their head attorney had to take the 5th in front of Congress. The situation is worse because some people (Fedora insiders, RH employees, customers they told under NDA) know the full details and potentially have power over your system that you would not like them to have.
Bruce
Re:The real world is a bit different than that.
on
The Fedora-Red Hat Crisis
·
· Score: 2, Insightful
The practice followed by Debian is that preferred by professional security engineers. They quickly closed the vulnerability, and then once the vulnerability was closed they reported how they failed, what the impact was on others, and how they'd fix it. There was sufficient information to convince the customer that they'd done the right thing.
Less than full disclosure is a problem because when you trust people, you place more potential points of failure in your security system than when you can verify something on your own. Real security does not trust, they check everything.
The problem is made worse by the fact that some people have all of the information. People in Red Hat and Fedora, and some customers that they've told under NDA, and whoever the perpetrator told. Those folks all have power over your system, potentially, that you would not want them to have.
Read Schneiner, he's a good independent source on this.
And if you please, "zealot" isn't polite. We all have our own beliefs, you same as I, for what we percieve to be good reasons.
That stuff about the current following the path of least resistance and flowing along the skin is actually only for high-frequency AC as from a Tesla coil, not DC as from a 12-volt battery. And then it's impedance, not resistance.
Professionals don't wear rings because those 12-volt terminals are connected to wires, and in various places along the circuit the two connections are brought quite close to each other.
This is serious stuff, be careful not to misinform lest others hurt themselves.
They harmed the FOSS community because they got in the way of the FOSS developers responding appropriately to their own security problem.
They harmed their customers because a business with more than 50 people has SOx to deal with, and to pass their own audits must be able to assure their own security with more than just a "you're OK, we promise". Even if they didn't have SOx to deal with, it would be bad practice for any security officer to accept "just trust me".
Bruce
Re:Affecting me to effect change has a good effect
on
The Fedora-Red Hat Crisis
·
· Score: 1, Informative
People have been dinging me on Effect vs. Affect for 3 decades. They are all right and all wrong, because legitimate dictionaries give one of the definitions of "affect" as "to have an effect upon".
surprise surprise, our 850 RHEL4/5 installs had none
You're very trusting with all that money. Someone else in the same situation might truthfully report: my vendor is keeping me the dark, I don't know the nature and degree of my own exposure.
Red Hat has an accepted path to make vulnerability information available, through CERT. There are no super crackers or super vulnerabilities that you can't talk about. Probably it was like the Debian situation. Someone got sloppy and had their password sniffed. Then once on the system a privilege-escalation vulnerability was used.
The Debian compromise lasted about two hours. The attacker had sniffed a developer password some time before then, but it wasn't until he could get root that he did anything dangerous, and he did stuff that revealed him to the site admins. The main problem was in the kernel, which had the privilege-escalation bug. Red Hat was vulnerable too.
Ob-FUD [just to poking Bruce for fun]: If they do come forth with details, it will be interesting to see if it was an ssh key compromised by the Debian flaw that caused this mess.
I got an email from Starfield a while back offering to re-key my SSL certificates because they had figured out that my original request was using Debian's compromised OpenSSL. I had already rekeyed by then.
Thawte is Debian based. I wonder if they had a problem.
The problem with not coming clean by 1) saying what happened and what you did wrong and 2) saying how you're going to fix it is that nobody will ever trust you again afterwards. IT managers now know that RH is going to go unresponsive when there's a problem. How can they trust Red Hat again? It might be different if RH was the only game in town, but there is an accepted standard for performance by thousands of Open Source projects in this sort of situation, and it's known as the best practice in the entire IT field, and Red Hat fell short.
They have to buy people's trust again now with their actions, and it's going to take years, if they even do it.
I liked the way that Debian handled its server breach, and the more
recent SSL bug. They realized that their first responsibility was to
the users. They knew that not just Debian but all Debian derivatives
like Ubuntu would be effected, and that the best way to handle it was to
publish the full details and what they were doing to fix them. They came
out of both situations looking better than Red Hat has this time. And
it's not what Fedora looks like. Red Hat obviously took control,
shutting off outside reporting in a way that never would have flown with a
real Open Source project rather than a company dominating an Open Source
project, and thus Red Hat got the loss of credibility.
The problem with a lot of corporate Open Source is that they ignore
the ethical foundation of Open Source. And eventually we find out that
Open Source isn't quite as good without the ethics.
Don't scoff at the lethal capabilities of the 12-volt battery. I never wear jewelry, not even my wedding ring. Put a wedding ring across that 12-volt battery, and you cook your finger off pretty quickly. Worse things can happen.
Actually battery is plural. The singular form is cell, as in Nickel-Metal-Hydride cell. A battery is two or more cells, connected in series, parallel, or both. This goes back to the early days of electronics.
We're talking about 1032 abortions at or past the 24th week, per year in the U.S. according to these folks. With that small a number, I doubt this is an elective issue rather than a medical one. Only 12% of abortions are done by or past the 13th week of gestation. 20-week fetuses are not viable. 27-week ones generally are. Any gray area is between the two.
None of this means a bit to people who believe in immortal souls granted by God upon conception. I think that's where the real argument lies.
Children with Down's syndrome have a suite of physical defects, often including mental retardation and short lifespan, caused by an error in cellular combination at conception. Their parents know this.
Many mothers these days have amniocentisis during pregnancy, which can reliably indicate Down's syndrome and a number of worse problems if present, and at that point can make a decision to terminate the pregnancy. They must face the question: "is it more cruel to bring this child into the world than to refrain from doing so?".
If you believe that a soul is placed in that child by God at the moment of conception, you may make a very different decision from someone who does not believe in deities, spirits, or souls.
Whatever you believe, behave as your religion and philosophy demand. I do not believe that it's the right of the governor of Alaska, or you, or the pope, to impose your religious beliefs on me or any unborn child that I might have.
Pixar had an OEM model too, back in its days of making hardware and software products (the Pixar image computer, Renderman, Renderman hardware acceleration) while waiting for the noncompete with Lucasfilm to run out. It's a very difficult way to run a business, because you have to pull your own market along with you, and you can't control them.
It does look like 3DFx bought the wrong card vendor. They also spun off Quantum3D, then a card vendor, which is still operating in the simulation business.
Pixar has had a great many employee perks, starting with cohabitant insurance benefits long before they were profitable. It's not very well known that they went bankrupt, repurchased employee stock, and refinanced once, although with Steve Jobs as the only major creditor they didn't need to go through formal bankruptcy in court.
They asked a lot of employees, and the benefits had to match that.
I think nVidia's lawsuit was strategicaly positioned to be the straw that closed out additional investment prospects for 3DFx and pushed them into formal bankruptcy.
I am mostly concerned with this because that was our only source of 3D cards with Open Source drivers, and nVidia killed it, and we really only recovered from that over the past year or so with Intel and ATI's releases.
I think the reason we've survived the other 35 companies who were making graphics at the start is that we've stayed focused.
3DFx was the first company to publish Open Source 3D drivers for their 3D cards. nVidia sued them, then bought them at a discount, and shut down the operation. So, we had no Open Source 3D for another 5 years.
That's not "staying focused". It's being a predator.
Oops. Slashdot ate my italics. Anyway, the important part above is that your subsystem avoiding GPL3 has to be an essential component of the OS or compiler as defined above. Making a case that some entire random subsystem of an application is an essential OS component might not get by the judge.
It seems to me that the definition of system libraries is tighter than are implying. Here's part of GPL3, the italics are mine:
The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
Calling an entire subsystem an essential part of your OS just to avoid the GPL could backfire, given the language above.
Consider the Firebird database, which was used for airline reservation systems. A deliberate back-door persisted for 9 years as proprietary software, and an additional 9 months as Open Source. Without Open Source, the back-door probably would have persisted to the end-of-life for the last use of the program.
If proprietary software was made extremely secure, how would anyone without the source be able to tell? Just trust someone?
The complete bootable system with the command line is "The GNU System", or "Red Hat", or "Debian", or "Novell". You are perfectly correct to say that Linux doesn't have a GUI, but except for insiders like the people you meet on Slashdot or in a software development house, nobody is going to understand that statement.
Slashdot Mirror
Well, in Red Hat's position, I would have pushed out fixes already if that was the case. And there's no evidence that they've done so.
Bruce
Don't accuse an individual of perpetrating a security penetration unless you are doing so to the police and ultimately the district attorney. Just saying "X did it" outside of that context will get you sued, and you will lose because no conviction exists. The accused has the right to be tried by a jury of their peers, after all.
The situation is different when you are talking about a security problem - not an individual - that may effect you. Yes, the entire problem this time has been in Red Hat's communications. When they communicate this way, they leave you with no way to verify what the problem actually was. And security is not about trusting others, you have to be able to verify yourself, because just trusting puts a potential failure point in your security system - not everyone is trustworthy, and big companies with conflicted interest are rather low on the list of potentially trustworthy entities. Consider HP, bigger than Red Hat, and the fact that their head attorney had to take the 5th in front of Congress. The situation is worse because some people (Fedora insiders, RH employees, customers they told under NDA) know the full details and potentially have power over your system that you would not like them to have.
Bruce
Less than full disclosure is a problem because when you trust people, you place more potential points of failure in your security system than when you can verify something on your own. Real security does not trust, they check everything.
The problem is made worse by the fact that some people have all of the information. People in Red Hat and Fedora, and some customers that they've told under NDA, and whoever the perpetrator told. Those folks all have power over your system, potentially, that you would not want them to have.
Read Schneiner, he's a good independent source on this.
And if you please, "zealot" isn't polite. We all have our own beliefs, you same as I, for what we percieve to be good reasons.
Bruce
Professionals don't wear rings because those 12-volt terminals are connected to wires, and in various places along the circuit the two connections are brought quite close to each other.
This is serious stuff, be careful not to misinform lest others hurt themselves.
"Crisis" is polite language for what is really meant :-)
They harmed their customers because a business with more than 50 people has SOx to deal with, and to pass their own audits must be able to assure their own security with more than just a "you're OK, we promise". Even if they didn't have SOx to deal with, it would be bad practice for any security officer to accept "just trust me".
Bruce
Emerson to them all!
You're very trusting with all that money. Someone else in the same situation might truthfully report: my vendor is keeping me the dark, I don't know the nature and degree of my own exposure.
This would make me nervous.
I would have phrased it differently: The issue isn't fully known, thus there's a problem.
There's been quite a lot of time.
The Debian compromise lasted about two hours. The attacker had sniffed a developer password some time before then, but it wasn't until he could get root that he did anything dangerous, and he did stuff that revealed him to the site admins. The main problem was in the kernel, which had the privilege-escalation bug. Red Hat was vulnerable too.
Bruce
I got an email from Starfield a while back offering to re-key my SSL certificates because they had figured out that my original request was using Debian's compromised OpenSSL. I had already rekeyed by then.
Thawte is Debian based. I wonder if they had a problem.
They have to buy people's trust again now with their actions, and it's going to take years, if they even do it.
The problem with a lot of corporate Open Source is that they ignore the ethical foundation of Open Source. And eventually we find out that Open Source isn't quite as good without the ethics.
Bruce
Check out the Prius Emergency Response Guide for some information on some pieces that can hurt you.
Bruce
Bruce
None of this means a bit to people who believe in immortal souls granted by God upon conception. I think that's where the real argument lies.
Children with Down's syndrome have a suite of physical defects, often including mental retardation and short lifespan, caused by an error in cellular combination at conception. Their parents know this.
Many mothers these days have amniocentisis during pregnancy, which can reliably indicate Down's syndrome and a number of worse problems if present, and at that point can make a decision to terminate the pregnancy. They must face the question: "is it more cruel to bring this child into the world than to refrain from doing so?".
If you believe that a soul is placed in that child by God at the moment of conception, you may make a very different decision from someone who does not believe in deities, spirits, or souls.
Whatever you believe, behave as your religion and philosophy demand. I do not believe that it's the right of the governor of Alaska, or you, or the pope, to impose your religious beliefs on me or any unborn child that I might have.
Bruce
It does look like 3DFx bought the wrong card vendor. They also spun off Quantum3D, then a card vendor, which is still operating in the simulation business.
They asked a lot of employees, and the benefits had to match that.
I think nVidia's lawsuit was strategicaly positioned to be the straw that closed out additional investment prospects for 3DFx and pushed them into formal bankruptcy.
I am mostly concerned with this because that was our only source of 3D cards with Open Source drivers, and nVidia killed it, and we really only recovered from that over the past year or so with Intel and ATI's releases.
Bruce
3DFx was the first company to publish Open Source 3D drivers for their 3D cards. nVidia sued them, then bought them at a discount, and shut down the operation. So, we had no Open Source 3D for another 5 years.
That's not "staying focused". It's being a predator.
Bruce
Oops, too late. You're entangled!
Oops. Slashdot ate my italics. Anyway, the important part above is that your subsystem avoiding GPL3 has to be an essential component of the OS or compiler as defined above. Making a case that some entire random subsystem of an application is an essential OS component might not get by the judge.
Calling an entire subsystem an essential part of your OS just to avoid the GPL could backfire, given the language above.
If proprietary software was made extremely secure, how would anyone without the source be able to tell? Just trust someone?
The complete bootable system with the command line is "The GNU System", or "Red Hat", or "Debian", or "Novell". You are perfectly correct to say that Linux doesn't have a GUI, but except for insiders like the people you meet on Slashdot or in a software development house, nobody is going to understand that statement.