Don't know if qmailtoaster already has been mentioned. It's really
easy to
From postfix-users@
Georgi Guninski have found a remotely-exploitable security hole in qmail. http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html
D. Bernstein denied the claim, classified it as "portability problem" and refused to pay the prize. http://cr.yp.to/qmail/guarantee.html
Qmail's ML responded nervously to Guninski's post. Like everytime when anyone dare to say anything negative about qmail... It's quite interesting: "I said that Guninski's dick isn't half as big as he's trying to claim." "Go masturbate somewhere else." "Learn to read, moron."
Link - http://tinyurl.com/caooe
----
Ooh, I am so worried.
My 16GB RAM server runs qmail-smtpd with no memory limits out of inetd on a FreeBSD 5.0 box on Opteron hardware and now I am vulnerable.
The 'exploit' might be possible IF you explicitly give the qmail-smtpd process unlimited memory and you have more than 4GB RAM available and you also run on an Opteron with FreeBSD 5.0.
idiot postfix poster. There was hardly anything nervous on the list.
idiot postfix poster at it again. Yeah, yeah, just quote Len's offensive posts about Guninski's 'security advisory'.
Quite a few qmail old hands such as Russel Nelson (maintainer of www.qmail.org) wanted DJB to update his installation instructions so that inetd is no longer mentioned.
The thing does not work on Linux and besides,there is no inetd on CentOS so you will have no security problems with qmail/netqmail.
On Tue, Jun 21, 2005 at 02:48:41PM +0800, Feizhou wrote:
Ooh, I am so worried.
You might not be about this particular problem, but it *should* make you worried about the state of qmail in general -- unmaintained by the one person who can do anything about it, and legally unmaintainable by anyone else.
idiot postfix poster. There was hardly anything nervous on the list.
Well, depends if you call ad hominem attacks and a quick "discount-first, think-later" response as nervous. I might.
This is *exactly* the point -- except it applies to the whole project, not just the documentation.
Matthew Miller wrote:
what is wrong with qmail? There is also netqmail if you want something maintained.
I personally do not see anything wrong with it.
Since when did Leonard Budney come to represent the entire qmail list members? This guy was rabid all the way to the end too.
Many people do not share your view. They find qmail as it is perfectly acceptable. That includes large ISPs.
On Tue, Jun 21, 2005 at 10:51:52PM +0800, Feizhou wrote:
This is too off-topic to get into. For the purposes of CentOS, it's not open source, and therefore not really interesting to the project -- good or badness or other problems aside.
"idiot postfix poster"?
*shrug* They'll learn.
Feizhou wrote:
People do stupid things from time to time. And people also make stupid typos in config files from time to time. Esp. if they are newbees. So yes, some newbee that has oversized machine could give qmail-smtpd unlimited memory (or simply too much memory).
Blindly assuming something fits into 32-bits and not doing checks is a bug. It might be theoretical bug that will not manifest itself in normal, standard or whatever you want to call them configurations, but still bug. Qmail should either check its memory limit and refuse to run if it was given too much (so that things do not fit into 32-bits anymore), or it should do proper checks and/or use proper types to prevent overflows.
After all, there's that famous quote from Bill Gates: "640K ought to be enough for anybody". Who knows, maybe one day we'll be quoting qmail author instead: "32 bits ought to be enough for anybody".
Aleksandar Milivojevic wrote:
When does a newbie gets a monster box to play with? Any box running an Opteron with more than 4GB of RAM is going to be pricey...of course this is beside the point. Hence Russel Nelson's wish that DJB would update his documentation so that newbies who manage to get a working system just using the documentation that comes with the source tarball won't shoot themselves in the foot.
DJB has already stated a long time ago that this should be done by the OS or available tools.
http://cr.yp.to/docs/resources.html (linked to from http://cr.yp.to/qmail/guarantee.html cor, this page got an update...)
I highly doubt it since he said nothing of the sort.
Quoting Feizhou feizhou@graffiti.net:
When does a newbie gets a monster box to play with?
4 gigs of memory isn't as expensive as it used to be. Not that cheap that I would put 4 gigs into any of the computers in my basement. But not that expensive either. Complete AMD64 system is not that much more expensive then P4 system (other then processor and motherboard, all other components are exactly the same). So I'd say wast majority of newbies from rotten rich west can financialy afford a "monster box to play with".
DJB has already stated a long time ago that this should be done by the OS or available tools.
Whatever way you put it, the following is buggy code:
int foo; int *bar; foo = bar;
Yelling that limits were supposed to be setup on the system for your particular program so that bar always fits into foo is not going to save you from the fact that your programming practices were flawed! The above code fragment is probably the biggest single problem with many programs when Alpha processors were introduced. And now we see it again.
Now I don't know if that "bug" in qmail fits the above description exactly, but I'm preaty darn sure it is something equivalent.
If you have such assumptions in the program, you either make checks at compile time to automatically configure your program to use properly sized types ("long foo; int *bar;" would work on AMD64, both are 64bit if program is compiled for 64bit environment), or you make checks during runtime.
I haven't said he did. It was a joke ;-)
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
alex@milivojevic.org wrote:
If you are referring to the 'problem #2 is exploitable at least on freebsd 5.4 amd64' code, it does not do anything of the sort.
int i; ... i = str_chr(cmd.s,' '); ... cmd.s[i] = 0;
str_chr returns 'unsigned int' not a pointer.
Why don't you look before you yammer.
If you did a compile of qmail, you will NEVER find any warnings about 'warning: assignment makes integer from pointer without a cast'
:)
Hi all,
Between two updates, I have the following difference in the ouptut log of the "rpm -Va" command
missing /usr/lib/rpmdb/i386-redhat-linux/CentOS/__db.001 missing /usr/lib/rpmdb/i386-redhat-linux/CentOS/__db.002 missing /usr/lib/rpmdb/i386-redhat-linux/CentOS/__db.003
........C /lib/ld-lsb.so.1 ........C /lib/ld-lsb.so.2
Does anybody knows why I have these missing files and why libraries are modified ?
I there a way with "rpm -Va" to know when the modifications where made ? (By adding another option ?)
Thank you,
Jean LEE
As this is pretty much off topic, I'll make this short. The qmailtoaster is installed with a default 6mb memory limit on smtpd, so this very theoretical security problem is pretty much eliminated.
Bruno S. Delbono sagde:
to pay the prize.
http://cr.yp.to/qmail/guarantee.html
Qmail's ML responded nervously to Guninski's post. Like everytime when anyone dare
to say anything negative about qmail... It's quite
interesting: "I said that Guninski's dick isn't half as big as he's trying to claim." "Go
masturbate somewhere else."
be clean.
!DSPAM:42b7b22b249767945598163!