""Openness is essential for trust..." --Whitfield Diffie, Sun Microsystems
BWAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!!!!
You really don't have a life. Do you?
|
|
|
 |
FreeRepublic , LLC PO BOX 9771 FRESNO, CA 93794
|
|
|
|
[Open Source Software Hacked] The software wasn't hacked. The FTP server was compromised, and every ten user got a trojan file. And again, thank god nobody ever hacks an IIS web server!!! (ill to my stomach from the sarcasm overdose)
Just stick with windoze and you won't have to worry about us dirty open source savages.
At least with open source, I don't have to trust the author. I can verify the integrity of the source myself. But anywho, I use Postfix instead of Sendmail because it has a higher level of SMTP security. A simple MD5 checksumming of the source would have shown the user that the source was corrupt. Nice thing about open source, the authors want you to help check the integrity. Mutual responsibility.
As for the hack, this was a vanity job. A sort of in your face, look at how "elite" I am.
Simple solution. Trust but verify. New 8.0 distro from Red Hat has disk checking software on the disk. Runs a test on the disks to verify they are originals copies, not trojans.
So a developer of the source can plant bugs/backdoors. Fancy that. News flash ... Bank tellers can steal from bank vaults. Who would have thought of that.
Unfortunately, what you get from the micro-crapware company can't be verified, or fixed. SP1 for XP unfixes some already installed fixes and leaves other security holes intact. You need to try and find out what got un-installed and find out what to do about it. The update does this without telling. Wonder why? didn't know? couldn't fix them all?
Penguin bites are fatal.
snooker
But the same thing happened to a Microsoft service pack, so this has little to do with open/closed source code.
The other open source project with atrocious security was the old BIND. BIND 9 was totally rewritten, and has been much better in that regard. Sometimes, it does make sense to go back to the drawing board and throw out old, outdated code.
There are shadowy figures out there, though, who can do amazing things to even relatively well-maintained servers running whatever OS you choose.
http://www.viacorp.com/auditing.html
Friday, our Japanese participants discover that a computer on their company network has been cracked into, one very secure Linux box running only SSH and Apache 1.3.4. Now this would definitely send a chill up your spine if you knew just how fanatic our friends are when it comes to network security. Furthermore, they only detected the intrusion three days after the fact, which is unbelievable when you consider the insane monitoring levels they've been keeping since they agreed to participate in the scan. They would have noticed any funny stuff, and in fact, they did, lots of it, but none of which came close enough to a security breach to raise any alarms.Readers should also note how although a key binary in the cracked machine had been modified, tripwire and an assortment of other booby traps failed to detect this had happened. Even a close-up manual inspection (comparing file contents with a trusted backup, playing with it's name) could not detect any odd behavior. This trick, and others equally spooky were achieved by clever manipulation of the OS's kernel code (dynamicly, through a module).
...
How the NT box was cracked into in the first place is still a mystery. The logs weren't helpful (surprise! surprise!) and the only way we were even able to confirm this had happened was by putting a sniff on the NT's traffic (following a hunch) and catching those sneaky packets redhanded, transmitting our SSH identification down under.
We never liked NT before, being generally suspicious of propriety blackbox OS, from a company with a long history of poor quality bloatware. But realizing just how helpless we were against an attacker that obviously knew the ins and outs of this can-of-worms OS, the company recognized that NT was a serious security hazard and changed it's security policies to keep it as far away from it's systems as possible, and this included restricting employees from using it from at home to log into the company network (even with SSH).
2) The attacker is using a custom built software penetration agent.
This is only an hypothesis, but is strongly supported by the fact that the entire attack only lasted an incredible 8 seconds! During which the attacker manages to log on (over an employee's SSH account, no less), gain root privileges, backdoor the system, remove any (standard) traces of it's activity and log off.
And they probably would have gotten away with it too, if it wasn't for those meddling kids!
Who thoughtfully installed a crude old tty surveillance-camera hack that trapped IO calls to and from isatty(3) file descriptors, in realtime, saving them on file along with a timestamp for neato it's-almost-as-if-you-were-there playback qualities.
Scary stuff, that.
Someone replaced the original sendmail source code distribution archive file with a bogus copy which included malicious code that opens a TCP connection to an outside server on port 6667 and waits for input from parties unknown.
This code runs as part of the build process, it does not affect the sendmail program, ancillary utility programs or support/configuration files.
The intruder replaced the file on the ftp server, but not the copy kept on the http server.
The MD5 checksum files were not altered. The PGP/GPG signatures were not altered (nor is it likely that they could have been). Anyone bothering to validate the checksums or check the cryptographic signatures would have discovered that the file was not genuine.
What can we infer from these facts? Someone gained unauthorized access to the sendmail.org ftp server and replaced the source distribution tarball with a bogus copy containing malicious code. Do you know which ftp server was in use at the time of the compromise and which platform it was running on? If not, then to claim that the fault lies with open source software is ill-informed, at best. Based on past experience I would attribute it to willful ignorance on your part. If you tried a little harder to get the facts straight and draw credible conclusions instead of acting like someone who's determined to spin every incident into a repudiation of something he hates, your words might hold more weight with those of us who actually know the subject and you might even find yourself involved in constructive dialogs. Your habit of starting and engaging in flamewars does not serve your purported cause very well. It takes real effort to constantly remind oneself that your behavior is not typical of all advocates of Microsoft software and culture. The average reader is not willing to make that distinction and will either agree with you or not based upon purely subjective criteria (and the choir says "Amen!"). Are you comfortable knowing that those who agree with you do so only because they're members of your camp? I certainly wouldn't be.
I'm troubled by the recent spate of compromised source tarball incidents (OpenSSH, BitchX IRC client, etc.) and all the more determined to make sure that none of my systems fall victim. I recently enabled GPG signature validation on the package management system on a couple of my systems but I'm not pleased with the results: several of the packages I've tried to install are not signed. This particular system does the right thing and refuses to install the unsigned packages (even though the MD5 checksums are valid) but why aren't the packages signed in the first place? While the MD5 checksums are checked against pre-existing local copies of the MD5 sums, reducing the likelihood that the MD5 sums could be falsified, I'm not comfortable relying only on this method of validation and would prefer the GPG cryptographic signatures.
There is a problem here, and users of open source and Free (libre) software (including Microsoft) should be concerned about the authenticity of the source code they use. A strong signature-validating package management system like RPM adds some protection, assuming the builder of the packages has taken due care to validate the source code used to create the package in the first place, but this isn't good enough, and a better system will have to be devised. Given my past experience with open source I'm optimistic that these issues will be addressed in the near future. Perhaps it's time to consider adding MD5 checksum and GPG signature validation directly to the BSD and GNU implementations of the ubiquitous tar(1) archive utility (the sectar project aims to be a "secure tar").
The problem of ensuring the authenticity of source code distributions is only the tip of the iceberg. What are we to do about this problem? Is Palladium (or something like it) the answer? I don't know. Sooner or later someone is going to figure out how to make Ken Thompson's nightmare scenario a reality (if it hasn't happened already) and I doubt anyone is equipped to detect such a compromise and deal with it effectively.