Slashdot Mirror
Sendmail Bug Tests US Dept Homeland Security
yanestra writes "CNET reports that the reported Sendmail bug has been a test for the US Department of Homeland Security which seems to have managed information flow in this case."
← Back to Stories (view on slashdot.org)
Interesting to read that the government is involved with this -- kind of makes you wonder what happened to CERT, which always used to coordinate public disclosure of and vendor response to bugs like this.
The fact that CERT always seemed to do a decent job makes this even more interesting. The biggest criticisms voiced about CERT were that they acted too slow and didn't provide enough detail information about problems (other than to acknowledge the general nature of it). How will the government do better in these areas?
My guess is that the answer to the latter question is 'not much', and that we'll start hearing the same complaints about the Dept. of Homeland Security soon...
This is actually quite encouraging. Having an organization that deals with the painful process of contacting each vendor and major user of a program with a newly discovered vulnerability is a major improvement. They also seem to have the law behind them (is this true?), so we finally have someone that can force people to fix security holes. I don't quite like the homeland-security big-brother model, but it worked nicely in this case and got the job done, something pretty hard in the Internet jungle.
We all got notified to patch our systems immediately.
Everyone is working togther to get all the systems running sendmail patched.
While this doesn't seem like a big deal in the corporate world, in the government world, all red tape has been removed and we can make changes to critical systems INSTANTLY.
FIX FIRST, meet later. It's an entirely different attitude, and it allows me to do my job more efficently. It works.
Is the U.S. Department of Homeland Security also going to try and take care of software developed internationally?
For example, it seems that a lot of OpenSSH development is done in Canada and Germany. And the server is run out of Canada.
The OpenSSL team looks primarily international too (UK, Germany, Sweden, New Zealand). There server is managed by Brits and Swedes.
Actually... I think you'll find that a lot of crypto software is based outside the US. Probably due to constraints placed on crypto development in the last decade.
Windows always has been and always will be a security risk.
Superior alternatives exist... so why is anyone still using Windows???
--
Sure Joe runs sendmail, and sendmail is insecure. But does Joe's server get attacked frequently? Chances are it probably doesn't. If it does, Joe may be looking into alternatives, or Joe may have found one already.
Joe doesn't have the time to fix every potential threat. Joe probably installs patches and updates as frequently as possible, maybe even on a schedule. Joe does his best to keep sendmail from being a problem, and at the same time Joe tries not to waste time.
If Joe were working for a huge company that depended heavily on it's e-mail, Joe would probably spend more time on sendmail. But odds are Joe doesn't, and Joe is doing the best he can.
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
Once again, ISS have let the community down. Instead of informing the vendors, or CERT, or even just posting to Bugtraq, they informed the USG first. As a result .mil sites had the patch four days before anyone else (so far as we know) were even aware that there was an issue. [Although they claim that they checked their private "sensor" networks, somehow I doubt they have better coverage than eg DShield.org. ) This is unacceptable behaviour for an info-sec company that wants to be a responsible member of the community, and of course is just the latest in a list of behaviour that I at least consider unethical. I work for an ISS reseller outside the USA, and I will be exercising my influence internally to push for replacing the ISS prodcuts either with Free alternatives, or proprietary products from companies with a better grasp of their responsibilities. BTW we have several very big global clients.
I think a timeframe needs to be established. Those who find exploits in programs have a moral obligation to let the maintainers of the program know first and give them a reasonable amount of time to fix the problem.
But what is reasonable? A week? A month? What if the exploit is a deep flaw in the system, something that cannot be fixed?
So, how long is long enough to keep an exploit from the general public? Does it depend upon the exploit, the company that makes the product, or the person who finds it? Is there a balance to be found?
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
I think it's interesting that the government is getting credit for working with the private sector in releasing information. Part of the the point of open sourced software is so that bugs can be found and patched quickly. The CERT email I got yesterday afternoon had MANY patch sources listed by vendor (RedHat, Apple, Sendmail etc) and was timely. I don't belive that the pat on the back goes to Uncle Sam in this situation, but rather the folks at Sendmail who worked to resolve this issue in a timely and organized fashion. They released the information to those who needed to know (including the DHS) and worked on a solution to get this stuff out to the public.
To quote Eric Raymond, "Given enough eyeballs, all bugs are shallow"
Kudos to Sendmail for getting this taken care of.
AF-Design, web development.
The one thing I didn't like about this article was the idea that this kind of process should be followed by everyone. This is what I saw as the process:
Here's the flaw(s) in this process:
I guess the biggest thing that I don't like about this is that idea that this model will support the Closed Source software model because of the arguments of: