RE: qmail 2.0 exploit
You know you guys are all assuming a lot. Who even says there will be a new version of qmail. qmail 1.03 is a very stable product... and stable is good in the linux world... just wish other venders would be willing to produce a product that was stable and then not muck with it until something truly useful is added. I'm sick and tired up updating software because one user needs that "neat new toe clipping option". David -Original Message- From: Brett Randall [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 04, 2001 3:15 AM To: Ian Lance Taylor Cc: Jason Brooke; [EMAIL PROTECTED] Subject: Re: qmail 2.0 exploit On 02 Mar 2001, [EMAIL PROTECTED] wrote: Dan could fix this by releasing qmail-1.03.1 with different installation instructions. Of course, if he did, some people would take that to be an admission that there actually is a security hole in qmail-1.03. Who cares what other people think? If he (Dan) is giving out a product which is even better and easier to set up than his last version, then who cares about the reasons? What are we doing? Making software design a sentimental practice? I say just stick LWQ into qmail-1.whatever-is-next, and then all alleged bug reports, whether true or not (which can be debated until the end of time - ask yourself if it possible for both sides to agree. It is human nature that they won't) will be old news. -- "People say Microsoft payed $14M for using the Rolling Stones song 'Start me up' in their commercials. This is wrong. Microsoft payed $14M only for a part of the song. For instance, they didn't use the line 'You'll make a grown man cry'."
Re: qmail 2.0 exploit
On Sun, Mar 04, 2001 at 07:14:59PM +1100, Brett Randall wrote: On 02 Mar 2001, [EMAIL PROTECTED] wrote: Dan could fix this by releasing qmail-1.03.1 with different installation instructions. Of course, if he did, some people would take that to be an admission that there actually is a security hole in qmail-1.03. Who cares what other people think? If he (Dan) is giving out a product which is even better and easier to set up than his last version, then who cares about the reasons? What are we doing? Making software design a sentimental practice? hi. im new to the list...just read the topic. someone gimme infos about this exploit. which part of the source is vulnerable ? which file ? line ? any fix ? who is working on an exploit ? skyper -- PGP: dig @segfault.net skyper axfr|grep TX|cut -f2 -d\"|sort|cut -f2 -d\;
Re: qmail 2.0 exploit
skyper [EMAIL PROTECTED] wrote: im new to the list...just read the topic. Not well enough, evidently. someone gimme infos about this exploit. There isn't one. It was a hypothetical argument. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: qmail 2.0 exploit
On 02 Mar 2001, [EMAIL PROTECTED] wrote: Dan could fix this by releasing qmail-1.03.1 with different installation instructions. Of course, if he did, some people would take that to be an admission that there actually is a security hole in qmail-1.03. Who cares what other people think? If he (Dan) is giving out a product which is even better and easier to set up than his last version, then who cares about the reasons? What are we doing? Making software design a sentimental practice? I say just stick LWQ into qmail-1.whatever-is-next, and then all alleged bug reports, whether true or not (which can be debated until the end of time - ask yourself if it possible for both sides to agree. It is human nature that they won't) will be old news. -- "People say Microsoft payed $14M for using the Rolling Stones song 'Start me up' in their commercials. This is wrong. Microsoft payed $14M only for a part of the song. For instance, they didn't use the line 'You'll make a grown man cry'."
Re: qmail 2.0 exploit
S'ok, it's no quibble - it's worth discussing the docs a little since it's what the docs allegedly fail to do, that some of the arguments hinge on. I disagree with the idea that a reasonable read of the docs would lead you to install Qmail under inetd. I believe that a reasonable read of the docs would lead you to install it under tcpserver. Right after the instruction to run 'make setup check', the INSTALL file says 'Read INSTALL.ctl and FAQ'. Heading 5 in FAQ (which is visible on the first page unless you're running a very small window) says 'Setting up servers'. If you jump to heading 5 by doing say '/ Setting' in vi you get taken straight to a section which begins by saying: '5.1. How do I run qmail-smtpd under tcpserver? inetd is barfing at high loads, cutting off service for ten-minute stretches. I'd also like better connection logging. Answer: First, install the tcpserver program, part of the ucspi-tcp package (http://pobox.com/~djb/ucspi-tcp.html). Second, remove the smtp line from /etc/inetd.conf, and put the line tcpserver -u 7770 -g 2108 0 smtp /var/qmail/bin/qmail-smtpd into your system startup files.' This is before you come to the part of the INSTALL file that instructs how to run it from inetd - which, incidentally, is only shown under the heading 'To upgrade from sendmail to qmail:' So to sum up, I really don't agree that anyone who thinks the INSTALL file is telling them to use inetd has done a reasonable read. They've actually only done a skim - and that's only the people actually upgrading from sendmail. People installing fresh have no reason whatsoever to even make the mistake of using inetd even if they skimmed. That's all well and good though, until your comment about tcpserver not preventing this DOS. If this is true then I have to withdraw. I run qmail under tcpserver on variety of slackware 7.1 installs and and a couple of slackware 4.0 installs, and none of these are affected by this DOS. There may be some limit in place on slackware 4.0/7.1 that I don't know about - but I haven't put any in myself. I've also seen other services spiral up the loadavg at an alarming rate under certain conditions until the box practically grinds to a halt, so this limit must be very selective if it exists :) jason - Original Message - From: "Ian Lance Taylor" [EMAIL PROTECTED] To: "Jason Brooke" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 02, 2001 6:01 PM Subject: Re: qmail 2.0 exploit I would say that that is a mere quibble, except that it isn't even that. It isn't tcpserver which prevents qmail-smtpd from growing without bound; it is softlimit. softlimit isn't mentioned in the INSTALL file or the FAQ which is distributed with qmail 1.03. The daemontools are mentioned, but not in the context of resource limits. Obviously there isn't anything wrong with qmail. And obviously these bug reports are highly misleading in implying that there is a bug which needs to be fixed in qmail. But I do think that the bug reports have a point: if you install qmail-1.03 according to a reasonable reading of the instructions which come with the tar file, your system may be vulnerable to a theoretical denial of service attack. The fact that other people tell you to install qmail in a different way is interesting, but does not change the fact that qmail-1.03 comes with installation instructions which at least some people will naturally follow. I certainly did in my first qmail installation. Dan could fix this by releasing qmail-1.03.1 with different installation instructions. Of course, if he did, some people would take that to be an admission that there actually is a security hole in qmail-1.03. Ian
Re: qmail 2.0 exploit
Ian Lance Taylor [EMAIL PROTECTED] writes: Obviously there isn't anything wrong with qmail. And obviously these bug reports are highly misleading in implying that there is a bug which needs to be fixed in qmail. But I do think that the bug reports have a point: if you install qmail-1.03 according to a reasonable reading of the instructions which come with the tar file, your system may be vulnerable to a theoretical denial of service attack. The fact that other people tell you to install qmail in a different way is interesting, but does not change the fact that qmail-1.03 comes with installation instructions which at least some people will naturally follow. I certainly did in my first qmail installation. Even if you *do* use softlimit to block that *particular* issue, you are *still* subject to various theoretical DOS attacks. *Any* server is subject to theoretical DOS attacks. -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: qmail 2.0 exploit
"Jason Brooke" [EMAIL PROTECTED] writes: That's all well and good though, until your comment about tcpserver not preventing this DOS. If this is true then I have to withdraw. I run qmail under tcpserver on variety of slackware 7.1 installs and and a couple of slackware 4.0 installs, and none of these are affected by this DOS. There may be some limit in place on slackware 4.0/7.1 that I don't know about - but I haven't put any in myself. I've also seen other services spiral up the loadavg at an alarming rate under certain conditions until the box practically grinds to a halt, so this limit must be very selective if it exists :) The DoS attack is based on growing the memory used by an instance of qmail-smtpd, so that it fills up the available swap space. It is softlimit which prevents that growth, not tcpserver. softlimit can be used with the -m option to set a limit on the amount of memory space which the child process may obtain. For more information, see http://cr.yp.to/daemontools/softlimit.html http://cr.yp.to/docs/resources.html Also, note the use of softlimit in Life With Qmail in the /var/qmail/supervise/qmail-smtpd/run file. Ask yourself why it is there. Note that the load average is not affected by this DoS, except indirectly as programs get swapped out. I don't know how you were running qmail under tcpserver, so I don't know whether there was a memory limit. I also don't know what limits Slackware may apply normally. A process started at boot time by root typically does not have a memory limit on most Unix systems. If you use bash, you can run the builtin `ulimit -a' to see what memory limits are applied to your process. As I said in my original post, when the Linux kernel runs out of swap space, it will randomly kill a user process. It is reasonably likely that it will kill the large qmail-smtpd, since on an otherwise stable system that will typically be the process requesting more memory. In that case, you aren't going to see a serious DoS. You will just see a qmail-smtpd get larger and larger and larger until it suddenly dies. While it is large, your system may slow down due to increased swapping. If you are unfortunate enough to have the kernel kill some other process, you may see more serious consequences. Ian
Re: qmail 2.0 exploit
David Dyer-Bennet [EMAIL PROTECTED] writes: Ian Lance Taylor [EMAIL PROTECTED] writes: Obviously there isn't anything wrong with qmail. And obviously these bug reports are highly misleading in implying that there is a bug which needs to be fixed in qmail. But I do think that the bug reports have a point: if you install qmail-1.03 according to a reasonable reading of the instructions which come with the tar file, your system may be vulnerable to a theoretical denial of service attack. The fact that other people tell you to install qmail in a different way is interesting, but does not change the fact that qmail-1.03 comes with installation instructions which at least some people will naturally follow. I certainly did in my first qmail installation. Even if you *do* use softlimit to block that *particular* issue, you are *still* subject to various theoretical DOS attacks. *Any* server is subject to theoretical DOS attacks. Well, sure. This whole thing is not an engineering issue. It is a political issue. (I don't personally find it surprising that somebody with the personality that DJB displays on the Internet is the target of political attacks.) I was just trying to look at the bug reports to see whether they were complete fabrications. I happen to think that they do have a vague connection to reality. That doesn't mean that this is an significant issue. As I said above, ``Obviously there isn't anything wrong with qmail.'' It just means that I believe that the bug reports are not complete fabrications. DJB's earlier message asked whether people would be willing to testify in court, suggesting that he may be thinking of bringing a court case. If he is indeed thinking of this, I would urge him to not do it. I expect, since the bug reports are not actually lies, that he would lose. Ian
Re: qmail 2.0 exploit
I get the feeling this would've already been well and truly covered on this list, but just out of curiosity I tried it anyway. On slackware 7.1 installed in vmware under win2k pro and slackware 7.1 on 2 other 'real' machines, all it did was chew cpu and cause qmail-smtpd to chew some cpu as well. 'top' showed about 48 in the %CPU column for both. I let it run for about 15 minutes - as far as I could tell from the output of 'free', swap wasn't affected in the slightest. Mail still worked fine - both 'real' machines host around 800 vhosts, each with their own virtual mail domains. It's a free hosting setup for computer gamers in Australia - they are generally very quick to complain when something goes wrong ;) but not a peep from them while I was doing those quick tests What is this qmail version 2.0 that securityfocus.com claims there is an explot for? Am I missing something, or are they? Being that I have better things to do than to try to screw up my mail server, has anyone tried this claimed explot? What really happens? --Pete
Re: qmail 2.0 exploit
actually for what it's worth, if you follow the directions in INSTALL you should generally hit the 'read FAQ' before getting down to the section of INSTALL that says to use inetd (for upgrading from sendmail):) FAQ pretty much points you at tcpserver - Original Message - From: "Ian Lance Taylor" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 01, 2001 2:59 PM Subject: Re: qmail 2.0 exploit Peter Cavender [EMAIL PROTECTED] writes: What is this qmail version 2.0 that securityfocus.com claims there is an explot for? Am I missing something, or are they? Being that I have better things to do than to try to screw up my mail server, has anyone tried this claimed explot? What really happens? It depends upon how you run qmail-smtpd. There are several variables. If you run qmail-smtpd directly from inetd.conf, as suggested in the INSTALL file distributed with qmail-1.03, then there is a pretty good chance that the instance of qmail-smtpd being attacked will grow to eat of all of memory. What happens then depends upon your OS. On GNU/Linux, a random process will be killed; there is a pretty good chance that the random process will be the large qmail-smtpd. Alternatively, a careful attacker who really understands your system can create several fairly large qmail-smtpd processes and significantly increase the chance that the random process which is killed will be something other than qmail-smtpd. In this scenario this attack can indeed be a denial of service. If you run qmail-smtpd as suggested in Life With Qmail, then you are not vulnerable to this attack, because qmail-smtpd is run under the softlimit program to limit the amount of memory it will allocate. (This does not affect the size of the mail messages it can accept, as qmail-smtpd does not store mail messages in memory.) Ian
Re: qmail 2.0 exploit
"Jason Brooke" [EMAIL PROTECTED] writes: If you run qmail-smtpd directly from inetd.conf, as suggested in the INSTALL file distributed with qmail-1.03, then there is a pretty good chance that the instance of qmail-smtpd being attacked will grow to eat of all of memory. What happens then depends upon your OS. On GNU/Linux, a random process will be killed; there is a pretty good chance that the random process will be the large qmail-smtpd. Alternatively, a careful attacker who really understands your system can create several fairly large qmail-smtpd processes and significantly increase the chance that the random process which is killed will be something other than qmail-smtpd. In this scenario this attack can indeed be a denial of service. actually for what it's worth, if you follow the directions in INSTALL you should generally hit the 'read FAQ' before getting down to the section of INSTALL that says to use inetd (for upgrading from sendmail):) FAQ pretty much points you at tcpserver I would say that that is a mere quibble, except that it isn't even that. It isn't tcpserver which prevents qmail-smtpd from growing without bound; it is softlimit. softlimit isn't mentioned in the INSTALL file or the FAQ which is distributed with qmail 1.03. The daemontools are mentioned, but not in the context of resource limits. Obviously there isn't anything wrong with qmail. And obviously these bug reports are highly misleading in implying that there is a bug which needs to be fixed in qmail. But I do think that the bug reports have a point: if you install qmail-1.03 according to a reasonable reading of the instructions which come with the tar file, your system may be vulnerable to a theoretical denial of service attack. The fact that other people tell you to install qmail in a different way is interesting, but does not change the fact that qmail-1.03 comes with installation instructions which at least some people will naturally follow. I certainly did in my first qmail installation. Dan could fix this by releasing qmail-1.03.1 with different installation instructions. Of course, if he did, some people would take that to be an admission that there actually is a security hole in qmail-1.03. Ian
qmail 2.0 exploit
What is this qmail version 2.0 that securityfocus.com claims there is an explot for? Am I missing something, or are they? Being that I have better things to do than to try to screw up my mail server, has anyone tried this claimed explot? What really happens? --Pete
Re: qmail 2.0 exploit
Peter Cavender [EMAIL PROTECTED] writes: What is this qmail version 2.0 that securityfocus.com claims there is an explot for? Am I missing something, or are they? Being that I have better things to do than to try to screw up my mail server, has anyone tried this claimed explot? What really happens? It depends upon how you run qmail-smtpd. There are several variables. If you run qmail-smtpd directly from inetd.conf, as suggested in the INSTALL file distributed with qmail-1.03, then there is a pretty good chance that the instance of qmail-smtpd being attacked will grow to eat of all of memory. What happens then depends upon your OS. On GNU/Linux, a random process will be killed; there is a pretty good chance that the random process will be the large qmail-smtpd. Alternatively, a careful attacker who really understands your system can create several fairly large qmail-smtpd processes and significantly increase the chance that the random process which is killed will be something other than qmail-smtpd. In this scenario this attack can indeed be a denial of service. If you run qmail-smtpd as suggested in Life With Qmail, then you are not vulnerable to this attack, because qmail-smtpd is run under the softlimit program to limit the amount of memory it will allocate. (This does not affect the size of the mail messages it can accept, as qmail-smtpd does not store mail messages in memory.) Ian
Re: qmail 2.0 exploit
On Wed, 28 Feb 2001, Peter Cavender wrote: What is this qmail version 2.0 that securityfocus.com claims there is an explot for? Am I missing something, or are they? Being that I have better things to do than to try to screw up my mail server, has anyone tried this claimed explot? What really happens? We all do. Last I checked (less than one minute ago) there is no qmail-2.0. It appears to be someone acting like an asshole and trying to create something that doesn't exist. qmail is secure and I've been comfortable trusting Dan's software. Whatever it is I know Dan's on top of it (based on something he sent earlier) and he'll get all the help he needs from all of us. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
