CERT: Sendmail Distribution Contained Trojan Horse 335
Scoria writes "According to a CERT advisory published this afternoon, the public distribution of Sendmail 8.12.6 contained a trojan horse from September 28 to October 6. For more detailed information, please consult advisory CA-2002-28." This sounds very much like what happened to OpenSSH.
But that's okay... (Score:5, Funny)
Article text... (before it gets /.ed) (Score:2, Informative)
Original release date: October 08, 2002
Last revised: --
Source: CERT/CC
A complete revision history is at the end of this file.
Overview
The CERT/CC has received confirmation that some copies of the source code for the Sendmail package were modified by an intruder to contain a Trojan horse.
Sites that employ, redistribute, or mirror the Sendmail package should immediately verify the integrity of their distribution.
I. Description
The CERT/CC has received confirmation that some copies of the source code for the Sendmail package have been modified by an intruder to contain a Trojan horse.
The following files were modified to include the malicious code:
sendmail.8.12.6.tar.Z
sendmail.8.12.6.tar.gz
These files began to appear in downloads from the FTP server ftp.sendmail.org on or around September 28, 2002. The Sendmail development team disabled the compromised FTP server on October 6, 2002 at approximately 22:15 PDT. It does not appear that copies downloaded via HTTP contained the Trojan horse; however, the CERT/CC encourages users who may have downloaded the source code via HTTP during this time period to take the steps outlined in the Solution section as a precautionary measure.
The Trojan horse versions of Sendmail contain malicious code that is run during the process of building the software. This code forks a process that connects to a fixed remote server on 6667/tcp. This forked process allows the intruder to open a shell running in the context of the user who built the Sendmail software. There is no evidence that the process is persistent after a reboot of the compromised system. However, a subsequent build of the Trojan horse Sendmail package will re-establish the backdoor process.
II. Impact
An intruder operating from the remote address specified in the malicious code can gain unauthorized remote access to any host that compiled a version of Sendmail from this Trojan horse version of the source code. The level of access would be that of the user who compiled the source code.
It is important to understand that the compromise is to the system that is used to build the Sendmail software and not to the systems that run the Sendmail daemon. Because the compromised system creates a tunnel to the intruder-controlled system, the intruder may have a path through network access controls.
III. Solution
Obtain an authentic version of Sendmail
The primary distribution site for Sendmail is
http://www.sendmail.org/
Sites that mirror the Sendmail source code are encouraged to verify the integrity of their sources.
Verify software authenticity
We strongly encourage sites that recently downloaded a copy of the Sendmail distribution to verify the authenticity of their distribution, regardless of where it was obtained. Furthermore, we encourage users to inspect any and all software that may have been downloaded from the compromised site. Note that it is not sufficient to rely on the timestamps or sizes of the file when trying to determine whether or not you have a copy of the Trojan horse version.
Verify PGP signatures
The Sendmail source distribution is cryptographically signed with the following PGP key:
pub 1024R/678C0A03 2001-12-18 Sendmail Signing Key/2002
Key fingerprint = 7B 02 F4 AA FC C0 22 DA 47 3E 2A 9A 9B 35 22 45
The Trojan horse copy did not include an updated PGP signature, so attempts to verify its integrity would have failed. The sendmail.org staff has verified that the Trojan horse copies did indeed fail PGP signature checks.
Verify MD5 checksums
In the absence of PGP, you can use the following MD5 checksums to verify the integrity of your Sendmail source code distribution:
Correct versions:
73e18ea78b2386b774963c8472cbd309 sendmail.8.12.6.tar.gz
cebe3fa43731b315908f44889
8b9c78122044f4e4744fc447ee
As a matter of good security practice, the CERT/CC encourages users to verify, whenever possible, the integrity of downloaded software. For more information, see
http://www.cert.org/incident_notes/IN-2001-06.h
Employ egress filtering
Egress filtering manages the flow of traffic as it leaves a network under your administrative control.
In the case of the Trojan horse Sendmail distribution, employing egress filtering can help prevent systems on your network from connecting to the remote intruder-controlled system. Blocking outbound TCP connections to port 6667 from your network reduces the risk of internal compromised machines communicating with the remote system.
Build software as an unprivileged user
Sites are encouraged to build software from source code as an unprivileged, non-root user on the system. This can lessen the immediate impact of Trojan horse software. Compiling software that contains Trojan horses as the root user results in a compromise that is much more difficult to reliably recover from than if the Trojan horse is executed as a normal, unprivileged user on the system.
Recovering from a system compromise
If you believe a system under your administrative control has been compromised, please follow the steps outlined in
Steps for Recovering from a UNIX or NT System Compromise
Reporting
The CERT/CC is interested in receiving reports of this activity. If machines under your administrative control are compromised, please send mail to cert@cert.org with the following text included in the subject line: "[CERT#33376]".
Appendix A. - Vendor Information
This appendix contains information provided by vendors for this advisory. As vendors report new information to the CERT/CC, we will update this section and note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments.
Over a week? (Score:4, Interesting)
Many eyes = better security but only when many > 0
Re:Over a week? (Score:5, Informative)
>really used Sendmail anymore.
What amazed me is I wasn't even aware anyone really used Unix anymore. Man, look at all the security holes in *that* software's history.
Sendmail hasn't had a remote exploit in over two years. Named has had a single advisory posted against it (a DoS) since the 9.x series was released.
Matt
Re:Over a week? (Score:2, Informative)
Last time I checked you need to devote some serious time and brain power to properly setting up sendmail.
Re:Over a week? (Score:5, Informative)
>configuration trivial, as it should be.
It really depends on what you're doing with them.
First off, installing either usually involves compiling from source, due to the restrictive licensing.
The software also isn't built to start under native Unix facilities like init or xinetd, so you either need to deal with installing and configuring ucspi and tcpserver, or hacking the source.
The lack of standards support in qmail also ends up requiring patching in a lot of common configurations, further complicating things. And honestly, configuring qmail isn't exactly a dream - permissions issues are easy to miss, a lot of configuration data requires compilation to a binary format, and configuration data is spread across a fairly large number of files and is hardly in the most intuitive of formats, e.g.:
+foo.com-:foo.com:500:500:/domains/foo.com:-::
Djbdns can either be very easy (simple case) or a pain in the ass.
For starters, there are a lot of standards it doesn't bother starting (IXFR, NOTIFY, TSIG, DNSSEC, etc). So interoperability with other servers is at best suboptimal.
Even if you're going to run a pure djbdns environment, there's no built in facility to transfer zone data, so you also need to either install and configure the axfr-dns program or install and configure rsync and ssh or some other method of copying the zone data to the remote server. In either case the propogation isn't automatic, so you'll probably want to write your own scripts to automate this.
Doing split-dns is a lot less intuitive than in BIND, in my opinion. You can add location tags to entries in the database, but the format only allows one per entry, so if you have different location definitions, you need to add the data multiple times (or store your data in a different format and process it into what tinydns-data expects). And those location tags are limited to only two characters, which prevents any meaningful name.
>Last time I checked you need to devote some
>serious time and brain power to properly setting
>up sendmail.
When did you last check? The mid-ninties?
Configuring Sendmail since the switch to m4 files is *trivial* for most setups.
What's even better is that, since Sendmail is under a permissive license, virtually all versions of Unix offer it by default, pre-installed and with a basic configuration.
For example, if you're doing a single domain setup the extent of your configuration on Red Hat would be adding your domain name to the
Want mail sent to phil@mydomain.net to go to bob instead?? Simple, add "phil@mydomain.net bob" to
And on Red Hat you don't even have to deal with compiling the database files, since the init scripts do it for you. Just run "/sbin/service sendmail restart".
Matt
Checksums (Score:4, Insightful)
Re:Checksums (Score:2, Interesting)
I can think of some likely players, namely those who feel that Linux/Unix is a threat to them.
Also can't forget about the black hats and chinese/russian/terrorist groups as well.
Re:Checksums (Score:5, Funny)
Incorrect md5 sums certainly strike terror into my heart.
Re:Checksums (Score:2, Insightful)
Re:Checksums (Score:2)
Re:Checksums (Score:2)
Re:Checksums (Score:4, Interesting)
What we need is a new format, as universal for Unix as
Re:Checksums (Score:5, Informative)
Just another plus for the distro, I suppose.
Re:Checksums (Score:4, Informative)
Of course, it would certainlly be funny if all the modified binary did was, in addition to the normal functionality of the program, also told you that you should verify the relevant checksums before installing.
Re:Checksums (Score:5, Interesting)
Gentoo neatly gets around this problem by using the source directly, and since a lot of projects list md5sums of the source archives (such as sendmail 8.12.6 [sendmail.org]), Portage can make sure that it gets the correct tarball.
Oh, and by the way:So, Gentoo had the right one on file all along. And, of course, Portage won't unpack files with the wrong md5sum, meaning Gentoo users were completely immune to this.
Re:Checksums (Score:3, Informative)
Red Hat solves this problem by signing all their packages. It's up to Red Hat to assure that the sources aren't trojaned, but they have a big monetary motivation to do so.
Re:Checksums (Score:4, Insightful)
Huh? Isn't that kind of the point of using md5?
If you have an md5 checksum for a binary (and assuming that it's from a reliable source), then why can't you use this to validate the binary is correct?
You could, in theory, construct a trojaned-binary that had the same md5 checksum, but I had always thought that this was so difficult as to be infeasible/not worth worrying about.
What am I missing? Are you saying the md5 checksum is being spoofed too?
Tim
Re:Checksums (Score:2)
We need a way to verify signatures (Score:5, Interesting)
For most people, never.... It would be great if we have automatic download tools to check signature as well (obviously, we need standard for storing the signature as well)
Not to plug Gentoo AGAIN, but... (Score:2)
Detecting corruption vs. tampering (Score:2)
Re:Not to plug Gentoo AGAIN, but... (Score:2)
Re:We need a way to verify signatures (Score:3, Informative)
Difficult? With GnuPG you can just do a gpg --verify and md5 is just md5sum filename
You mentioned the real issue: key management. If files from ftp.sendmail.org get infected, then people could probably get a bogus key as well. (Although the sendmail folks verified that the files didn't have an updated signature and wouldn't have validated).
Re:We need a way to verify signatures (Score:4, Insightful)
This difference, though, is that one can download a public GPG key from a site (like sendmail.org or something) and continue using it to verify software over several versions. So, for example, you could use a 2002 public GPG key to verify software in 2004 and be reasonably sure the key hasn't been tampered with for two years straight without someone noticing. With an md5sum, the checksum is only good for that version of the software and can forged much easier in the short term.
That said, I think md5sums are better for ensuring integrity, GPGs are better for ensuring security and both should be as automated as possible (like with the help of RPM and friends).
also keys come from DIFFERENT locations than src (Score:3, Interesting)
This difference, though, is that one can download a public GPG key from a site (like sendmail.org or something) and continue using it to verify software over several versions.
Not only that, but public keys (or even complete keyrings containing public keys for groups of developers) can be obtained from multiple, different sources, all of which in turn are different and ideally independent of where one downloads the source tarball from.
This means one can obtain a developer's key or keyring from, say, a public key server (or two, or several), some ftp site (preferably a different non-mirror one from the tarball), a purchased CD, or any number of other places, check them against each other (make sure none disagree), and use them to check a download immediately, as well as 5 years from now.
The cracker would have to not only trojan the tarball, but also break into numerous independent key servers around the globe, numerous ftp sites around the globe, likely numerous web sites as well, and perhaps even various freenet nodes as well (if that is being used to distribute keys as well). And for those who anti up $5 for a CD with developers keys on it, they'd have to intercept the postal service and swap CDs as well (or crack the master CD before it goes to press).
Good luck. Even the NSA would probably have trouble pulling something like that off.
Re:We need a way to verify signatures (Score:2)
Re:We need a way to verify signatures (Score:2, Informative)
Re:We need a way to verify signatures (Score:3, Informative)
That being said, it certainly isn't inconceivable that the checksums themselves could be tampered with, but it is at the least a further layer of security.
Re:We need a way to verify signatures (Score:2, Informative)
For end users of binary RPMs, RedCarpet (and I presume competing tools like apt-get) automatically check signatures.
Yes, it is more difficult for tarballs. But I think the theory is that people packaging tarballs have a clue. It really is not that difficult to check sendmail tarballs. Just download that ascii signature file also, and run pgpv. It even runs md5 for you. The only wrinkle is that you have to gunzip the tarball first:
Ximian Red Carpet (Score:2)
Ximian's Red Carpet does MD5 and GPG verification of packages every time it does an install or an update.
Checksums and crypto (Score:5, Informative)
Re:Checksums and crypto (Score:2)
The author of a package should digitally sign the package he is distributing, and part of that signature should necessarily contain the appropriate MD5 checksum for the package.
This way, one can easily tell if the package has been tampered with (if the signature does not unencode with the author's public key, or the unencoded checksum is invalid). Of course, the one flaw with this is that there needs to be a way to determine who the author is and grab the author's public key. If the author's identity is stored in the package, then this method is useless. If the author's identity can be found via some central resource (say, a searchable database of projects and their authors on the FSF or GNU websites), then the security of this method is only as strong as the security of that database.
All in all, food for thought, but no real foolproof way of verifying you're installing untampered binaries.
Re:Checksums and crypto (Score:2)
Scary. (Score:5, Interesting)
check sums blah blah (Score:5, Insightful)
Re:check sums blah blah (Score:2, Interesting)
It would be best to sign the MD5 with a PGP signature. They key they use may have also been compromised, but at least that adds another layer to security.
Two reasons. (Score:2)
2) It didn't get discovered for a week, so obviously no one used the check sums.
Re:check sums blah blah (Score:4, Informative)
You still need a trusted info source ... (Score:5, Insightful)
I download the tarball and MD5s. Then I want to verify the signature. For that I need a public key or something like that of the developer that signed the tarball.Since I never met him, I must resort to download also that from an internet place, probably the same from which I downloaded the source.
Now, what prevents whoever cracked the server and placed the troianed tarballs on it, to also change the public key, so that it matches the couterfeit signed tarball?
At a minimum, one should go to some forum/ML and check the key with a dozen or so other users, choosing the ones that got the key in different places and times.
Or am I missing something ?
Re:check sums blah blah (Score:3, Interesting)
Type cd /usr/ports/mail/sendmail && make install and it then downloads the source, and then checks what it downloaded against an md5 checksum that's kept on your machine before it applies patches and builds.
Re:check sums blah blah (Score:2)
You get the binaries from a mirror to ease the load on the master server and then get the MD5sum (which is just a few bytes) from the master server to verify the binaries you got.
Microsoft Sux!!! (Score:3, Funny)
Thank GOD for Microsoft! (Score:5, Funny)
Re:Thank GOD for Microsoft! (Score:5, Funny)
got any exploits? (Score:2, Informative)
outlook web access / iis is the only source of problems, but that's all iis' fault.
This is a good reason to get windows! (Score:4, Funny)
Sendmail (Score:2, Funny)
Only the FTP... (Score:5, Insightful)
So, as for those that are saying it's an Open Source problem, this is just wrong.
There's been alot more closed software distributed with Viri/Trojan Horses. The truth is, this is bound to happen if the public archives are on an unsecured server...I even seem to remember pressed CDs being distributed with trojans.
So, what are they doing to keep this from happening again?
Re:Only the FTP... (Score:4, Funny)
Surely these can't be Microsoft CDs!?! According to a KB article at Microsoft.com, "Disks are duplicated on a variety of industrial strength, quality focused systems. Most of these systems are UNIX-based. The UNIX-based duplication systems used in manufacturing are impervious to MS-DOS-based, Windows-based, and Macintosh-based viruses."
Re:Only the FTP... (Score:2)
Re:Only the FTP... (Score:5, Interesting)
All of the virus scanning should be done by the vendor/distributor...
The infections generally happen before it gets pressed. That's why it's usually only a few files that are infected. Someone's machine is infected and due to either poor administration or what not, they get onto the pressed CD.
But, the truth is, mass-produced CDs don't go into a CD-R (ever wonder why there's no dye to be found on pressed CDs?)...They are pressed...they use molded metal "stamps" from a glass master...
The UNIX machines are most likely only running the pressing machines...now, if you're expecting me to belive that a virus can get onto the pressing machine through this process, I'ld like to know how...
Check out This link [mmsdirect.com] to read about the process of CD pressing.
I'm sure M$ has a reason for making it sound like they are using standard CD-Rs for this process...it probably makes it easier to blame a UNIX machine when a problem does arise...rather than telling ppl that one of your developers had an infected machine...
Re:Only the FTP... (Score:3, Insightful)
Um. I can't tell if you're kidding or not, so I'll bite:
It doesn't matter what kind of computer runs the machine that copies the CDs. The machine that creates the master CD could have a virus, and infect an executable on the CD. I'm sure microsoft has a number of failsafes in order to make sure that this master CD doesn't have a virus on it, but having a unix computer run the duplication machine is not one of those failsafes.
Question (Score:3, Interesting)
# netstat -a | grep 6667
all that is necessary to see if one has a the open port, or is there more to it than that?
Re:Question (Score:3, Informative)
I can't say for sure but seeing as the trojans only action is to open the port (doesn't infect anything, can't survive a reboot), it's probably not smart enough to cover it's tracks very well and that would probably show it.
The solution given in the cert advisory is basicly
Holy crap (Score:2, Interesting)
I considered doing sendmail, but then I remembered how fucking thick the ORA sendmail book is and how complex it is, so I decided, "screw it, let's try postfix, I have never tried it before." If I had gone with sendmail, there would be some serious egg on my face tomorrow morning. We might be running MS exchange within a week if that had happened.
(Oh yeah, and postfix was pretty easy to set up.)
Upgrading Sendmail isn't Enough (Score:5, Informative)
So more than just checking the MD5sums of things you download you need to watch who you compile as, since the trojan will have the privledges of whoever compiled sendmail. This isn't exactly the most sly trojan either, it is quite blatent about how it creates a tunnel to a specified target, this can also help the intruder avoid firewall rules and detection.
If you find you've been affected by the trojan you would be wise to reinstall the system from known clean code since the intruder may have already created other backdoors from themself.
No worries! (Score:4, Interesting)
Ahem. Sorry. Couldn't resist. AAH! Don't mark it troll yet! Keep reading!
Ok, folks will say "Well here's a great example of a problem cryptography would prevent." Well as long as the guys inserting the trojans aren't contributing to your code base. Minor detail there. Keep in mind that a "trojan" can be as easy to code up as allowing a buffer overflow to take place (AND you have plausible deniability there.) Ok. So I'm paranoid.
So lets talk about the crypto side of things again. Since I'm paranoid and all that. Do you trust the project maintainer's system security? Reckon he allows anyone to log into his system? Do you trust their security and the network they come over? For that matter, reckon the CVS archive the code's stored on could be compromised? Do you see what we're up against yet? Paranoia...
Ok, lets say we've checked out his sytem and it's sterling. Key server/key management is a big pain in the ass right now. It'd be nice to have some infrastructure in place where I could go to a brick and mortar, establish my identity (Here's my passport, driver's license yadda yadda) and load MY PGP public key onto their server with their signature attached. Might even be worth a few bucks for me. That'd make that whole expiration thing pretty easy to deal with too.
It also seems to be that the US Postal Service would be the ideal venue for this infrastructure. As much of a pain in the ass as they are to deal with, it'd make the whole key revocation/renewal thing much easier. And it'd be a whole lot more secure than me asking my friends to sign my key via E-mail.
Who do you trust? (Score:2)
It isn't that complex to do it right, but as we all know, it's the human factors that get you. I'm sure GnuPG has all the functions necessary to implement it, but you need a trusted party with rock solid proceedures to ensure the top of the chain. What do people do for a CA for their signatures?
As long as you can be certain that: 1) You have the correct public key for the signing authority, and 2) nobody but the signing authority can get access to the corresponding private key. You can do it yourself by generating a key set for your own CA to a floppy and then making signing keys for yourself and your friends from there. You only need the public key to make a certificate, so a friend can email it to you, you get out your floppy and sign with GnuPG, and send the cert back. Keeping your signing keys off-line is a good idea too (if your paranoid, but who can afford not to be with this stuff going on).
Now, the only point that can be attacked is to compromise the CA's signing certificate (This is the CA's public key, signed by itself). If you squirl away a copy of it and get a new copy from time to time to double check you should be completely safe. You could use a public CA, but the commercial ones tend to charge a lot, so it would be nice to have a cooperative CA that does it on the cheap, but still does it well (Does such a thing exist?). Since someone is obviously getting their jollies by compromising distributions on public ftp servers, I'd be a little careful about setting this up. As long as the root signing key is safe (This is the private key), you can make lots of copies of the root certificate (on differenct servers, of course) and verify them with each other periodically.
With all of this in place it should be a simple matter to script the verification of signed signatures. I know I'm not the only person who knows how to do this correctly, so perhaps this is already done. If not, it looks like an excellent project for someone wanting to do this stuff.
Re:No worries! (Score:2)
Re:No worries! (Score:2)
Does any one know (Score:2, Interesting)
I wonder how many admins download/install packages, go on vacation (missing all the warnings), and simply never hear of the problem.
I think it would be interesting to see some statistics on this topic.
Hardly news ... (Score:5, Insightful)
Sendmail is such a complex beast that, no matter how much you personally know about it, there are always things in there that you don't know about or understand.
So it has always been full or Trojan Horses.
This is the fundamental thing that's wrong with building a hugs program that tries to do everything possible. Pretty much all the other mail tools are better at sendmail in this respect, because they only try to be a mail tool.
Sendmail, OTOH, is an emulator for a rather complex sort of machine language. Some time back, someone demonstrated that it was possible to emulate a Turing machine with a sendmail.cf file. Impressive as this may be technically, it's way overkill for the task, and it shouldn't be any surprise to anyone when problems turn up in sendmail and aren't discoverted for a while.
It's guaranteed that there are others lurking inside that monster.
Re:Hardly news ... (Score:5, Funny)
Not quite.
A Trojan Horse is defined as a big wooden horse which sat outside the ancient city of Troy, just large enough to happily contain 700 greeks in full battle dress and still leave adequate room for toilet facilities.
For more information read Homers's Iliad.
Re:Hardly news ... (Score:2)
Well, yeah; I often tell people that all the programs that I write contain THs. For example, I usually include a number of debug hooks that jack up the verbosity. Most users don't want to know about these things, so I only document then down at the end of the man page, where it won't be seen. So to most users, my programs can suddenly start writing huge log files that they weren't expecting.
I also often include code that isn't quite working yet, and only enabled via some command-line flag that isn't documented. I can tell a few select beta testers about it. To everyone else, such things are TH code.
People do write a lot about such things without ever making their definitions clear. It can be fun to make up a "reasonable" definition and see if you can argue that it applies to your own stuff.
Ah... (Score:2, Insightful)
Hmmm. Except this looks a bit uglier.
Of course, the headline for that was very different. A bit more, let's say, sensationalistic. Yeah, that's the word I was looking for.
Re:Ah... (Score:2)
The script worm you are referring to was found in an html help file which was a native language translation done by a third party and inadequately checked by MS before mastering the cd. You couldn't get infected by installing
It just goes to show that there is no such thing as 100% secure. I can be really bad about not checking signatures on source I download before compiling/installing.
So how do I fix it? (Score:3, Insightful)
Also, the CERT advisory doesn't give any fixes, it just gives the signatures. It doesn't seem like installing a good version would eliminate the trojan.
Re:So how do I fix it? (Score:2)
I would mod you higher, but since I modded down Alan Cox I've never had mod points again. He was offtopic though.
*yawn* (Score:4, Insightful)
It's quite simple... software can be infected by viruses, open source, closed source, any operating system or language. Just because today it's Sendmail that took a hit doesn't mean that it couldn't be qmail tomorrow.
If you got a virus, don't blame it on the software you downloaded, blame it on yourself for not validating it first.
Huge applications are bad. (Score:2)
Putting software on secure servers or better to put them on a community server would be nice. I can understand that coders dont want to tinker on their servers when they want to code but why not get some help?
qmail anyone? :) (Score:2, Interesting)
I realize that qmail wouldn't solve the problem of modified tarballs that allow trojans to come alive during builds (that's what md5s are for), but if you're really worried about security you'd probably be using qmail [cr.yp.to] anyway. If you can prove me, the author, and everyone else who has a qmail fetish wrong, there's a prize in it for you.
After the number of open e-mail relays I've had to deal with, sendmail leaves a sour taste in my mouth. Using the blacklist that has no real regulation on it doesn't seem to help, either. Closing a relay makes users upset. Sendmail is a lose-lose situation, and now there's a trojan in it to top it off. Wee!
Re:qmail anyone? :) (Score:2)
Re:qmail anyone? :) (Score:2)
obua.org [obua.org]
They have a script for FreeBSD too but I prefer:
Matt Simerson's Qmail Toaster
I've got a couple sites running Qmail, djbdns (tinydns, dnscache, etc), courier, and sqwebmail/squirrelmail and it simply rocks. It is a bit of pain to get installed but the actual configuration of the software itself is so simple it is worth the pain. Bind vs tindydns config files are simply hilarious because the tindydns one is just so damn simple! Qmail is much the same.
Re:qmail anyone? :) (Score:2)
Doh...
Re:qmail anyone? :) (Score:4, Informative)
>deal with, sendmail leaves a sour taste in my
>mouth.
Sendmail hasn't allowed relaying at all for about five years unless you explicitely turn it on. In otherwords, blame site admins, not Sendmail.
Matt
I got the bastard's IP (Score:3, Informative)
Re:I got the bastard's IP (Score:3, Interesting)
Decisionism Inc. (ACLUE2-DOM)
4260 E. Evans Ave.
Denver, CO 80222
US
Domain Name: ACLUE.COM
Administrative Contact, Technical Contact:
Klein, Eli (NCMGTMOSXI) elijah@firstlink.com
4260 E. Evans Ave.
Denver, CO 80222
US
no phone no fax
Record expires on 17-Dec-2003.
Record created on 17-Dec-1998.
Database last updated on 8-Oct-2002 23:09:51 EDT.
Domain servers in listed order:
NS3.FIRSTLINK.COM 66.37.141.4
DENVER.FIRSTLINK.COM 66.37.143.67
Any chance this isn't the guy responsible (i.e., Eli had his machine h4x0r3d)? Talk about an ironic choice of domain names.... At least he's running Apache [aclue.com].
Re:I got the bastard's IP (Score:3, Interesting)
previous post is from eli, yes, this is the owner of 66.37.138.99 *gasp*, and more importantly, no i'm not involved in the backdooring of sendmail in any way.
Infects the BUILD machine (Score:2)
It is important to understand that the compromise is to the system that is used to build the Sendmail software and not to the systems that run the Sendmail daemon. Because the compromised system creates a tunnel to the intruder-controlled system, the intruder may have a path through network access controls.
I guess that would mean that just downloading the correct sources and recompiling isn't enough to right an infected machine. Does anyone have any details about what specifically this does (and how to get rid of it)? Does it install some binary? Run some daemon created as part of the build process? The advisory doesn't seem to say much (other than point to a generic set of recovery instructions [cert.org], albeit pretty good ones).
Time to evaluate existing checking mechanism (Score:2)
Some people recommend PGP - to be more precise, public-key encryption and digital signature. However, we'd get into a similar situation when the public key itself is not from the legitimate owner of the package(impersonating during the process).
May be we should start introducing PKI(more info [pkiguru.com]) in the distributing of open source packages. However, issuing a CA costs money, which is not very desirable for opensource development.
I've been heard of some effort in issuing CA for opensource projects. Then again, the costs implied in CA does not mainly lie in the issuing, administrating or distributing the CA, it's the legal liability that we pay for. If there's no legal liability in opensource CA, then we lost the whole point of introducing PKI into the packages distributing process.
I'm sure people are working on a feasible solution to this problem. We must really do something when more and more people using opensource software.
There are solutions... (Score:2)
A trivial approach is for program distributors to keep on a SEPARATE machine the file that's being distributed, and then periodically send copies up. That way, if a single file is modified, it will get "unmodified". A sophisticated cracker can subvert this, but it takes more effort.
A trivial approach for users is to wait a number of days between (1) download and (2) getting the MD5 checksum or PGP key. That delay gives the original distributor time to detect a problem. Then, use the MD5 checksum or PGP key to detect if the program is actually the right one.
These approaches don't solve all attacks, but they do make attacks harder. Clearly, it would be better if PGP keys were distributed either via some trusted path and/or via ahead-of-time (like the ports system does).
Perhaps my Easy email security approach [dwheeler.com] could be implemented, which would also make it easy to quickly get keys. In my approach, I propose using DNSSEC (DNS security) to get a trusted path to a remote LDAP server, and then use LDAP to retrieve key. That way, you don't need to pay big bucks for a separate certificate... you can get your certificate when you register for your domain name, and then manage all the other keys yourself.
Stop Supporting MD5 Checksums!! (Score:5, Interesting)
The previous version of MD5, MD4, was so flawed it is now considered "broken". "Dobbertin [Dob95] has shown how collisions for the full version of MD4 can be found in under a minute on a typical PC... Clearly, MD4 should now be considered broken. [rsasecurity.com]".
SHA1, while of the same family of hashes as MD4 and MD5, remains uncompromised by any research discoveries, and is widely used in many applications requiring the highest levels of security.
Gnutella, the File Sharing Protocol, uses SHA1 over MD5 for the same reasons I state here. A developer of Bitzi [bitzi.com] (the Metadata/Hash catalog) has also recommended to the Gnutella Developer Forum not to use MD5 [yahoo.com], but SHA1 instead. Thus, people should be using SHA1 instead of MD5. I've noticed some major websites and companies are using MD5 hash's now, such as Adobe and Roxio. I would recommend to them to change them to SHA1 instead, since Gnutella supports it (and the fact that it is a much more secure and stronger hash algorithm)... and they can use MAGNET URI's to link to the files on Gnutella.
Read and realize what's going on before you post! (Score:5, Insightful)
READ THE ARTICLE AND REALIZE WHAT IS GOING ON!
It says that:
The FTP-server of sendmail.org was compromised.
It doesn't say that:
- somebody commited code to the CVS server.
- nobody reads the commitlog of the CVS server.
It says that:
The sendmail-distribution was trojaned.
It doesn't say that:
- sendmail itself was trojaned
- there are trojans inside sendmail
- qmail/postfix is better because it isn't trojaned.
- exchange is better because the source is closed. It's the distribution which is corrupted, not the software.
It says that:
The correct MD5-checksum is
It doesn't say that:
- with PGP signing it wouldn't be prevented. Security is a process, you need to follow the rules or you are not secure. You should check all checksum/signatures you have, preferable from independant resources (e.g. one from sendmail.com and one from your unix-distribution).
Next time, please read the article and realize what's going on before you post (apologies to the people who actually did
Edwin (yes, the guy from the OpenSSH trojan)
OpenBSD not affected: (Score:4, Informative)
The backdoor code (Score:5, Informative)
This was diff'd from a previously downloaded tar ball that we were using for analysis of another bug.
Re:The backdoor code (Score:2)
Why Mail Shouldn't Run As Root! (Score:5, Informative)
Scorched earth policy on bad distros? (Score:4, Insightful)
Re:We knew... (Score:2)
(Except this wasn't due to any vulnerability within the software itself -- it looks like it was a lapse in the security of the sendmail project's server.)
Re:this is why you cannot trust OSS (Score:2, Informative)
Re:A Sad Day for Egg Troll (Score:4, Insightful)
Re:A Sad Day for Egg Troll (Score:3, Funny)
Re:Upgrade? (Score:2)
Could you let us know the IP address so we can all put that "swiss cheese" server in our blacklists?
Simply buy the book that's available. (Score:2)
Buy the book, you'll thank me later. QMail is great but it's a very detailed process of installing all the associated s/w. relay-ctrl is critical as well (to avoid becoming a spam server for "Smoking your way thin" and "Get confident stupid!" seminars (ahhh I miss Troy McClure).
OU 17 TX 10
Re:Sendmail is now worthless, instead (Score:2)
>program written by a person with the same level of
>maturity and social skills as a mentally retarded
>5 year-old.
Don't forget "that hasn't had a new release in over four years and neglects to implement a lot of basic standards like authentication or encryption".
Matt
Re:How the heck? (Score:2)
Noone will be putting trojans on my chips!
Re:LMAO! (Score:4, Funny)
>another sendmail problem.
Yeah, and if someone breaks into your house and pees on your carpet, it's yet another carpet problem.
Matt
Re:LMAO! (Score:2)
That carpet... it really tied the room together, man.
</ lebowski quote>
Re:LMAO! (Score:2)
Matt