CVE-1999-0144

• BID:2237
• URL:http://www.securityfocus.com/bid/2237
• BUGTRAQ:19970612 Re: Denial of service (qmail-smtpd)
• URL:http://marc.info/?l=bugtraq&m=87602558319029&w=2
• BUGTRAQ:19970612 qmail-dos-2.c, another denial of service attack
• URL:http://marc.info/?l=bugtraq&m=87602558319024&w=2
• MISC:http://cr.yp.to/qmail/venema.html
• MISC:http://www.ornl.gov/its/archives/mailing-lists/qmail/1997/06/threads.html
• XF:qmail-rcpt(208)
• URL:https://exchange.xforce.ibmcloud.com/vulnerabilities/208

 Christey> DUPE CVE-1999-0418 and CVE-1999-0250?
 Christey> Dan Bernstein, author of Qmail, says that this is not a
   vulnerability in qmail because Unix has built-in resource
   limits that can restrict the size of a qmail process; other
   limits can be specified by the administrator.  See
   http://cr.yp.to/qmail/venema.html
   
   Significant discussion of this issue took place on the qmail
   list.  The fundamental question appears to be whether 
   application software should set its own limits, or rely
   on limits set by the parent operating system (in this case,
   UNIX).  Also, some people said that the only problem was that
   the suggested configuration was not well documented, but this
   was refuted by others.
   
   See the following threads at
   http://www.ornl.gov/its/archives/mailing-lists/qmail/1997/06/threads.html
   "Denial of service (qmail-smtpd)"
   "qmail-dos-2.c, another denial of service"
   "[PATCH] denial of service"
   "just another qmail denial-of-service"
   "the UNIX way"
   "Time for a reality check"
   
   Also see Bugtraq threads on a different vulnerability that
   is related to this topic:
   BUGTRAQ:19990903 Web servers / possible DOS Attack / mime header flooding
   http://archives.neohapsis.com/archives/bugtraq/1998_3/0742.html
 Baker> http://cr.yp.to/qmail/venema.html
   Berstein rejects this as a vulnerability, claiming this is a slander campaign by Wietse Venema.
   His page states this is not a qmail problem, rather it is a UNIX problem
   that many apps can consume all available memory, and that the administrator
   is responsible to set limits in the OS, rather than expect applications to
   individually prevent memory exhaustion.  CAN 1999-0250 does appear to
   be a duplicate of this entry, based on the research I have done so far.
   There were two different bugtraq postings, but the second one references
   the first, stating that the new exploit uses perl instead of shell scripting
   to accomplish the same attack/exploit.
 Baker> http://www.securityfocus.com/archive/1/6970
   http://www.securityfocus.com/archive/1/6969
   http://cr.yp.to/qmail/venema.html
   
   Should probably reject CVE-1999-0250, and add these references to this
   Candidate.
 Baker> http://www.securityfocus.com/bid/2237
 CHANGE> [Baker changed vote from REVIEWING to ACCEPT]
 Christey> qmail-dos-1.c, as published by Wietse Venema (CVE-1999-0250)
   in "BUGTRAQ:19970612 Denial of service (qmail-smtpd)", does not
   use any RCPT commands.  Instead, it sends long strings
   of "X" characters.  A followup by "super@UFO.ORG" includes
   an exploit that claims to do the same thing; however, that
   exploit does not send long strings of X characters - it sends
   a large number of RCPT commands.  It appears that super@ufo.org
   followed up to the wrong message.
   
   NOTE: the ufo.org domain was purchased by another party in
   2003, so the current owner is not associated with any
   statements by "super@ufo.org" that were made before 2003.
   
   qmail-dos-2.c, as published by Wietse Venema (CVE-1999-0144)
   in "BUGTRAQ:19970612 qmail-dos-2.c, another denial of service attack"
   sends a large number of RCPT commands.
   
   ADDREF BID:2237
   ADDREF BUGTRAQ:19970612 qmail-dos-2.c, another denial of service attack
   ADDREF BUGTRAQ:19970612 Re: Denial of service (qmail-smtpd)
   
   Also see a related thread:
   BUGTRAQ:19990308 SMTP server account probing
   http://marc.theaimsgroup.com/?l=bugtraq&m=92100018214316&w=2
   
   This also describes a problem with mail servers not being able
   to handle too many "RCPT TO" requests.  A followup message
   notes that application-level protection is used in Sendmail
   to prevent this:
   BUGTRAQ:19990309 Re: SMTP server account probing
   http://marc.theaimsgroup.com/?l=bugtraq&m=92101584629263&w=2
   The person further says, "This attack can easily be
   prevented with configuration methods."