<?xml version="1.0"?>
<cve xmlns="http://cve.mitre.org/cve/downloads/xml_schema_info.html" xmlns:cve="http://cve.mitre.org/cve/downloads/xml_schema_info.html" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://cve.mitre.org/cve/downloads/xml_schema_info.html cve_schema.xsd" schemaVersion="0.1">
<item type="CAN" name="CVE-1999-0001" seq="1999-0001">
<status>Candidate</status>
<phase date="20051217">Modified</phase>
<desc>ip_input.c in BSD-derived TCP/IP implementations allows remote attackers to cause a denial of service (crash or hang) via crafted packets.</desc>
<refs>
<ref source="CERT">CA-98-13-tcp-denial-of-service</ref>
<ref source="BUGTRAQ">19981223 Re: CERT Advisory CA-98.13 - TCP/IP Denial of Service</ref>
<ref source="CONFIRM" url="http://www.openbsd.org/errata23.html#tcpfix">http://www.openbsd.org/errata23.html#tcpfix</ref>
<ref source="OSVDB" url="http://www.osvdb.org/5707">5707</ref>
</refs>
<votes>
<modify count="1">Frech</modify>
<noop count="2">Northcutt, Wall</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">A Bugtraq posting indicates that the bug has to do with
&quot;short packets with certain options set,&quot; so the description
should be modified accordingly.

But is this the same as CVE-1999-0052?  That one is related
to nestea (CVE-1999-0257) and probably the one described in
BUGTRAQ:19981023 nestea v2 against freebsd 3.0-Release
The patch for nestea is in ip_input.c around line 750.
The patches for CVE-1999-0001 are in lines 388&amp;446.  So, 
CVE-1999-0001 is different from CVE-1999-0257 and CVE-1999-0052.
The FreeBSD patch for CVE-1999-0052 is in line 750.
So, CVE-1999-0257 and CVE-1999-0052 may be the same, though
CVE-1999-0052 should be RECAST since this bug affects Linux
and other OSes besides FreeBSD.</comment>
<comment voter="Frech">XF:teardrop(338)
This assignment was based solely on references to the CERT advisory.</comment>
<comment voter="Christey">The description for BID:190, which links to CVE-1999-0052 (a
FreeBSD advisory), notes that the patches provided by FreeBSD in
CERT:CA-1998-13 suggest a connection between CVE-1999-0001 and
CVE-1999-0052.  CERT:CA-1998-13 is too vague to be sure without
further analysis.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0004" seq="1999-0004">
<status>Candidate</status>
<phase date="19990621">Modified</phase>
<desc>MIME buffer overflow in email clients, e.g. Solaris mailtool and Outlook.</desc>
<refs>
<ref source="CERT">CA-98.10.mime_buffer_overflows</ref>
<ref source="XF">outlook-long-name</ref>
<ref source="SUN">00175</ref>
<ref source="MS" url="http://www.microsoft.com/technet/security/bulletin/ms98-008.asp">MS98-008</ref>
</refs>
<votes>
<accept count="8">Magdych, Northcutt, Wall, Baker, Landfield, Cole, Dik, Collins</accept>
<modify count="1">Frech</modify>
<noop count="1">Christey</noop>
<reviewing count="1">Shostack</reviewing>
</votes>
<comments>
<comment voter="Frech">Extremely minor, but I believe e-mail is the correct term. (If you reject
this suggestion, I will not be devastated.) :-)</comment>
<comment voter="Christey">This issue seems to have been rediscovered in
BUGTRAQ:20000515 Eudora Pro &amp; Outlook Overflow - too long filenames again
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=95842482413076&amp;w=2

Also see
BUGTRAQ:19990320 Eudora Attachment Buffer Overflow
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=92195396912110&amp;w=2</comment>
<comment voter="Christey"> 
CVE-2000-0415 may be a later rediscovery of this problem
for Outlook.</comment>
<comment voter="Dik">Sun bug 4163471,</comment>
<comment voter="Christey">ADDREF BID:125</comment>
<comment voter="Christey">BUGTRAQ:19980730 Long Filenames &amp; Lotus Products
URL:http://marc.theaimsgroup.com/?l=bugtraq&amp;m=90221104526201&amp;w=2</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0015" seq="1999-0015">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>Teardrop IP denial of service.</desc>
<refs>
<ref source="CERT">CA-97.28.Teardrop_Land</ref>
<ref source="XF">teardrop</ref>
</refs>
<votes>
<accept count="1">Wall</accept>
<modify count="1">Frech</modify>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">XF: teardrop-mod</comment>
<comment voter="Christey">Not sure how many separate &quot;instances&quot; of Teardrop there are.
See: CVE-1999-0015, CVE-1999-0104, CVE-1999-0257, CVE-1999-0258</comment>
<comment voter="Christey">See the SCO advisory at:
http://www.securityfocus.com/templates/advisory.html?id=1411
which may further clarify the issue.</comment>
<comment voter="Christey">MSKB:Q154174
MSKB:Q154174 (CVE-1999-0015) and MSKB:Q179129 (CVE-1999-0104)
indicate that CVE-1999-0015 was fixed in NT SP3, but
CVE-1999-0104 was not.  Thus CD:SF-LOC suggests that the
problems keep separate candidates because one problem appears
in a different version than the other.</comment>
<comment voter="Christey">BID:124
http://www.securityfocus.com/bid/124
Consider MSKB:Q154174
http://support.microsoft.com/support/kb/articles/q154/1/74.asp
Consider BUGTRAQ:19971113 Linux IP fragment overlap bug
http://www.securityfocus.com/archive/1/8014</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0020" seq="1999-0020">
<status>Candidate</status>
<phase date="20050204">Modified</phase>
<desc>** REJECT **  DO NOT USE THIS CANDIDATE NUMBER.  ConsultIDs: CVE-1999-0032.  Reason: This candidate is a duplicate of CVE-1999-0032.  Notes: All CVE users should reference CVE-1999-0032 instead of this candidate.  All references and descriptions in this candidate have been removed to prevent accidental usage.</desc>
<refs>
</refs>
<votes>
<modify count="1">Frech</modify>
<noop count="4">Levy, Northcutt, Wall, Shostack</noop>
<reject count="2">Christey, Baker</reject>
</votes>
<comments>
<comment voter="Frech">XF:lpr-bo</comment>
<comment voter="Christey">DUPE CVE-1999-0032, which includes XF:lpr-bo</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0030" seq="1999-0030">
<status>Candidate</status>
<phase date="19990623">Proposed</phase>
<desc>root privileges via buffer overflow in xlock command on SGI IRIX systems.</desc>
<refs>
<ref source="CERT">CA-97.21.sgi_buffer_overflow</ref>
<ref source="AUSCERT">AA-97.24.IRIX.xlock.buffer.overflow.vul</ref>
<ref source="XF">sgi-xlockbo</ref>
<ref source="SGI">19970508-02-PX</ref>
</refs>
<votes>
<accept count="3">Ozancin, Levy, Prosser</accept>
<noop count="1">Baker</noop>
<recast count="1">Frech</recast>
<reject count="1">Christey</reject>
</votes>
<comments>
<comment voter="Frech">XF:xlock-bo (also add)
As per xlock-bo, also appears on AIX, BSDI, DG/UX, FreeBSD, Solaris, and
several Linii.
Also, don't you mean to cite SGI:19970502-02-PX? The one you list is
login/scheme.</comment>
<comment voter="Levy">Notice that this xlock overflow is the same as in
CA-97.13. CA-97.21 simply is a reminder.</comment>
<comment voter="Christey">As pointed out by Elias, CA-97.21 states: &quot;For more
information about vulnerabilities in xlock... see CA-97.13&quot;
CA-97.13 = CVE-1999-0038.
This may also be a duplicate with CVE-1999-0306.

See exploits at:

http://marc.theaimsgroup.com/?l=bugtraq&amp;m=87602167418394&amp;w=2
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=87602167418404&amp;w=2

Sun also has this problem, at
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&amp;doc=secbull/150&amp;type=0&amp;nav=sec.sba</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0033" seq="1999-0033">
<status>Candidate</status>
<phase date="20040811">Modified</phase>
<desc>Command execution in Sun systems via buffer overflow in the at program.</desc>
<refs>
<ref source="CERT">CA-97.18.at</ref>
<ref source="SUN">00160</ref>
<ref source="XF">sun-atbo</ref>
</refs>
<votes>
<accept count="8">Hill, Northcutt, Wall, Baker, Cole, Dik, Shostack, Collins</accept>
<noop count="1">Christey</noop>
<recast count="1">Frech</recast>
</votes>
<comments>
<comment voter="Frech">This vulnerability also manifests itself for the following 
platforms: AIX, HPUX, IRIX, Solaris, SCO, NCR MP-RAS. In this light,
please add the following:
Reference: XF:at-bo</comment>
<comment voter="Dik">Sun bug 1265200, 4063161</comment>
<comment voter="Christey">ADDREF SGI:19971102-01-PX
ftp://patches.sgi.com/support/free/security/advisories/19971102-01-PX
SCO:SB.97:01
ftp://ftp.sco.com/SSE/security_bulletins/SB.97:01a</comment>
<comment voter="Christey">CIAC:F-15
http://ciac.llnl.gov/ciac/bulletins/f-15.shtml
HP:HPSBUX9502-023</comment>
<comment voter="Christey">Add period to the end of the description.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0061" seq="1999-0061">
<status>Candidate</status>
<phase date="19990630">Proposed</phase>
<desc>File creation and deletion, and remote execution, in the BSD line printer daemon (lpd).</desc>
<refs>
<ref source="NAI">NAI-20</ref>
<ref source="XF">bsd-lpd</ref>
</refs>
<votes>
<accept count="3">Hill, Northcutt, Frech</accept>
<recast count="1">Baker</recast>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">This should be split into three separate problems based on
the SNI advisory.  But there's newer information to further
complicate things.

What do we do about this one?  in 1997 or so, SNI did an
advisory on this problem.  In early 2000, it was still
discovered to be present in some Linux systems.  So an 
SF-DISCOVERY content decision might say that this is a
long enough time between the two, so this should be recorded
separately.  But they're the same codebase... so if we keep
them in the same entry, how do we make sure that this entry
reflects that some new information has been discovered?

The use of dot notation may help in this regard, to use one
dot for the original problem as discovered in 1997, and
another dot for the resurgence of the problem in 2000.</comment>
<comment voter="Baker">We should merge these.</comment>
<comment voter="Christey">Perhaps this should be NAI-19 instead of NAI-20?
The original Bugtraq post for the SNI advisory suggests SNI-19:
BUGTRAQ:19971002 SNI-19:BSD lpd vulnerability
URL:SNI-19:BSD lpd vulnerability

Also add:
BUGTRAQ:19971021 SNI-19: BSD lpd vulnerabilities (UPDATE)
URL:http://marc.theaimsgroup.com/?l=bugtraq&amp;m=87747479514310&amp;w=2

However, archives of &quot;NAI-0020&quot; point to the lpd vuln.

If I recall correctly, some of the NAI advisory numbers got
switched when NAI acquired SNI.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0076" seq="1999-0076">
<status>Candidate</status>
<phase date="19990925">Modified</phase>
<desc>Buffer overflow in wu-ftp from PASV command causes a core dump.</desc>
<refs>
<ref source="XF">ftp-args</ref>
</refs>
<votes>
<accept count="3">Ozancin, Baker, Frech</accept>
<noop count="1">Balinsky</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Balinsky">Don't know what this is.  Is this the LIST Core dump vulnerability?</comment>
<comment voter="Christey">Need to add more references and details.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0078" seq="1999-0078">
<status>Candidate</status>
<phase date="19990621">Modified</phase>
<desc>pcnfsd (aka rpc.pcnfsd) allows local users to change file permissions, or execute arbitrary commands through arguments in the RPC call.</desc>
<refs>
<ref source="CERT">CA-96.08.pcnfsd</ref>
<ref source="XF">rpc-pcnfsd</ref>
</refs>
<votes>
<accept count="5">Collins, Northcutt, Landfield, Frech, Shostack</accept>
<noop count="1">Baker</noop>
<recast count="1">Christey</recast>
</votes>
<comments>
<comment voter="Christey">This candidate should be SPLIT, since there are two separate
software flaws.  One is a symlink race and the other is a
shell metacharacter problem.</comment>
<comment voter="Christey">The permissions part of this vulnerability appears to
overlap with CVE-1999-0353</comment>
<comment voter="Christey">SGI:20020802-01-I</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0086" seq="1999-0086">
<status>Candidate</status>
<phase date="19990630">Interim</phase>
<desc>AIX routed allows remote users to modify sensitive files.</desc>
<refs>
<ref source="ERS">ERS-SVA-E01-1998:001.1</ref>
<ref source="XF">ibm-routed</ref>
</refs>
<votes>
<accept count="2">Northcutt, Shostack</accept>
<modify count="2">Prosser, Frech</modify>
<noop count="1">Baker</noop>
<reject count="1">Christey</reject>
</votes>
<comments>
<comment voter="Frech">Reference: XF:ibm-routed</comment>
<comment voter="Prosser">This vulnerability allows debug mode to be turned on which is
the problem.  Should this be more specific in the description? This
one also affects SGI OSes, ref SGI Security Advisory 19981004-PX which
is in the SGI cluster, shouldn't these be cross-referenced as the same
vuln affects multiple OSes.</comment>
<comment voter="Christey">This appears to be subsumed by CVE-1999-0215</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0088" seq="1999-0088">
<status>Candidate</status>
<phase date="19990617">Proposed</phase>
<desc>IRIX and AIX automountd services (autofsd) allow remote users to execute root commands.</desc>
<refs>
<ref source="ERS" url="http://www-1.ibm.com/services/brs/brspwhub.nsf/advisories/852567CC004F9038852566BF007B6393/$file/ERS-SVA-E01-1998_004_1.txt">ERS-SVA-E01-1998:004.1</ref>
</refs>
<votes>
<accept count="2">Northcutt, Shostack</accept>
<modify count="2">Prosser, Frech</modify>
<recast count="1">Baker</recast>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">ERS (and other references, BTW) explicitly stipulate 'local and
remote'.
Reference: XF:irix-autofsd</comment>
<comment voter="Prosser">Include the SGI Alert as well since it is mentioned in the
description.
SGI Security Advisory 19981005-01-PX</comment>
<comment voter="Christey">DUPE CVE-1999-0210?</comment>
<comment voter="Christey">ADDREF CIAC:J-014</comment>
<comment voter="Baker">It does look very similar to 1999-0210.  Perhaps they should be a single entry</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0089" seq="1999-0089">
<status>Candidate</status>
<phase date="19990630">Interim</phase>
<desc>Buffer overflow in AIX libDtSvc library can allow local users to gain root access.</desc>
<refs>
<ref source="ERS">ERS-SVA-E01-1997:005.1</ref>
<ref source="XF">ibm-libDtSvc</ref>
</refs>
<votes>
<accept count="2">Northcutt, Shostack</accept>
<modify count="2">Prosser, Frech</modify>
<recast count="1">Baker</recast>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">Reference: XF:ibm-libDtSvc</comment>
<comment voter="Prosser">The overflow is in the dtaction utility.  Also affects
dtaction in the CDE on versions of SunOS (SUN 164). Probably should be
specific.</comment>
<comment voter="Christey">Same Codebase as CVE-1999-0121, so the two entries should be
merged.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0092" seq="1999-0092">
<status>Candidate</status>
<phase date="19990623">Proposed</phase>
<desc>Various vulnerabilities in the AIX portmir command allows local users to obtain root access.</desc>
<refs>
<ref source="ERS">ERS-SVA-E01-1997:006.1</ref>
</refs>
<votes>
<accept count="2">Baker, Bollinger</accept>
<modify count="1">Frech</modify>
<noop count="1">Ozancin</noop>
</votes>
<comments>
<comment voter="Frech">XF:ibm-portmir</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0098" seq="1999-0098">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>Buffer overflow in SMTP HELO command in Sendmail allows a remote attacker to hide activities.</desc>
<refs>
<ref source="XF">smtp-helo-bo</ref>
</refs>
<votes>
<modify count="2">Baker, Frech</modify>
<noop count="1">Wall</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">(Accept XF reference.)
Our references do not mention hiding activities. This issue can crash the
SMTP server or execute arbitrary byte-code. Is there another reference
available?</comment>
<comment voter="Christey">Should this be merged with CVE-1999-0284, which is Sendmail
with SMTP HELO?</comment>
<comment voter="Christey">BUGTRAQ:19980522 about sendmail 8.8.8 HELO hole
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=90221101925991&amp;w=2
BUGTRAQ:19980527 about sendmail 8.8.8 HELO hole
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=90221101926003&amp;w=2</comment>
<comment voter="Baker">Apparently this XF reference is not for this issue, but for the other issue.  This should be modified to have the Bugtraq references, and remove the XF reference.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0104" seq="1999-0104">
<status>Candidate</status>
<phase date="20040811">Modified</phase>
<desc>A later variation on the Teardrop IP denial of service attack, a.k.a. Teardrop-2.</desc>
<refs>
<ref source="CERT">CA-97.28.Teardrop_Land</ref>
<ref source="XF">teardrop-mod</ref>
</refs>
<votes>
<accept count="2">Wall, Frech</accept>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Wall">Another reference is Microsoft Knowledge Base Q179129.</comment>
<comment voter="Christey">Not sure how many separate &quot;instances&quot; of Teardrop there are.
See: CVE-1999-0015, CVE-1999-0104, CVE-1999-0257, CVE-1999-0258</comment>
<comment voter="Christey">See the SCO advisory at:
http://www.securityfocus.com/templates/advisory.html?id=1411
which may further clarify the issue.</comment>
<comment voter="Christey">MSKB:Q179129
http://support.microsoft.com/support/kb/articles/q179/1/29.asp</comment>
<comment voter="Christey">MSKB:Q179129
http://support.microsoft.com/support/kb/articles/q179/1/29.asp
Note that the hotfix name is teardrop2, but the keywords
included in the KB article specifically name bonk
(CVE-1999-0258) and boink.
Since teardrop2 was fixed in a slightly different version
(at least in a separate patch) than Teardrop, CD:SF-LOC
suggests keeping them separate.</comment>
<comment voter="Christey">Add period to the end of the description.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0105" seq="1999-0105">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>finger allows recursive searches by using a long string of @ symbols.</desc>
<refs>
</refs>
<votes>
<modify count="3">Shostack, Baker, Frech</modify>
<noop count="1">Christey</noop>
<reject count="1">Northcutt</reject>
</votes>
<comments>
<comment voter="Shostack">fingerD</comment>
<comment voter="Frech">XF:finger-bomb</comment>
<comment voter="Christey">aka redirection or forwarding requests? (but then might
overlap CVE-1999-0106)</comment>
<comment voter="Baker">should change description to indicate the recursive searching can consume enough system resources to cause a DoS.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0106" seq="1999-0106">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>Finger redirection allows finger bombs.</desc>
<refs>
</refs>
<votes>
<accept count="1">Northcutt</accept>
<modify count="2">Shostack, Frech</modify>
<recast count="1">Baker</recast>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Shostack">fingerd allows redirection
This is a larger modification, since there are two applications of the 
vulnerability, one that I can finger anonymously, and the other that I 
can finger bomb anonymously.</comment>
<comment voter="Frech">XF:finger-bomb</comment>
<comment voter="Christey">need more refs</comment>
<comment voter="Baker">This should be merged with 1999-0105</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0107" seq="1999-0107">
<status>Candidate</status>
<phase date="19991223">Modified</phase>
<desc>Buffer overflow in Apache 1.2.5 and earlier allows a remote attacker to cause a denial of service with a large number of GET requests containing a large number of / characters.</desc>
<refs>
<ref source="XF">apache-dos</ref>
<ref source="BUGTRAQ">19971230 Apache DoS attack?</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
<noop count="3">Shostack, Northcutt, Wall</noop>
<reviewing count="1">Levy</reviewing>
<revote count="1">Christey</revote>
</votes>
<comments>
<comment voter="Wall">- Although this is probably the phf hack.</comment>
<comment voter="Frech">XF:apache-dos</comment>
<comment voter="Christey">This sounds like the incident reported in:
NTBUGTRAQ:20000810 Apache Distributed Denial of Service</comment>
<comment voter="Levy">I belive this is the problem where sending lot of HTTP headers to apache resulted on a denial of service.
BUGTRAQ: http://www.securityfocus.com/archive/1/10228
BUGTRAQ: http://www.securityfocus.com/archive/1/10516</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0110" seq="1999-0110">
<status>Candidate</status>
<phase date="19990810">Interim</phase>
<desc>** REJECT **  DO NOT USE THIS CANDIDATE NUMBER.  ConsultIDs: CVE-1999-0315.  Reason: This candidate's original description had a typo that delayed it from being detected as a duplicate of CVE-1999-0315.  Notes: All CVE users should reference CVE-1999-0315 instead of this candidate.  All references and descriptions in this candidate have been removed to prevent accidental usage.</desc>
<refs>
</refs>
<votes>
<modify count="1">Frech</modify>
<noop count="4">Shostack, Levy, Northcutt, Wall</noop>
<reject count="3">Dik, Christey, Baker</reject>
</votes>
<comments>
<comment voter="Frech">XF:fdformat-bo</comment>
<comment voter="Christey">Duplicate of CVE-1999-0315</comment>
<comment voter="Dik">dup</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0114" seq="1999-0114">
<status>Candidate</status>
<phase date="20000106">Modified</phase>
<desc>Local users can execute commands as other users, and read other users' files, through the filter command in the Elm elm-2.4 mail package using a symlink attack.</desc>
<refs>
<ref source="BUGTRAQ">19990912 elm filter program</ref>
<ref source="BUGTRAQ">19951226 filter (elm package) security hole</ref>
<ref source="XF">elm-filter2</ref>
</refs>
<votes>
<accept count="7">Shostack, Bishop, Blake, Wall, Landfield, Cole, Armstrong</accept>
<modify count="2">Baker, Frech</modify>
<noop count="3">Ozancin, Christey, Northcutt</noop>
<reviewing count="1">Levy</reviewing>
</votes>
<comments>
<comment voter="Frech">XF:elm-filter2</comment>
<comment voter="CHANGE">[Wall changed vote from NOOP to ACCEPT]</comment>
<comment voter="Landfield">with Frech modifications</comment>
<comment voter="Baker">ADD REF http://www.cert.org/ftp/cert_bulletins/VB-95:10a.elm	Official Advisory</comment>
<comment voter="Christey">The correct URL is http://www.cert.org/vendor_bulletins/VB-95:10a.elm
Need to make sure that this CERT advisory describes the right
problem, especially since the CERT advisory is dated December
18, 1995 and the original Bugtraq post was December 26, 1995.</comment>
<comment voter="Christey">BID:1802
URL:http://www.securityfocus.com/bid/1802
BID:1802 doesn't include the 1999 posting - does Security
Focus think that the 1999 post describes a different
vulnerability?</comment>
<comment voter="Christey">XF:elm-filter2 isn't on the X-Force web site.  How about XF:elm-filter(402) ?
Its references point to the December 26, 1995 BUgtraq post.

Also consider CIAC:G-36 and CERT:VB-95:10</comment>
<comment voter="Frech">DELREF:XF:elm-filter2(711)
ADDREF:XF:elm-filter(402)</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0119" seq="1999-0119">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>Windows NT 4.0 beta allows users to read and delete shares.</desc>
<refs>
</refs>
<votes>
<modify count="1">Frech</modify>
<noop count="2">Northcutt, Baker</noop>
<reject count="1">Wall</reject>
</votes>
<comments>
<comment voter="Wall">Reject based on beta copy.</comment>
<comment voter="Frech">XF:nt-beta(11)
Reconsider reject, because this beta was in widespread use.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0121" seq="1999-0121">
<status>Candidate</status>
<phase date="19990617">Proposed</phase>
<desc>Buffer overflow in dtaction command gives root access.</desc>
<refs>
<ref source="SUN">00164</ref>
<ref source="ERS">ERS-SVA-E01-1997:005.1</ref>
</refs>
<votes>
<accept count="2">Dik, Northcutt</accept>
<modify count="3">Prosser, Baker, Frech</modify>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">Reference: XF:dtaction-bo
Reference: XF:sun-dtaction</comment>
<comment voter="Prosser">Buffer overflow also affects /usr/dt/bin/dtaction in libDtSvc.a
library in AIX 4.x, but reference for this Sun vulnerability should
only reflect the Sun Bulletin or the CIAC I-032 version of the Sun
Bulletin</comment>
<comment voter="Christey">This is the Same Codebase as CVE-1999-0089, so the two entries
should be merged.</comment>
<comment voter="Frech">Replace sun-dtaction(732) with dtaction-bo(879)</comment>
<comment voter="Baker">Merge with 1999-0089</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0123" seq="1999-0123">
<status>Candidate</status>
<phase date="20000105">Modified</phase>
<desc>Race condition in Linux mailx command allows local users to read user files.</desc>
<refs>
<ref source="XF">linux-mailx</ref>
<ref source="BUGTRAQ">19951222 mailx-5.5 (slackware /bin/mail) security hole</ref>
</refs>
<votes>
<accept count="3">Ozancin, Baker, Frech</accept>
<noop count="1">Wall</noop>
</votes>
<comments>
</comments>
</item>

<item type="CAN" name="CVE-1999-0127" seq="1999-0127">
<status>Candidate</status>
<phase date="19990623">Proposed</phase>
<desc>swinstall and swmodify commands in SD-UX package in HP-UX systems allow local users to create or overwrite arbitrary files to gain root access.</desc>
<refs>
<ref source="CERT">CA-96.27.hp_sw_install</ref>
<ref source="AUSCERT">AA-96.04</ref>
<ref source="XF">hpux-swinstall</ref>
</refs>
<votes>
<accept count="2">Prosser, Baker</accept>
<modify count="1">Frech</modify>
<noop count="1">Christey</noop>
</votes>
<comments>
<comment voter="Frech">(keep current XF: reference, and add)
XF:hpux-sqwmodify</comment>
<comment voter="Christey">Perhaps this should be split, per SF-LOC.</comment>
<comment voter="Christey">CIAC:H-81
http://ciac.llnl.gov/ciac/bulletins/h-81.shtml
HP:HPSBUX9707-064  references CERT:CA-96.27
http://ciac.llnl.gov/ciac/bulletins/h-81.shtml

The original AUSCERT advisory says that the programs &quot;create
files in an insecure manner&quot; and &quot;Exploit details involving
this vulnerability have been made publicly available.&quot; which
leads one to assume that the following original Bugtraq post
provides the details for a standard symlink problem:

BUGTRAQ:19961005 swinst,bug
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=87602167419941&amp;w=2</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0140" seq="1999-0140">
<status>Candidate</status>
<phase date="19990630">Proposed</phase>
<desc>Denial of service in RAS/PPTP on NT systems.</desc>
<refs>
</refs>
<votes>
<accept count="1">Hill</accept>
<modify count="2">Frech, Meunier</modify>
<noop count="1">Baker</noop>
<reject count="1">Christey</reject>
</votes>
<comments>
<comment voter="Meunier">Add &quot;pptp invalid packet length in header&quot; to distinguish from other
vulnerabilities in RAS/PPTP on NT systems resulting in DOS, that might be
discovered in the future.</comment>
<comment voter="Frech">XF:nt-ras-bo
ONLY IF reference is to MS:MS99-016</comment>
<comment voter="Christey">According to my mappings, this is not the MS:MS99-016 problem
referred to by Andre.  However, I have yet to dig up a
source.</comment>
<comment voter="CHANGE">[Christey changed vote from NOOP to REVIEWING]</comment>
<comment voter="CHANGE">[Christey changed vote from REVIEWING to REJECT]</comment>
<comment voter="Christey">This is too general to know which problem is being discussed.
More precise candidates should be created.</comment>
<comment voter="Christey">Consider adding BID:2111</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0144" seq="1999-0144">
<status>Candidate</status>
<phase date="20010301">Modified</phase>
<desc>Denial of service in Qmail by specifying a large number of recipients with the RCPT command.</desc>
<refs>
<ref source="BUGTRAQ" url="http://marc.theaimsgroup.com/?l=bugtraq&amp;m=87602558319024&amp;w=2">19970612 qmail-dos-2.c, another denial of service attack</ref>
<ref source="BUGTRAQ" url="http://marc.theaimsgroup.com/?l=bugtraq&amp;m=87602558319029&amp;w=2">19970612 Re: Denial of service (qmail-smtpd)</ref>
<ref source="MISC" url="http://cr.yp.to/qmail/venema.html">http://cr.yp.to/qmail/venema.html</ref>
<ref source="MISC" url="http://www.ornl.gov/its/archives/mailing-lists/qmail/1997/06/threads.html">http://www.ornl.gov/its/archives/mailing-lists/qmail/1997/06/threads.html</ref>
<ref source="BID" url="http://www.securityfocus.com/bid/2237">2237</ref>
<ref source="XF" url="http://xforce.iss.net/static/208.php">qmail-rcpt</ref>
</refs>
<votes>
<accept count="4">Frech, Meunier, Hill, Baker</accept>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">DUPE CVE-1999-0418 and CVE-1999-0250?</comment>
<comment voter="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
&quot;Denial of service (qmail-smtpd)&quot;
&quot;qmail-dos-2.c, another denial of service&quot;
&quot;[PATCH] denial of service&quot;
&quot;just another qmail denial-of-service&quot;
&quot;the UNIX way&quot;
&quot;Time for a reality check&quot;

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</comment>
<comment voter="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.</comment>
<comment voter="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.</comment>
<comment voter="Baker">http://www.securityfocus.com/bid/2237</comment>
<comment voter="CHANGE">[Baker changed vote from REVIEWING to ACCEPT]</comment>
<comment voter="Christey">qmail-dos-1.c, as published by Wietse Venema (CVE-1999-0250)
in &quot;BUGTRAQ:19970612 Denial of service (qmail-smtpd)&quot;, does not
use any RCPT commands.  Instead, it sends long strings
of &quot;X&quot; characters.  A followup by &quot;super@UFO.ORG&quot; 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 &quot;super@ufo.org&quot; that were made before 2003.

qmail-dos-2.c, as published by Wietse Venema (CVE-1999-0144)
in &quot;BUGTRAQ:19970612 qmail-dos-2.c, another denial of service attack&quot;
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&amp;m=92100018214316&amp;w=2

This also describes a problem with mail servers not being able
to handle too many &quot;RCPT TO&quot; 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&amp;m=92101584629263&amp;w=2
The person further says, &quot;This attack can easily be
prevented with configuration methods.&quot;</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0154" seq="1999-0154">
<status>Candidate</status>
<phase date="20010912">Proposed</phase>
<desc>IIS 2.0 and 3.0 allows remote attackers to read the source code for ASP pages by appending a . (dot) to the end of the URL.</desc>
<refs>
<ref source="MSKB">Q163485</ref>
<ref source="MSKB">Q164059</ref>
<ref source="BUGTRAQ">19970220 ! [ADVISORY] Major Security Hole in MS ASP</ref>
<ref source="XF">http-iis-aspdot</ref>
<ref source="XF">http-iis-aspsource</ref>
</refs>
<votes>
<accept count="4">Frech, Stracener, Wall, Foat</accept>
<noop count="3">Christey, Baker, Cole</noop>
</votes>
<comments>
<comment voter="Christey">This is the precursor to the problem that is identified in
CVE-1999-0253.  </comment>
<comment voter="Christey">CIAC:H-48
URL:http://ciac.llnl.gov/ciac/bulletins/h-48.shtml</comment>
<comment voter="CHANGE">[Foat changed vote from NOOP to ACCEPT]</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0156" seq="1999-0156">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>wu-ftpd FTP daemon allows any user and password combination.</desc>
<refs>
<ref source="XF">ftp-pwless</ref>
</refs>
<votes>
<accept count="2">Shostack, Northcutt</accept>
<noop count="1">Baker</noop>
<recast count="1">Frech</recast>
<reviewing count="2">Christey, Prosser</reviewing>
</votes>
<comments>
<comment voter="Prosser">but so far can find no reference to this one</comment>
<comment voter="Frech">Our records indicate that this does not necessarly affect just wu-ftp (ie,
also affects IIS FTP server).</comment>
<comment voter="Christey">The references for XF:ftp-pwless are not specific enough,
e.g. in terms of version numbers.  Perhaps this candidate
should be rejected due to insufficient information.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0163" seq="1999-0163">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>In older versions of Sendmail, an attacker could use a pipe character to execute root commands.</desc>
<refs>
<ref source="XF">smtp-pipe</ref>
</refs>
<votes>
<accept count="2">Frech, Northcutt</accept>
<modify count="1">Prosser</modify>
<noop count="2">Christey, Baker</noop>
<recast count="1">Shostack</recast>
</votes>
<comments>
<comment voter="Shostack">there was a 'To: |' and a 'From: |' attack, which I
think are seperate.</comment>
<comment voter="Prosser">older vulnerability, but one additional reference is-
The Ultimate Sendmail Hole List by Markus H&#252;bner @
bau2.uibk.ac.at/matic/buglist.htm
'|PROGRAM '</comment>
<comment voter="Christey">Description needs to be more specific to distinguish between
this and CVE-1999-0203, as alluded to by Adam Shostack</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0165" seq="1999-0165">
<status>Candidate</status>
<phase date="20040811">Modified</phase>
<desc>NFS cache poisoning.</desc>
<refs>
<ref source="XF">nfs-cache</ref>
</refs>
<votes>
<accept count="3">Frech, Northcutt, Baker</accept>
<modify count="1">Shostack</modify>
<noop count="1">Prosser</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Shostack">need more data</comment>
<comment voter="Christey">need more refs</comment>
<comment voter="Christey">Add period to the end of the description.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0169" seq="1999-0169">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>NFS allows attackers to read and write any file on the system by specifying a false UID.</desc>
<refs>
<ref source="XF">nfs-uid</ref>
</refs>
<votes>
<accept count="2">Frech, Northcutt</accept>
<modify count="1">Baker</modify>
<reject count="1">Shostack</reject>
</votes>
<comments>
<comment voter="Shostack">this is not a vulnerability but a design feature.</comment>
<comment voter="Baker">Maybe we should reword it so that it is clear that this was a problem to something like:

&quot;A remote attacker could read/write files to the system with root-level permissions on NFS servers that fail to properly check the UID.&quot;</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0171" seq="1999-0171">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>Denial of service in syslog by sending it a large number of superfluous messages.</desc>
<refs>
<ref source="XF">syslog-flood</ref>
</refs>
<votes>
<accept count="2">Frech, Northcutt</accept>
<noop count="1">Baker</noop>
<reject count="2">Shostack, Christey</reject>
</votes>
<comments>
<comment voter="Shostack">design issue, not a vulnerability.  Alternately, add:
DOS on server by opening a large number of telnet sessions..</comment>
<comment voter="Christey">Duplicate of CVE-1999-0566</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0186" seq="1999-0186">
<status>Candidate</status>
<phase date="20071119">Modified</phase>
<desc>In Solaris, an SNMP subagent has a default community string that allows remote attackers to execute arbitrary commands as root, or modify system parameters.</desc>
<refs>
<ref source="CONFIRM" url="http://support.novell.com/cgi-bin/search/searchtid.cgi?/10080762.htm">http://support.novell.com/cgi-bin/search/searchtid.cgi?/10080762.htm</ref>
<ref source="SUN">00178</ref>
<ref source="XF">snmp-backdoor-access</ref>
</refs>
<votes>
<accept count="2">Dik, Baker</accept>
<modify count="1">Frech</modify>
<noop count="1">Wall</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">Change XF:snmp-backdoor-access to XF:sol-hidden-commstr
Add ISS:Hidden Community String in SNMP Implementation</comment>
<comment voter="Christey">What is the proper level of abstraction to use here?  Should
we have a separate entry for each different default community
string?  See:
http://cve.mitre.org/Board_Sponsors/archives/msg00242.html and
http://cve.mitre.org/Board_Sponsors/archives/msg00250.html
http://cve.mitre.org/Board_Sponsors/archives/msg00251.html

Until the associated content decisions have been approved
by the Editorial Board, this candidate cannot be accepted
for inclusion in CVE.</comment>
<comment voter="Christey">ADDREF BID:177</comment>
<comment voter="Christey">ISS:19981102 Hidden community string in SNMP implementation
http://xforce.iss.net/alerts/advise11.php

Change description to include &quot;hidden&quot;</comment>
<comment voter="Christey">XF:snmp-backdoor-access is missing.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0187" seq="1999-0187">
<status>Candidate</status>
<phase date="20050204">Modified</phase>
<desc>** REJECT **  DO NOT USE THIS CANDIDATE NUMBER.  ConsultIDs: CVE-1999-0022.  Reason: This candidate is a duplicate of CVE-1999-0022.  Notes: All CVE users should reference CVE-1999-0022 instead of this candidate.  All references and descriptions in this candidate have been removed to prevent accidental usage.</desc>
<refs>
</refs>
<votes>
<accept count="2">Hill, Northcutt</accept>
<recast count="3">Frech, Prosser, Baker</recast>
<reject count="1">Dik</reject>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Prosser">The Sun Patches in Ref roll-up fixes for an earlier BO in
rdist lookup( )(ref CERT 96.14)as well as the BO in rdist function expstr()
(ref CERT 97-23) and various vendor bulletins.  However both of these rdist
BO's affect many more OSs than just Sun, i.e., BSD/OS 2.1, DEC OSF's, AIX,
FreeBSD, SCO, SGI, etc.  Believe this falls into the SF-codebase content
decision</comment>
<comment voter="Frech">XF:rdist-bo (error msg formation)
XF:rdist-bo2 (execute code)
XF:rdist-bo3 (execute user-created code)
XF:rdist-sept97 (root from local)</comment>
<comment voter="Christey">Duplicate of CVE-1999-0022 (SUN:00179 is referenced in
CERT:CA-97.23.rdist), but as Mike and Andre noted, there
are multiple flaws here, so a RECAST may be necessary.</comment>
<comment voter="Dik">As currently phrasedm thissa duplicate of CVE-1999-0022</comment>
<comment voter="Baker">Based on our new philosophy, this should be recast/merged or re-described.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0193" seq="1999-0193">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>Denial of service in Ascend and 3com routers, which can be rebooted by sending a zero length TCP option.</desc>
<refs>
</refs>
<votes>
<accept count="5">Shostack, Bishop, Ozancin, Northcutt, Cole</accept>
<modify count="2">Blake, Baker</modify>
<noop count="4">Frech, Wall, Landfield, Armstrong</noop>
<reviewing count="2">Levy, Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">possibly XF:ascend-kill
I can't find a reference that lists both routers in the same reference.</comment>
<comment voter="Wall">Comment:  There is a reference about the zero length TCP option in BugTraq on
Feb 5, 1999
and it mentions Cisco, but not directly Ascend or 3Com.  CIAC Advisory I-038
mentions
vulnerabilities in Ascend, but does not mention TCP.  CIAC Advisory I-052
mentions
3Com vulnerabilities, but not TCP.  Too confusing withour better references.</comment>
<comment voter="Landfield">What are the references for this ? I cannot find a means to check it out.</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to NOOP]</comment>
<comment voter="Frech">Cannot reconcile to our database without further references.</comment>
<comment voter="Blake">I'm with Andre.  I only remember and can find reference to the Ascend
issue.  Do we have a refernce to the 3Coms?  If not, that should be
removed from the description.</comment>
<comment voter="Baker">http://xforce.iss.net/static/614.php	Misc Defensive Info
http://www.securityfocus.com/archive/1/5682	Misc Offensive Info
http://www.securityfocus.com/archive/1/5647	Misc Defensive Info
http://www.securityfocus.com/archive/1/5640	Misc Defensive Info</comment>
<comment voter="CHANGE">[Armstrong changed vote from REVIEWING to NOOP]</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0195" seq="1999-0195">
<status>Candidate</status>
<phase date="19991130">Modified</phase>
<desc>Denial of service in RPC portmapper allows attackers to register or unregister RPC services or spoof RPC services using a spoofed source IP address such as 127.0.0.1.</desc>
<refs>
<ref source="BUGTRAQ">19990128 rpcbind: deceive, enveigle and obfuscate</ref>
</refs>
<votes>
<accept count="2">Shostack, Balinsky</accept>
<modify count="1">Frech</modify>
<noop count="3">Northcutt, Wall, Baker</noop>
<reviewing count="2">Levy, Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">XF:rpcbind-spoof</comment>
<comment voter="Christey">CVE-1999-0195 = CVE-1999-0461 ?
If this is approved over CVE-1999-0461, make sure it gets
XF:pmap-sset</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0197" seq="1999-0197">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>finger 0@host on some systems may print information on some user accounts.</desc>
<refs>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="2">Frech, Shostack</modify>
<reject count="1">Northcutt</reject>
</votes>
<comments>
<comment voter="Shostack">fingerd may respond to 'finger 0@host' with account info</comment>
<comment voter="Frech">Need more reference to establish this 'exposure'.</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to MODIFY]</comment>
<comment voter="Frech">XF:finger-unused-accounts(8378)
We're entering it into our database solely to track
competition. The only references seem to be product listings:
http://hq.mcafeeasap.com/vulnerabilities/vuln_data/1000.asp (1002
Finger 0@host check)
http://www.ipnsa.com/ipnsa_vuln.htm?step=1000 (Finger 0@host check)
http://cgi.nessus.org/plugins/dump.php3?id=10069 (Finger zero at host
feature)</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0198" seq="1999-0198">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>finger .@host on some systems may print information on some user accounts.</desc>
<refs>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="2">Frech, Shostack</modify>
<reject count="1">Northcutt</reject>
</votes>
<comments>
<comment voter="Shostack">as above</comment>
<comment voter="Frech">Need more reference to establish this 'exposure'.</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to MODIFY]</comment>
<comment voter="Frech">XF:finger-unused-accounts(8378)
We're entering it into our database solely to track
competition. The only references seem to be product listings:
http://hq.mcafeeasap.com/vulnerabilities/vuln_data/1000.asp (1004
Finger .@target-host check)
http://www.ipnsa.com/ipnsa_vuln.htm?step=1000 (Finger .@target-host
check )
http://cgi.nessus.org/plugins/dump.php3?id=10072 (Finger dot at host
feature)</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0200" seq="1999-0200">
<status>Candidate</status>
<phase date="19991130">Modified</phase>
<desc>Windows NT FTP server (WFTP) with the guest account enabled without a password allows an attacker to log into the FTP server using any username and password.</desc>
<refs>
<ref source="MSKB">Q137853</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="2">Frech, Shostack</modify>
<noop count="2">Northcutt, Wall</noop>
<reject count="1">Christey</reject>
<reviewing count="1">Levy</reviewing>
</votes>
<comments>
<comment voter="Shostack">WFTP is not sufficient; is this wu-, ws-, war-, or another?</comment>
<comment voter="Frech">Other have mentioned this before, but it may be WU-FTP.
POSSIBLY XF:ftp-exec; does this have to do with the Site Exec allowing root
access without anon FTP or a regular account?
POSSIBLY XF:wu-ftpd-exec;same as above conditions, but instead from a
non-anon FTP account and gain root privs.</comment>
<comment voter="Christey">added MSKB reference</comment>
<comment voter="CHANGE">[Christey changed vote from REVOTE to REJECT]</comment>
<comment voter="Christey">The MSKB article may have confused things even more.  There
were reports of problems in a Windows-based FTP server called
WFTP (http://www.wftpd.com/) that is not a Microsft FTP
server.  It's best to just kill this candidate where it
stands and start fresh.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0205" seq="1999-0205">
<status>Candidate</status>
<phase date="19990925">Modified</phase>
<desc>Denial of service in Sendmail 8.6.11 and 8.6.12.</desc>
<refs>
<ref source="BUGTRAQ">19990708 SM 8.6.12</ref>
</refs>
<votes>
<accept count="2">Hill, Northcutt</accept>
<modify count="2">Frech, Prosser</modify>
<noop count="1">Baker</noop>
<reviewing count="2">Ozancin, Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">XF:sendmail-alias-dos</comment>
<comment voter="Prosser">additional source
Bugtraq
&quot;Re:  SM 8.6.12&quot;
http://www.securityfocus.com</comment>
<comment voter="Christey">The Bugtraq thread does not provide any proof, including a
comment by Eric Allman that he hadn't been provided any
details either.

See http://www.securityfocus.com/templates/archive.pike?list=1&amp;date=1995-07-8&amp;thread=199507131402.KAA02492@bedbugs.net.ohio-state.edu
for the thread.</comment>
<comment voter="Christey">Change Bugtraq reference date to 19950708.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0213" seq="1999-0213">
<status>Candidate</status>
<phase date="20001009">Modified</phase>
<desc>libnsl in Solaris allowed an attacker to perform a denial of service of rpcbind.</desc>
<refs>
<ref source="XF">sun-libnsl</ref>
<ref source="SUNBUG">4305859</ref>
</refs>
<votes>
<accept count="6">Dik, Ozancin, Hill, Blake, Landfield, Cole</accept>
<modify count="3">Frech, Levy, Baker</modify>
<noop count="4">Bishop, Meunier, Wall, Armstrong</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">XF:sun-libnsl</comment>
<comment voter="Dik">Sun bug #4305859</comment>
<comment voter="Baker">http://xforce.iss.net/static/1204.php	Misc Defensive Info
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&amp;doc=secbull/172&amp;type=0&amp;nav=sec.sba	Vendor Info
http://www-1.ibm.com/services/continuity/recover1.nsf/advisories/A1050E354364BF498525680F0077E414/$file/ERS-OAR-E01-1998_074_1.txt	Vendor Info
http://www.securityfocus.com/archive/1/9749	Misc Defensive Info</comment>
<comment voter="Christey">I don't think this is the bug that everyone thinks it is.
This candidate came from CyberCop Scanner 2.4/2.5, which
only reports this as a DoS problem.  If SUN:00172 is an
advisory for this, then it may be a duplicate of
CVE-1999-0055.  There appears to be overlap with other
references as well.  HOWEVER, this particular one deals with a
DoS in rpcbind - which isn't mentioned in the sources for
CVE-1999-0055.</comment>
<comment voter="Levy">BID 148</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0216" seq="1999-0216">
<status>Candidate</status>
<phase date="19991203">Modified</phase>
<desc>Denial of service of inetd on Linux through SYN and RST packets.</desc>
<refs>
<ref source="BUGTRAQ">19971130 Linux inetd..</ref>
<ref source="XF">linux-inetd-dos</ref>
<ref source="HP">HPSBUX9803-077</ref>
<ref source="XF">hp-inetd</ref>
</refs>
<votes>
<accept count="1">Hill</accept>
<modify count="2">Frech, Baker</modify>
<recast count="1">Meunier</recast>
</votes>
<comments>
<comment voter="Meunier">The location of the vulnerability, whether in the Linux kernel or the
application, is debatable.  Any program making the same (reasonnable)
assumption is vulnerable, i.e., implements the same vulnerability:
&quot;Assumption that TCP-three-way handshake is complete after calling Linux
kernel function accept(), which returns socket after getting SYN.   Result
is process death by SIGPIPE&quot;
Moreover, whether it results in DOS (to third parties) depends on the
process that made the assumption.
I think that the present entry should be split, one entry for every
application that implements the vulnerability (really describing threat
instances, which is what other people think about when we talk about
vulnerabilities), and one entry for the Linux kernel that allows the
vulnerability to happen.</comment>
<comment voter="Frech">XF:hp-inetd
XF:linux-inetd-dos</comment>
<comment voter="Baker">Since we have an hpux bulletin, the description should not specifically say Linux, should it?  It applies to mulitple OS and should be likely either modified, or in extreme case, recast</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0220" seq="1999-0220">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>Attackers can do a denial of service of IRC by crashing the server.</desc>
<refs>
</refs>
<votes>
<noop count="2">Northcutt, Baker</noop>
<reject count="2">Frech, Christey</reject>
</votes>
<comments>
<comment voter="Frech">Would reconsider if any references were available.</comment>
<comment voter="Christey">No references available, combined with extremely vague
description, equals REJECT.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0222" seq="1999-0222">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>Denial of service in Cisco IOS web server allows attackers to reboot the router using a long URL.</desc>
<refs>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="3">Frech, Shostack, Levy</modify>
<noop count="3">Balinsky, Northcutt, Wall</noop>
<recast count="1">Ziese</recast>
<reject count="1">Christey</reject>
</votes>
<comments>
<comment voter="Shostack">I follow cisco announcements and problems pretty closely, and haven't
seen this.  Source?</comment>
<comment voter="Frech">XF:cisco-web-crash</comment>
<comment voter="Christey">XF:cisco-web-crash has no additional references.  I can't find
any references in Bugtraq or Cisco either.  This bug is
supposedly tested by at least one security product, but that
product's database doesn't have any references either.  So
a question becomes, how did it make it into at least two
security companies' databases?</comment>
<comment voter="Levy">BUGTGRAQ: http://www.securityfocus.com/archive/1/60159
BID 1154</comment>
<comment voter="Ziese">The vulnerability is addressed by a vendor acknowledgement.  This one, if
recast to reflect that &quot;...after using a long url...&quot; should be replaced
with
&quot;...A defect in multiple releases of Cisco IOS software will cause a Cisco
router or switch to halt and reload if the IOS HTTP service is enabled,
browsing to &quot;http://router-ip/anytext?/&quot; is attempted, and the enable
password is supplied when requested. This defect can be exploited to produce
a denial of service (DoS) attack.&quot;
Then I can accept this and mark it as &quot;Verfied by my Company&quot;.  If it can't
be recast because this (long uri) is diffferent then our release (special
url construction).</comment>
<comment voter="CHANGE">[Christey changed vote from REVIEWING to REJECT]</comment>
<comment voter="Christey">Elias Levy's suggested reference is CVE-2000-0380.
I don't think that Kevin's description is really addressing
this either.  The lack of references and a specific
description make this candidate unusable, so it should be
rejected.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0226" seq="1999-0226">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>Windows NT TCP/IP processes fragmented IP packets improperly, causing a denial of service.</desc>
<refs>
</refs>
<votes>
<accept count="1">Northcutt</accept>
<modify count="1">Frech</modify>
<noop count="1">Baker</noop>
<reject count="1">Christey</reject>
</votes>
<comments>
<comment voter="Christey">Too general, and no references.</comment>
<comment voter="Frech">XF:nt-frag(528)
See reference from BugTraq Mailing List, &quot;A New Fragmentation Attack&quot; at
http://www.securityfocus.com/templates/archive.pike?list=1&amp;date=1997-07-8&amp;ms
g=Pine.SUN.3.94.970710054440.11707A-100000@dfw.dfw.net</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0229" seq="1999-0229">
<status>Candidate</status>
<phase date="19991228">Modified</phase>
<desc>Denial of service in Windows NT IIS server using ..\..</desc>
<refs>
<ref source="MSKB">Q115052</ref>
</refs>
<votes>
<accept count="2">Shostack, Baker</accept>
<modify count="2">Frech, Wall</modify>
<noop count="1">Northcutt</noop>
<reject count="1">Christey</reject>
<reviewing count="1">Levy</reviewing>
</votes>
<comments>
<comment voter="Wall">Denial of service in Windows NT IIS Server 1.0 using ..\...
Source: Microsoft Knowledge Base Article Q115052 - IIS Server.</comment>
<comment voter="Frech">XF:http-dotdot (not necessarily IIS?)</comment>
<comment voter="Christey">DELREF XF:http-dotdot - it deals with a read/access dot dot
problem.</comment>
<comment voter="Christey">This actually looks like XF:iis-dot-dot-crash(1638)
http://xforce.iss.net/static/1638.php
If so, include the version number (2.0)
</comment>
<comment voter="CHANGE">[Christey changed vote from REVOTE to REJECT]</comment>
<comment voter="Christey">Bill Wall intended to suggest Q155052, but the affected
IIS version there is 1.0; the effect is to read files,
so this sounds like a directory traversal problem,
instead of an inability to process certain strings.

As a result, this candidate is too general, since it could
apply to 2 different problems, so it should be REJECTed.</comment>
<comment voter="Christey">Consider adding BID:2218</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0231" seq="1999-0231">
<status>Candidate</status>
<phase date="19991207">Modified</phase>
<desc>Buffer overflow in IP-Switch IMail and Seattle Labs Slmail 2.6 packages using a long VRFY command, causing a denial of service and possibly remote access.</desc>
<refs>
<ref source="BUGTRAQ">19990317 Re: SLMail 2.6 DoS - Imail also</ref>
</refs>
<votes>
<accept count="2">Levy, Baker</accept>
<noop count="3">Christey, Northcutt, Landfield</noop>
<recast count="1">Frech</recast>
<reviewing count="1">Ozancin</reviewing>
</votes>
<comments>
<comment voter="Frech">XF:slmail-vrfyexpn-overflow (for Slmail v3.2 and below)
XF:smtp-vrfy-bo (many mail packages)</comment>
<comment voter="Northcutt">(There is no way I will have access to these systems)</comment>
<comment voter="Christey">Some sources report that VRFY and EXPN are both affected.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0232" seq="1999-0232">
<status>Candidate</status>
<phase date="19991220">Modified</phase>
<desc>Buffer overflow in NCSA WebServer (version 1.5c) gives remote access.</desc>
<refs>
</refs>
<votes>
<accept count="2">Hill, Northcutt</accept>
<modify count="1">Frech</modify>
<noop count="1">Prosser</noop>
<reject count="1">Baker</reject>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">Unable to provide a match due to vague/insufficient description/references.
Possible matches are:
XF:ftp-ncsa (probably not, considering you've mentioned the webserver.)
XF:http-ncsa-longurl (highest probability)</comment>
<comment voter="Christey">CVE-1999-0235 is the one associated with XF:http-ncsa-longurl
More research is necessary for this one.</comment>
<comment voter="Baker">Since this has no references at all, and is vague and we have a
CAN for the most likely issue, we should kill this one</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0235" seq="1999-0235">
<status>Candidate</status>
<phase date="19991220">Modified</phase>
<desc>Buffer overflow in NCSA WebServer (1.4.1 and below) gives remote access.</desc>
<refs>
<ref source="CERT">CA-95:04</ref>
<ref source="CIAC">F-11</ref>
</refs>
<votes>
<accept count="3">Hill, Prosser, Northcutt</accept>
<modify count="1">Frech</modify>
<reject count="2">Christey, Baker</reject>
</votes>
<comments>
<comment voter="Frech">XF:http-ncsa-longurl</comment>
<comment voter="Christey">CVE-1999-0235 has the same ref's as CVE-1999-0267</comment>
<comment voter="Baker">Not to mention, the X-force listings of http-ncsa-longurl and http-port both
refer to the same problem.  This should be rejected as 1999-0267 is the same problem.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0238" seq="1999-0238">
<status>Candidate</status>
<phase date="19990623">Proposed</phase>
<desc>php.cgi allows attackers to read any file on the system.</desc>
<refs>
<ref source="XF">http-cgi-phpfileread</ref>
</refs>
<votes>
<accept count="5">Frech, Collins, Prosser, Northcutt, Baker</accept>
<noop count="1">Christey</noop>
</votes>
<comments>
<comment voter="Prosser">additional source
AUSCERT External Security Bulletin ESB-97.047
http://www.auscert.org.au</comment>
<comment voter="Christey">ADDREF BUGTRAQ:19970416 Update on PHP/FI hole
URL:http://www.dataguard.no/bugtraq/1997_2/0069.html
The attacker specifies the filename as an argument to the
program.
Add &quot;PHP/FI&quot; to description to facilitate search.
AUSCERT URL is ftp://ftp.auscert.org.au/pub/auscert/ESB/ESB-97.047</comment>
<comment voter="Christey">Consider adding BID:2250</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0240" seq="1999-0240">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>Some filters or firewalls allow fragmented SYN packets with IP reserved bits in violation of their implemented policy.</desc>
<refs>
</refs>
<votes>
<accept count="1">Northcutt</accept>
<noop count="1">Baker</noop>
<reject count="1">Frech</reject>
</votes>
<comments>
<comment voter="Frech">Would reconsider if any references were available.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0241" seq="1999-0241">
<status>Candidate</status>
<phase date="19990925">Modified</phase>
<desc>Guessable magic cookies in X Windows allows remote attackers to execute commands, e.g. through xterm.</desc>
<refs>
<ref source="XF">http-xguess-cookie</ref>
</refs>
<votes>
<accept count="3">Hill, Northcutt, Proctor</accept>
<modify count="2">Frech, Prosser</modify>
<noop count="1">Baker</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">Also add to references:
XF:sol-mkcookie</comment>
<comment voter="Prosser">additional source
Bugtraq
&quot;X11 cookie hijacker&quot;
http://www.securityfocus.com</comment>
<comment voter="Christey">The cookie hijacker thread has to do with stealing cookies
through a file with bad permissions.  I'm not sure the
X-Force reference identifies this problem either.</comment>
<comment voter="Christey">CIAC:G-04
URL:http://ciac.llnl.gov/ciac/bulletins/g-04.shtml
SGI:19960601-01-I
URL:ftp://patches.sgi.com/support/free/security/advisories/19960601-01-I
CERT:VB-95:08</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0242" seq="1999-0242">
<status>Candidate</status>
<phase date="20000106">Modified</phase>
<desc>Remote attackers can access mail files via POP3 in some Linux systems that are using shadow passwords.</desc>
<refs>
<ref source="BUGTRAQ">19951222 mailx-5.5 (slackware /bin/mail) security hole</ref>
<ref source="XF">linux-pop3d</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
<noop count="4">Shostack, Christey, Northcutt, Wall</noop>
<reviewing count="1">Levy</reviewing>
</votes>
<comments>
<comment voter="Frech">Ambiguous description: need more detail. Possibly:
XF:linux-pop3d (mktemp() leads to reading e-mail)</comment>
<comment voter="Christey">At first glance this might look like CVE-1999-0123 or
CVE-1999-0125, however this particular candidate arises out
of a brief mention of the problem in a larger posting which
discusses CVE-1999-0123 (which may be the same bug as
CVE-1999-0125).  See the following phrase in the Bugtraq
post: &quot;one such example of this is in.pop3d&quot;

However, the original source of this candidate's description
explicitly mentions shadowed passwords, though it has no
references to help out here.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0243" seq="1999-0243">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>Linux cfingerd could be exploited to gain root access.</desc>
<refs>
</refs>
<votes>
<accept count="1">Shostack</accept>
<noop count="4">Levy, Northcutt, Wall, Baker</noop>
<reject count="2">Frech, Christey</reject>
</votes>
<comments>
<comment voter="Christey">This has no sources; neither does the original database that
this entry came from.  It's a likely duplicate of 
CVE-1999-0813.</comment>
<comment voter="Frech">I disagree on the dupe; see Linux-Security Mailing List,
&quot;[linux-security] Cfinger (Yet more :)&quot; at
http://www.geocrawler.com/archives/3/92/1996/9/0/2217716/. Seems as
if v1.2.3 is vulnerable, perhaps 1.3.0 also. CVE-1999-0813 pertains
to 1.4.x and below and shows up two years later.</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to REJECT]</comment>
<comment voter="Frech">If the reference I previously supplied is correct, then
it appears as if the poster modified the source using authorized 
access to make it vulnerable. Modifying the source in this manner 
does not qualify as being listed a vulnerability.
I disagree on the dupe; see Linux-Security Mailing List,
&quot;[linux-security] Cfinger (Yet more :)&quot; at
http://www.geocrawler.com/archives/3/92/1996/9/0/2217716/. Seems as
if v1.2.3 is vulnerable, perhaps 1.3.0 also. CVE-1999-0813 pertains
to 1.4.x and below and shows up two years later.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0246" seq="1999-0246">
<status>Candidate</status>
<phase date="19990630">Proposed</phase>
<desc>HP Remote Watch allows a remote user to gain root access.</desc>
<refs>
<ref source="XF">hp-remote</ref>
</refs>
<votes>
<accept count="4">Frech, Hill, Prosser, Northcutt</accept>
<noop count="1">Baker</noop>
<recast count="1">Christey</recast>
</votes>
<comments>
<comment voter="Frech">Comment: Determine if it's RemoteWatch or Remote Watch.</comment>
<comment voter="Christey">HP:HPSBUX9610-039 alludes to multiple vulnerabilities in
Remote Watch (the advisory uses two words, not one, for the
&quot;Remote Watch&quot; name)

ADDREF BUGTRAQ:19961015 HP/UX Remote Watch (was Re: BoS: SOD remote exploit)
URL:http://www.securityfocus.com/templates/archive.pike?list=1&amp;msg=199610151351.JAA18241@grymoire.crd.ge.com</comment>
<comment voter="Prosser">agree that the advisory mentions two vulnerabilities in Remote
Watch, one being a socket connection and other with the showdisk utility
which seems to be a suid vulnerability.  Never get much details on this
anywhere since the recommendation is to remove the program since it is
obsolete and superceded by later tools. Believe the biggest concern here is
to just not run the tool at all.</comment>
<comment voter="Christey">CIAC:H-16
Also, http://www.cert.org/vendor_bulletins/VB-96.20.hp
And possibly AUSCERT:AA-96.07 at
ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-96.07.HP-UX.Remote.Watch.vul</comment>
<comment voter="Christey">Also BUGTRAQ:19961013 BoS: SOD remote exploit
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=87602167419969&amp;w=2
Include &quot;remwatch&quot; in the description to facilitate search.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0249" seq="1999-0249">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>Windows NT RSHSVC program allows remote users to execute arbitrary commands.</desc>
<refs>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="2">Frech, Wall</modify>
<noop count="2">Shostack, Northcutt</noop>
<recast count="1">Christey</recast>
<reviewing count="1">Levy</reviewing>
</votes>
<comments>
<comment voter="Wall">Windows NT Rshsvc.exe from the Windows NT Resource Kit allows
remote
users to execute arbitrary commands.
Source: rshsvc.txt from the Windows NT Resource Kit.</comment>
<comment voter="Frech">XF:rsh-svc</comment>
<comment voter="Christey">MSKB:Q158320, last reviewed in January 1999, refers to a case
where remote users coming from authorized machines are
allowed access regardless of what .rhosts says.  XF:rsh-svc
refers to a bug circa 1997 where any remote entity could
execute commands as system.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0250" seq="1999-0250">
<status>Candidate</status>
<phase date="20010301">Modified</phase>
<desc>Denial of service in Qmail through long SMTP commands.</desc>
<refs>
<ref source="BUGTRAQ" url="http://marc.theaimsgroup.com/?l=bugtraq&amp;m=87602558319024&amp;w=2">19970612 qmail-dos-2.c, another denial of service attack</ref>
<ref source="MISC" url="http://cr.yp.to/qmail/venema.html">http://cr.yp.to/qmail/venema.html</ref>
<ref source="MISC" url="http://www.ornl.gov/its/archives/mailing-lists/qmail/1997/06/threads.html">http://www.ornl.gov/its/archives/mailing-lists/qmail/1997/06/threads.html</ref>
<ref source="XF">qmail-leng</ref>
</refs>
<votes>
<accept count="2">Meunier, Hill</accept>
<modify count="1">Frech</modify>
<reject count="1">Baker</reject>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">XF:qmail-rcpt</comment>
<comment voter="Christey">DUPE CVE-1999-0418 and CVE-1999-0144?</comment>
<comment voter="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
&quot;Denial of service (qmail-smtpd)&quot;
&quot;qmail-dos-2.c, another denial of service&quot;
&quot;[PATCH] denial of service&quot;
&quot;just another qmail denial-of-service&quot;
&quot;the UNIX way&quot;
&quot;Time for a reality check&quot;

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</comment>
<comment voter="Baker">This appears to be the same vulnerability listed in CAN 1999-0144.  In reading
through both bugtraq postings, the one that is referenced by 0144 is
based on a shell code exploit to cause memory exhaustion. The bugtraq
posting referenced by this entry refers explicitly to the prior
posting for 0144, and states that the same effect could be
accomplished by a perl exploit, which was then attached.</comment>
<comment voter="Baker">http://www.securityfocus.com/archive/1/6969    CVE-1999-0144
http://www.securityfocus.com/archive/1/6970    CVE-1999-0250

Both references should be added to CVE-1999-0144, and CVE-1999-0250
should likely be rejected.</comment>
<comment voter="CHANGE">[Baker changed vote from REVIEWING to REJECT]</comment>
<comment voter="Christey">XF:qmail-leng no longer exists; check with Andre to see if they
regarded it as a duplicate as well.

qmail-dos-1.c, as published by Wietse Venema (CVE-1999-0250)
in &quot;BUGTRAQ:19970612 Denial of service (qmail-smtpd)&quot;, does not
use any RCPT commands.  Instead, it sends long strings
of &quot;X&quot; characters.  A followup by &quot;super@UFO.ORG&quot; 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.

qmail-dos-2.c, as published by Wietse Venema (CVE-1999-0144)
in &quot;BUGTRAQ:19970612 qmail-dos-2.c, another denial of service attack&quot;
sends a large number of RCPT commands.

ADDREF BUGTRAQ:19970612 Denial of service (qmail-smtpd)
ADDREF BUGTRAQ:19970612 qmail-dos-2.c, another denial of service attack

Also see a related thread:
BUGTRAQ:19990308 SMTP server account probing
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=92100018214316&amp;w=2

This also describes a problem with mail servers not being able
to handle too many &quot;RCPT TO&quot; 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&amp;m=92101584629263&amp;w=2
The person further says, &quot;This attack can easily be
prevented with configuration methods.&quot;</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0253" seq="1999-0253">
<status>Candidate</status>
<phase date="20000106">Modified</phase>
<desc>IIS 3.0 with the iis-fix hotfix installed allows remote intruders to read source code for ASP programs by using a %2e instead of a . (dot) in the URL.</desc>
<refs>
<ref source="XF">http-iis-2e</ref>
<ref source="L0PHT">19970319</ref>
</refs>
<votes>
<accept count="9">Frech, Bishop, Collins, Blake, Northcutt, Baker, Landfield, Cole, Armstrong</accept>
<modify count="1">LeBlanc</modify>
<noop count="3">Ozancin, Prosser, Wall</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">This is a problem that was introduced after patching a
previous dot bug with the iis-fix hotfix (see CVE-1999-0154).
Since the hotfix introduced the problem, this should be
treated as a seaprate issue.</comment>
<comment voter="Wall">Agree with the comment.</comment>
<comment voter="LeBlanc">- this one is so old, I don't remember it at all and can't verify or
deny the issue. If you can find some documentation that says we fixed it (KB
article, hotfix, something), then I would change this to ACCEPT</comment>
<comment voter="CHANGE">[Christey changed vote from NOOP to REVIEWING]</comment>
<comment voter="Christey">BID:1814
URL:http://www.securityfocus.com/bid/1814</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0254" seq="1999-0254">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>A hidden SNMP community string in HP OpenView allows remote attackers to modify MIB tables and obtain sensitive information.</desc>
<refs>
<ref source="ISS">Hidden SNMP community in HP OpenView</ref>
<ref source="XF">hpov-hidden-snmp-comm</ref>
</refs>
<votes>
<accept count="2">Frech, Baker</accept>
<noop count="1">Wall</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">What is the proper level of abstraction to use here?  Should
we have a separate entry for each different default community
string?  See:
http://cve.mitre.org/Board_Sponsors/archives/msg00242.html and
http://cve.mitre.org/Board_Sponsors/archives/msg00250.html
http://cve.mitre.org/Board_Sponsors/archives/msg00251.html

Until the associated content decisions have been approved
by the Editorial Board, this candidate cannot be accepted
for inclusion in CVE.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0255" seq="1999-0255">
<status>Candidate</status>
<phase date="19990623">Proposed</phase>
<desc>Buffer overflow in ircd allows arbitrary command execution.</desc>
<refs>
</refs>
<votes>
<accept count="3">Hill, Northcutt, Baker</accept>
<modify count="1">Frech</modify>
<noop count="1">Prosser</noop>
<reject count="1">Christey</reject>
</votes>
<comments>
<comment voter="Frech">XF:irc-bo</comment>
<comment voter="Christey">This is too general and doesn't have any references.  The
XF reference doesn't appear toe xist any more.

Perhaps this reference would help:
BUGTRAQ:19970701 ircd buffer overflow</comment>
<comment voter="Baker">It appears that the XForce entry has been corrected, and there is a patch posted in the original bugtraq post.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0257" seq="1999-0257">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>Nestea variation of teardrop IP fragmentation denial of service.</desc>
<refs>
</refs>
<votes>
<accept count="1">Wall</accept>
<modify count="1">Frech</modify>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">XF:nestea-linux-dos</comment>
<comment voter="Christey">Not sure how many separate &quot;instances&quot; of Teardrop
and its ilk.  Also see comments on CVE-1999-0001.

See: CVE-1999-0015, CVE-1999-0104, CVE-1999-0257, CVE-1999-0258

Is CVE-1999-0001 the same as CVE-1999-0052?  That one is related
to nestea (CVE-1999-0257) and probably the one described in
BUGTRAQ:19981023 nestea v2 against freebsd 3.0-Release
The patch for nestea is in ip_input.c around line 750.
The patches for CVE-1999-0001 are in lines 388&amp;446.  So, 
CVE-1999-0001 is different from CVE-1999-0257 and CVE-1999-0052.
The FreeBSD patch for CVE-1999-0052 is in line 750.
So, CVE-1999-0257 and CVE-1999-0052 may be the same, though
CVE-1999-0052 should be RECAST since this bug affects Linux
and other OSes besides FreeBSD.

Also see BUGTRAQ:19990909 CISCO and nestea.

Finally, note that there is no fundamental difference between
nestea and nestea2/nestea-v2; they are different ports that
exploit the same problem.

The original nestea advisory is at
http://www.technotronic.com/rhino9/advisories/06.htm
but notice that the suggested fix is in line 375 of
ip_fragment.c, not ip_input.c.</comment>
<comment voter="Christey">See the SCO advisory at:
http://www.securityfocus.com/templates/advisory.html?id=1411
which may further clarify the issue.</comment>
<comment voter="Christey">BUGTRAQ:19980501 nestea does other things
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=90221101925819&amp;w=2
BUGTRAQ:19980508 nestea2 and HP Jet Direct cards.
URL:http://marc.theaimsgroup.com/?l=bugtraq&amp;m=90221101925870&amp;w=2
BUGTRAQ:19981027 nestea v2 against freebsd 3.0-Release
URL:http://marc.theaimsgroup.com/?l=bugtraq&amp;m=90951521507669&amp;w=2

Nestea source code is in
MISC:http://oliver.efri.hr/~crv/security/bugs/Linux/ipfrag6.html</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0258" seq="1999-0258">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>Bonk variation of teardrop IP fragmentation denial of service.</desc>
<refs>
</refs>
<votes>
<modify count="2">Frech, Wall</modify>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Wall">Reference Q179129</comment>
<comment voter="Frech">XF:teardrop-mod</comment>
<comment voter="Christey">Not sure how many separate &quot;instances&quot; of Teardrop there are.
See: CVE-1999-0015, CVE-1999-0104, CVE-1999-0257, CVE-1999-0258</comment>
<comment voter="Christey">See the SCO advisory at:
http://www.securityfocus.com/templates/advisory.html?id=1411
which may further clarify the issue.</comment>
<comment voter="Christey">BUGTRAQ:19980108 bonk.c
URL:http://marc.theaimsgroup.com/?l=bugtraq&amp;m=88429524325956&amp;w=2
NTBUGTRAQ:19980108 bonk.c
URL:http://marc.theaimsgroup.com/?l=ntbugtraq&amp;m=88433857200304&amp;w=2
NTBUGTRAQ:19980109 Re: Bonk.c
URL:http://marc.theaimsgroup.com/?l=ntbugtraq&amp;m=88441302913269&amp;w=2
NTBUGTRAQ:19980304 Update on wide-spread NewTear Denial of Service attacks
URL:http://marc.theaimsgroup.com/?l=ntbugtraq&amp;m=88901842000424&amp;w=2
BUGTRAQ:19980304 Update on wide-spread NewTear Denial of Service attacks
URL:http://marc.theaimsgroup.com/?l=bugtraq&amp;m=88903296104349&amp;w=2
CIAC:I-031a
http://ciac.llnl.gov/ciac/bulletins/i-031a.shtml

CERT summary CS-98.02 implies that bonk, boink, and newtear
all exploit the same vulnerability.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0261" seq="1999-0261">
<status>Candidate</status>
<phase date="20000827">Modified</phase>
<desc>Netmanager Chameleon SMTPd has several buffer overflows that cause a crash.</desc>
<refs>
<ref source="BUGTRAQ">19980504 Netmanage Holes</ref>
<ref source="MISC" url="http://www.insecure.org/sploits/netmanage.chameleon.overflows.html">http://www.insecure.org/sploits/netmanage.chameleon.overflows.html</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="2">Frech, Landfield</modify>
<noop count="3">Ozancin, Christey, Northcutt</noop>
</votes>
<comments>
<comment voter="Frech">XF:chamelion-smtp-dos</comment>
<comment voter="Landfield">- Specify what &quot;a crash&quot; means.</comment>
<comment voter="Christey">ADDREF XF:chameleon-smtp-dos ?  (but it's not on the web site)</comment>
<comment voter="Christey">Consider adding BID:2387</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0271" seq="1999-0271">
<status>Candidate</status>
<phase date="19990925">Modified</phase>
<desc>Progressive Networks Real Video server (pnserver) can be crashed remotely.</desc>
<refs>
<ref source="BUGTRAQ">19980115 pnserver exploit..</ref>
<ref source="BUGTRAQ">19980817 Re: Real Audio Server Version 5 bug?</ref>
</refs>
<votes>
<accept count="3">Blake, Northcutt, Baker</accept>
<modify count="1">Frech</modify>
<noop count="1">Prosser</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">Problem confirmed by RealServer vendor (URL listed in Bugtraq
posting), but may be multiple codebases since several
Real Audio servers are affected.

Also, this may be the same as BUGTRAQ:19991105 RealNetworks RealServer G2 buffer overflow.
See CVE-1999-0896</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to MODIFY]</comment>
<comment voter="Frech">ADDREF XF:realvideo-telnet-dos</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0282" seq="1999-0282">
<status>Candidate</status>
<phase date="20050830">Modified</phase>
<desc>** REJECT **  DO NOT USE THIS CANDIDATE NUMBER.  ConsultIDs: CVE-1999-1584, CVE-1999-1586.  Reason: This candidate combined references from one issue with the description from another issue.  Notes: Users should consult CVE-1999-1584 and CVE-1999-1586 to obtain the appropriate name.  All references and descriptions in this candidate have been removed to prevent accidental usage.</desc>
<refs>
</refs>
<votes>
<accept count="2">Dik, Baker</accept>
<modify count="1">Frech</modify>
<noop count="1">Ozancin</noop>
<recast count="1">Prosser</recast>
<reject count="1">Christey</reject>
</votes>
<comments>
<comment voter="Frech">XF:sun-loadmodule
XF:sun-modload (CERT CA-93.18 very old!)</comment>
<comment voter="Prosser">Believe the reference given, 95-12,  is referencing a later
loadmodule(8) setuid problem in the X11/NeWS windowing system.  There is an
earlier, similar setuid vulnerability in the CA-93.18, CIAC G-02 advisories
for the SunOS 4.1.x/Solbourne and OpenWindow 3.0.  In fact, there may be the
same as the HP patches are 100448-02 for the 93 loadmodule/modload
vulnerability and 100448-03 for the 95 loadmodule vulnerability which
normally indicated a patch update.  Looks like the original patch either
didn't completely fix the problem or it resurfaced in X11 NeWS.  Can't tell
much beyond that and this is my opinion only as have no way to check it.  
Which one is this CVE referencing?  I accept both.</comment>
<comment voter="Dik">There are three similar Sun bug ids associated with the patches.
1076118 loadmodule has a security vulnerability
1148753 loadmodule has a security vulnerability
1222192 loadmodule has a security vulnerability
as well as:
1137491
Ancient stuff.</comment>
<comment voter="Christey">Add period to the end of the description.</comment>
<comment voter="CHANGE">[Christey changed vote from NOOP to REVIEWING]</comment>
<comment voter="Christey">This is distinct from CVE-1999-1584 - CVE-1999-1584 is for
CA-93.18.</comment>
<comment voter="CHANGE">[Christey changed vote from REVIEWING to REJECT]</comment>
<comment voter="Christey">This candidate combines two separate issues.  It uses the CERT
alert reference from 1995, from one issue, but a description that
is associated with a separate issue.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0283" seq="1999-0283">
<status>Candidate</status>
<phase date="19991203">Modified</phase>
<desc>The Java Web Server would allow remote users to obtain the source code for CGI programs.</desc>
<refs>
<ref source="BUGTRAQ" url="http://marc.theaimsgroup.com/?l=bugtraq&amp;m=88256790401004&amp;w=2">19970716 Viewable .jhtml source with JavaWebServer</ref>
</refs>
<votes>
<accept count="7">Dik, Collins, Blake, Northcutt, Wall, Baker, Cole</accept>
<modify count="1">Frech</modify>
<noop count="5">Armstrong, Bishop, Christey, Prosser, Landfield</noop>
<reviewing count="1">Ozancin</reviewing>
</votes>
<comments>
<comment voter="Wall">Acknowledged by vendor at
http://www.sun.com/software/jwebserver/techinfo/jws112info.html.</comment>
<comment voter="Baker">Vulnerability Reference (HTML)	Reference Type
http://www.securityfocus.com/archive/1/7260	Misc Defensive Info
http://www.sun.com/software/jwebserver/techinfo/jws112info.html Vendor Info</comment>
<comment voter="Christey">BID:1891
URL:http://www.securityfocus.com/bid/1891</comment>
<comment voter="Christey">Add version number (1.1 beta) and details of attack (appending
a . or a \)

The Sun URL referenced by Dave Baker no longer exists, so I
wasn't able to verify that it addressed the problem described
in the Bugtraq post.  This might not even be Sun's
&quot;Java Web Server,&quot; as CVE-2001-0186 describes some product
called &quot;Free Java Web Server&quot;</comment>
<comment voter="Dik">There appears to be some confusion.

The particular bug seems to be on in JWS 1.1beta or 1.1 which was fixed
in 1.1.2 (get foo.jthml source by appending &quot;.&quot; of &quot;\&quot; to URL)

There are other bugs that give access and that require a configuration
change.

http://www.sun.com/software/jwebserver/techinfo/security_advisory.html</comment>
<comment voter="Christey">Need to make sure to create CAN's for the other bugs,
as documented in:
NTBUGTRAQ:19980724 Alert: New Source Bug Affect Sun JWS
http://marc.theaimsgroup.com/?l=ntbugtraq&amp;m=90222454131622&amp;w=2
BUGTRAQ:19980725 Alert: New Source Bug Affect Sun JWS
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=90221104526086&amp;w=2
The reported bugs are:
1) file read by appending %20
2) Directly call /servlet/file
URL:http://www.sddt.com/cgi-bin/Subscriber?/library/98/07/24/tbd.html
#2 is explicitly mentioned in the Sun advisory for
CVE-1999-0283.</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to MODIFY]</comment>
<comment voter="Frech">XF:javawebserver-cgi-source(5383)</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0284" seq="1999-0284">
<status>Candidate</status>
<phase date="19990623">Proposed</phase>
<desc>Denial of service to NT mail servers including Ipswitch, Mdaemon, and Exchange through a buffer overflow in the SMTP HELO command.</desc>
<refs>
<ref source="XF">smtp-helo-bo</ref>
</refs>
<votes>
<accept count="2">Blake, Northcutt</accept>
<modify count="3">Frech, Ozancin, Levy</modify>
<noop count="1">Baker</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">&quot;Windows NT-based mail servers&quot; (A trademark thing, and for clarification)
XF:mdaemon-helo-bo
XF:lotus-notes-helo-crash
XF:slmail-helo-overflow
XF:smtp-helo-bo (mentions several products)
XF:smtp-exchangedos</comment>
<comment voter="Levy">- Need one per software. Each one should be its own
vulnerability.</comment>
<comment voter="Ozancin">=&gt; Windows NT is correct</comment>
<comment voter="Christey">These are probably multiple codebases, so we'll need to use
dot notation.  Also need to see if this should be merged
with CVE-1999-0098 (Sendmail SMTP HELO).</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0285" seq="1999-0285">
<status>Candidate</status>
<phase date="19990630">Proposed</phase>
<desc>Denial of service in telnet from the Windows NT Resource Kit, by opening then immediately closing a connection.</desc>
<refs>
</refs>
<votes>
<accept count="1">Hill</accept>
<noop count="2">Wall, Baker</noop>
<reject count="2">Frech, Christey</reject>
</votes>
<comments>
<comment voter="Christey">No references, no information.</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to REJECT]</comment>
<comment voter="Frech">No references; closest documented match is with
CVE-2001-0346, but that's for Windows 2000.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0286" seq="1999-0286">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>In some NT web servers, appending a space at the end of a URL may allow attackers to read source code for active pages.</desc>
<refs>
</refs>
<votes>
<accept count="3">Armstrong, Shostack, Cole</accept>
<modify count="3">Levy, Blake, Wall</modify>
<noop count="5">Bishop, Ozancin, Northcutt, Baker, Landfield</noop>
<reject count="1">Frech</reject>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Wall">In some NT web servers, appending a dot at the end of a URL may
allows attackers to read source code for active pages.
Source:  MS Knowledge Base Article Q163485 - &quot;Active Server Pages Script Appears
in Browser&quot;</comment>
<comment voter="Frech">In the meantime, reword description as 'Windows NT' (trademark issue)</comment>
<comment voter="Christey">Q163485 does not refer to a space, it refers to a dot.
However, I don't have other references.

Reading source code with a dot appended is in CVE-1999-0154,
which will be proposed.  A subsequent bug similar to the
dot bug is CVE-1999-0253.</comment>
<comment voter="Levy">NTBUGTRAQ: http://www.securityfocus.com/archive/2/22014
NTBUGTRAQ: http://www.securityfocus.com/archive/2/22019
BID 273</comment>
<comment voter="Blake">Reference:  http://www.allaire.com/handlers/index.cfm?ID=10967</comment>
<comment voter="CHANGE">[Christey changed vote from NOOP to REVIEWING]</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to REJECT]</comment>
<comment voter="Frech">BID articles)</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0287" seq="1999-0287">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>Vulnerability in the Wguest CGI program.</desc>
<refs>
</refs>
<votes>
<modify count="2">Frech, Shostack</modify>
<noop count="4">Levy, Blake, Northcutt, Wall</noop>
<reject count="2">Christey, Baker</reject>
</votes>
<comments>
<comment voter="Shostack">allows file reading</comment>
<comment voter="Frech">XF:http-cgi-webcom-guestbook</comment>
<comment voter="Christey">CVE-1999-0287 is probably a duplicate of CVE-1999-0467.  In
NTBUGTRAQ:19990409 Webcom's CGI Guestbook for Win32 web servers
Mnemonix says that he had previously reported on a similar
problem.  Let's refer to the NTBugtraq posting as
CVE-1999-0467.  We will refer to the &quot;previous report&quot; as
CVE-1999-0287, which could be found at:
http://oliver.efri.hr/~crv/security/bugs/NT/httpd41.html

0287 describes an exploit via the &quot;template&quot; hidden variable.
The exploit describes manually editing the HTML form to
change the filename to read from the template variable.

The exploit as described in 0467 encodes the template variable
directly into the URL.  However, hidden variables are also
encoded into the URL, which would have looked the same to
the web server regardless of the exploit.  Therefore 0287
and 0467 are the same.</comment>
<comment voter="Christey">BID:2024</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0298" seq="1999-0298">
<status>Candidate</status>
<phase date="20000524">Modified</phase>
<desc>ypbind with -ypset and -ypsetme options activated in Linux Slackware and SunOS allows local and remote attackers to overwrite files via a .. (dot dot) attack.</desc>
<refs>
<ref source="NAI" url="http://www.nai.com/nai_labs/asp_set/advisory/06_ypbindsetme_adv.asp">19970205 Vulnerabilities in Ypbind when run with -ypset/-ypsetme</ref>
</refs>
<votes>
<accept count="4">Cole, Dik, Levy, Northcutt</accept>
<modify count="1">Frech</modify>
<noop count="3">Shostack, Christey, Baker</noop>
</votes>
<comments>
<comment voter="Christey">ADDREF BID:1441
URL:http://www.securityfocus.com/bid/1441</comment>
<comment voter="Dik">If you run with &quot;-ypset&quot;, then you're always insecure.
With ypsetme, only root on the local host
can run ypset in Solaris 2.x+.
Probably true for SunOS 4, hence my vote.</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to MODIFY]</comment>
<comment voter="Frech">ADDREF XF:ypbind-ypset-root</comment>
<comment voter="CHANGE">[Dik changed vote from REVIEWING to ACCEPT]</comment>
<comment voter="Dik">This vulnerability does exist in SunOS 4.x in non default configurations.
In Solaris 2.x, the vulnerability only applies to files named &quot;cache_binding&quot;
and not all files ending in .2
Both releases are not vulnerable in the default configuration (both
disabllow ypset by default which prevents this problem from occurring)</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0306" seq="1999-0306">
<status>Candidate</status>
<phase date="19990714">Proposed</phase>
<desc>buffer overflow in HP xlock program.</desc>
<refs>
<ref source="XF">hp-xlock</ref>
</refs>
<votes>
<accept count="3">Frech, Northcutt, Baker</accept>
<modify count="1">Prosser</modify>
<noop count="1">Shostack</noop>
<reject count="1">Christey</reject>
</votes>
<comments>
<comment voter="Prosser">This is another of those with multiple affected OSs.
Refs:  CA-97.13, http://207.237.120.45/linux/xlock-exploit.txt,
HPSBUX9711-073, SGI 19970502-02-PX, Sun Bulletin 000150</comment>
<comment voter="Christey">XF:hp-xlock points to SGI:19970502-02-PX which says this is
the same problem as in CERT:CA-97.13, which is CVE-1999-0038.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0307" seq="1999-0307">
<status>Candidate</status>
<phase date="19991207">Modified</phase>
<desc>Buffer overflow in HP-UX cstm program allows local users to gain root privileges.</desc>
<refs>
<ref source="BUGTRAQ">19961116 This week: turn me on, dead man</ref>
<ref source="XF">hpux-cstm-bo</ref>
</refs>
<votes>
<accept count="2">Frech, Northcutt</accept>
<noop count="3">Shostack, Prosser, Baker</noop>
<recast count="1">Christey</recast>
</votes>
<comments>
<comment voter="Prosser">only ref I can find is an old SOD exploit on
www.outpost9.com</comment>
<comment voter="Christey">MERGE CVE-1999-0336 (the exact exploit works with both
cstm and mstm, which are clearly part of the same package,
so CD:SF-EXEC says to merge them.)

Also, there does not seem to be any recognition of this problem
by HP.  The only other information besides the Bugtraq post
is the SOD exploit.

See the original post:
http://www.securityfocus.com/templates/archive.pike?list=1&amp;date=1996-11-15&amp;msg=Pine.LNX.3.91.961116112242.15276J-100000@underground.org</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0317" seq="1999-0317">
<status>Candidate</status>
<phase date="19991216">Modified</phase>
<desc>Buffer overflow in Linux su command gives root access to local users.</desc>
<refs>
<ref source="BUGTRAQ">19990818 slackware-3.5 /bin/su buffer overflow</ref>
<ref source="XF">su-bo</ref>
</refs>
<votes>
<accept count="3">Frech, Hill, Northcutt</accept>
<noop count="1">Prosser</noop>
<recast count="1">Baker</recast>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">DUPE CVE-1999-0845?
Also, ADDREF XF:unixware-su-username-bo
A report summary by Aleph One states that nobody was able to
confirm this problem on any Linux distribution.</comment>
<comment voter="Baker">If this is the same as the unixware, the n it is a dupe of 1999-0845.  There is about a two and half month difference in the bugtraq reporting of these.
Sounds like the same bug however...</comment>
<comment voter="Christey">XF:su-bo no longer seems to exist.
How about XF:linux-subo(734) ?
http://xforce.iss.net/static/734.php

BID:475 also seems to describe the same problem
(http://www.securityfocus.com/bid/475) in which case,
vsyslog is blamed in:
BUGTRAQ:19971220 Linux vsyslog() overflow
http://www.securityfocus.com/archive/1/8274</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0319" seq="1999-0319">
<status>Candidate</status>
<phase date="19990623">Proposed</phase>
<desc>Buffer overflow in xmcd 2.1 allows local users to gain access through a user resource setting.</desc>
<refs>
<ref source="XF">xmcd-tiflestr</ref>
</refs>
<votes>
<accept count="3">Frech, Hill, Northcutt</accept>
<noop count="2">Prosser, Baker</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">BUGTRAQ:19961126 Security Problems in XMCD 2.1
A followup to this post says that xmcd is not suid here.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0330" seq="1999-0330">
<status>Candidate</status>
<phase date="20000105">Modified</phase>
<desc>Linux bdash game has a buffer overflow that allows local users to gain root access.</desc>
<refs>
<ref source="BUGTRAQ">19940101 (No Subject)</ref>
<ref source="XF">bdash-bo</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
<noop count="3">Shostack, Northcutt, Wall</noop>
<reviewing count="1">Levy</reviewing>
</votes>
<comments>
<comment voter="Frech">XF:bdash-bo</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0331" seq="1999-0331">
<status>Candidate</status>
<phase date="20040811">Modified</phase>
<desc>Buffer overflow in Internet Explorer 4.0(1).</desc>
<refs>
<ref source="XF">msie-bo</ref>
</refs>
<votes>
<accept count="2">Northcutt, Baker</accept>
<modify count="2">Frech, Shostack</modify>
<recast count="1">Prosser</recast>
<reject count="2">Christey, LeBlanc</reject>
</votes>
<comments>
<comment voter="Shostack">this is a high cardinality item</comment>
<comment voter="Prosser">needs to be more specific.</comment>
<comment voter="Frech">Replace reference with XF:iemk-bug (msie-bo is obsolete and a vague
duplicate)
Description (from xfdb): Some versions of Internet Explorer for Windows
contain a vulnerability that may crash the broswer when a malicious web site
contains a certain kind of URL (that begins with &quot;mk://&quot;) with more
characters than the browser supports. </comment>
<comment voter="Christey">The description is too vague.</comment>
<comment voter="LeBlanc">too vague</comment>
<comment voter="Christey">Add period to the end of the description.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0333" seq="1999-0333">
<status>Candidate</status>
<phase date="19990925">Modified</phase>
<desc>HP OpenView Omniback allows remote execution of commands as root via spoofing, and local users can gain root access via a symlink attack.</desc>
<refs>
<ref source="RSI">RSI.0009.09-08-98.HP-UX.OMNIBACK</ref>
<ref source="HP">HPSBUX9810-085</ref>
<ref source="XF">omniback-remote</ref>
</refs>
<votes>
<accept count="2">Frech, Baker</accept>
<modify count="1">Prosser</modify>
<recast count="1">Christey</recast>
</votes>
<comments>
<comment voter="Prosser">additional source
HP Security Bulletin 85
http://us-support.external.hp.com
http://europe-support.external.hp.com</comment>
<comment voter="Christey">Two separate bugs, so SF-LOC says this candidate should be
split</comment>
<comment voter="Christey">ADDREF CIAC:J-007
URL:http://ciac.llnl.gov/ciac/bulletins/j-007.shtml</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0336" seq="1999-0336">
<status>Candidate</status>
<phase date="19991207">Modified</phase>
<desc>Buffer overflow in mstm in HP-UX allows local users to gain root access.</desc>
<refs>
<ref source="BUGTRAQ">19961116 This week: turn me on, dead man</ref>
<ref source="XF">hpux-mstm-bo</ref>
</refs>
<votes>
<accept count="2">Frech, Northcutt</accept>
<noop count="3">Shostack, Prosser, Baker</noop>
<recast count="1">Christey</recast>
</votes>
<comments>
<comment voter="Prosser">same as CVE-1999-0307, only ref I can find is an old SOD
exploit on www.outpost9.com</comment>
<comment voter="Christey">MERGE CVE-1999-0307 (the exact exploit works with both
cstm and mstm, which are clearly part of the same package,
so CD:SF-EXEC says to merge them.)

Also, there does not seem to be any recognition of this problem
by HP.  The only other information besides the Bugtraq post
is the SOD exploit.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0345" seq="1999-0345">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>Jolt ICMP attack causes a denial of service in Windows 95 and Windows NT systems.</desc>
<refs>
</refs>
<votes>
<accept count="2">Cole, Blake</accept>
<modify count="2">Frech, Wall</modify>
<noop count="4">Landfield, Bishop, Ozancin, Northcutt</noop>
<recast count="1">Meunier</recast>
<reject count="4">Armstrong, Levy, LeBlanc, Baker</reject>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Wall">Invalid ICMP datagram fragments causes a denial of service in Windows 95 and
Windows NT systems.
Reference: Q154174.
Jolt is also known as sPING, ICMP bug, Icenewk, and Ping of Death.
It is a modified teardrop 2 attack.  </comment>
<comment voter="Frech">XF:nt-ssping
ADDREF XF:ping-death
ADDREF XF:teardrop-mod
ADDREF XF:mpeix-echo-request-dos</comment>
<comment voter="Christey">I can't tell whether the Jolt exploit at:

http://www.securityfocus.com/templates/archive.pike?list=1&amp;date=1997-06-28&amp;msg=Pine.BSF.3.95q.970629163422.3264A-200000@apollo.tomco.net

is exploiting any different flaw than teardrop does.</comment>
<comment voter="CHANGE">[Christey changed vote from NOOP to REVIEWING]</comment>
<comment voter="Baker">Jolt (original) is basically just a fragmented oversized ICMP that
kills Win boxes ala Ping of Death.
Teardrop is altering the offset in fragmented tcp packets so that the
end of subsequent fragments is inside first packet...
Teardrop 2 is UDP packets, if I remember right.
Seems like Jolt (original, not jolt 2) is just exploit code that
creates a ping of death (CVE 1999-0128)</comment>
<comment voter="Levy">I tend to agree with Baker.</comment>
<comment voter="CHANGE">[Armstrong changed vote from REVIEWING to REJECT]</comment>
<comment voter="Armstrong">This code does not use fragment overlap.  It is simply a large ICMP echo request.</comment>
<comment voter="Christey">See the SCO advisory at:
http://www.securityfocus.com/templates/advisory.html?id=1411
which may further clarify the issue.</comment>
<comment voter="LeBlanc">This is a hodge-podge of DoS attacks. Jolt isn't the same
thing as ping of death - POD was an oversized ICMP packet, Jolt froze
Linux and Solaris (and I think not NT), IIRC Jolt2 did get NT boxes.
Teardrop and teardrop2 were related attacks (usually ICMP frag attacks),
but each of these is a distinct vulnerability, affected a discrete group
of systems, and should have distinct CVE numbers. CVE entries should be
precise as to what the problem is.</comment>
<comment voter="Meunier">I agree with Leblanc in that Jolt is multi-faceted.  Jolt has
characteristics of Ping of Death AND teardrop, but it doesn't do
either exactly.  Moreover, it sends a truncated IP fragment.  I
disagree with Armstrong; jolt uses overlapping fragments.  It's not a
simple ping of death either.  It may be that the author's intent was
to construct a &quot;super attack&quot; somehow combining elements of other
vulnerabilities to try to make it more potent.  In any case it
succeeded in confusing the CVE board :-).

I notice that Jolt uses echo replies (type 0) instead of echo
requests (to get past firewalls?).  Jolt is peculiar in that it also
sends numerous overlapping fragments.  The &quot;Pascal Simulator&quot; :-) says
it sends:

- 172 fragments of length 400 with offset starting at 5120 and</comment>
<comment voter="increasing by about 47 (odd arithmetic of 5120 OR ((n* 380) ">&gt; 3)),
which eventually results in sending fragments inside an already</comment>
<comment voter="covered area once ((n* 380) ">&gt; 3) is greater than 5120, which occurs
when n is reaches 108.  This would look a bit like TearDrop if
fragments were reassembled on-the-fly.

- 1 fragment such that the total length of all the fragments
is greater than 65535 (my calculation is 172*380 + 418 = 65778; the
comment about 65538 must be wrong).  The last packet is size 418
according to the IP header but the buffer is of size 400.  The sendto
takes as argument the size of the buffer so a truncated packet is
sent.

So, I am not sure if the problem is because the last packet
doesn't extend to the payload it says it has or because the total size
of all fragments is greater than 65535.  The author says it may take
more than one sending, so perhaps this has to do with an incorrect
error handling and recovery.  One would need to experiment and isolate
each of those characteristics and test them independently.  Inasmuch
as each of those things is likely a different vulnerability, then I
agree with Leblanc that this entry should be split.  I'll try that if
I ever get bored.  Jolt 2 should also have a different entry (see
below).

Jolt 2 runs in an infinite loop, sending the same fragmented
IP packet, which can pretend to be &quot;ICMP&quot; or &quot;UDP&quot; data; however this
is meaningless, as it's just a late fragment of an IP packet.  The
attack works only as long as packets are sent.  According to
http://www.securityfocus.com/archive/1/62170 the packets are
truncated, and would overflow over the 65535 byte limit, which is
similar to Jolt.  Note that Jolt does send that much data whereas
jolt2 doesn't.  Since jolt2 is simpler and narrower than jolt, and it
has weaker consequences, I believe that it's a different
vulnerability.

&quot;Jolt 2 vulnerability causes a temporary denial-of-service in
Windows-type OSes&quot; would be a title for it.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0347" seq="1999-0347">
<status>Candidate</status>
<phase date="20051028">Modified</phase>
<desc>Internet Explorer 4.01 allows remote attackers to read local files and spoof web pages via a &quot;%01&quot; character in an &quot;about:&quot; Javascript URL, which causes Internet Explorer to use the domain specified after the character.</desc>
<refs>
<ref source="BUGTRAQ" url="http://marc.theaimsgroup.com/?l=bugtraq&amp;m=91745430007021&amp;w=2">19990126 Javascript ecurity bug in Internet Explorer</ref>
<ref source="NTBUGTRAQ" url="http://marc.theaimsgroup.com/?l=ntbugtraq&amp;m=91756771207719&amp;w=2">19990126 Javascript ecurity bug in Internet Explorer</ref>
</refs>
<votes>
<accept count="4">Levy, LeBlanc, Northcutt, Baker</accept>
<modify count="2">Frech, Prosser</modify>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Prosser">this is a modified Cross-Frame vulnerability that circumvents
the original Cross-Frame Patch.  Addressed in MS Bulletin MS99.012
http://www.microsoft.com/security/bulletins/ms99-012.asp</comment>
<comment voter="Christey">Duplicate of CVE-1999-0490?</comment>
<comment voter="LeBlanc">If Prosser is correct that this is MS99-012, accept</comment>
<comment voter="Christey">BUGTRAQ:19990126 Javascript ecurity bug in Internet Explorer
URL:http://marc.theaimsgroup.com/?l=bugtraq&amp;m=91745430007021&amp;w=2
NTBUGTRAQ:19990128 Javascript %01 bug in Internet Explorer
URL:http://marc.theaimsgroup.com/?l=ntbugtraq&amp;m=91756771207719&amp;w=2
BID:197
URL:http://www.securityfocus.com/bid/197</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to MODIFY]</comment>
<comment voter="Frech">XF:ie-window-spoof(2069)</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0352" seq="1999-0352">
<status>Candidate</status>
<phase date="19990721">Proposed</phase>
<desc>ControlIT 4.5 and earlier (aka Remotely Possible) has weak password encryption.</desc>
<refs>
<ref source="ISS">Multiple vulnerabilities in ControlIT(tm) (formerly Remotely Possible/32) enterprise management software</ref>
<ref source="XF">controlit-passwd-encrypt</ref>
</refs>
<votes>
<accept count="2">Frech, Baker</accept>
<noop count="2">Northcutt, Wall</noop>
<recast count="1">Ozancin</recast>
</votes>
<comments>
<comment voter="Ozancin">Can we combine this with CVE-1999-0356 - ControlIT(tm) 4.5 and earlier uses
weak encryption.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0354" seq="1999-0354">
<status>Candidate</status>
<phase date="19990623">Proposed</phase>
<desc>Internet Explorer 4.x or 5.x with Word 97 allows arbitrary execution of Visual Basic programs to the IE client through the Word 97 template, which doesn't warn the user that the template contains executable content.  Also applies to Outlook when the client views a malicious email message.</desc>
<refs>
<ref source="NTBUGTRAQ">Jan27,1999</ref>
<ref source="MS" url="http://www.microsoft.com/technet/security/bulletin/ms99-002.asp">MS99-002</ref>
</refs>
<votes>
<accept count="3">Ozancin, Wall, Baker</accept>
<modify count="1">Frech</modify>
<noop count="1">Christey</noop>
</votes>
<comments>
<comment voter="Frech">XF:word97-template-macro</comment>
<comment voter="Christey">CHANGEREF NTBUGTRAQ:19990127 IE 4/5/Outlook + Word 97 security hole
URL:http://marc.theaimsgroup.com/?l=ntbugtraq&amp;m=91747570922757&amp;w=2
BID:196
http://www.securityfocus.com/bid/196</comment>
<comment voter="Christey">MSKB:Q214652
http://support.microsoft.com/support/kb/articles/q214/6/52.asp</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0356" seq="1999-0356">
<status>Candidate</status>
<phase date="19990721">Proposed</phase>
<desc>ControlIT v4.5 and earlier uses weak encryption to store usernames and passwords in an address book.</desc>
<refs>
<ref source="ISS">Multiple vulnerabilities in ControlIT(tm) (formerly Remotely Possible/32) enterprise management software</ref>
<ref source="XF">controlit-bookfile-access</ref>
</refs>
<votes>
<accept count="2">Frech, Baker</accept>
<noop count="2">Northcutt, Wall</noop>
<recast count="1">Ozancin</recast>
</votes>
<comments>
</comments>
</item>

<item type="CAN" name="CVE-1999-0359" seq="1999-0359">
<status>Candidate</status>
<phase date="20010214">Proposed</phase>
<desc>ptylogin in Unix systems allows users to perform a denial of service by locking out modems, dial out with that modem, or obtain passwords.</desc>
<refs>
<ref source="BUGTRAQ">19990127 UNIX shell modem access vulnerabilities</ref>
<ref source="XF">ptylogin-dos</ref>
</refs>
<votes>
<accept count="2">Cole, Frech</accept>
<modify count="1">Baker</modify>
</votes>
<comments>
<comment voter="Frech">XF:ptylogin-dos </comment>
<comment voter="Baker">Should say &quot;... lock out a modem, ...&quot; rather than &quot;... locking out modems...&quot;</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0360" seq="1999-0360">
<status>Candidate</status>
<phase date="20000530">Modified</phase>
<desc>MS Site Server 2.0 with IIS 4 can allow users to upload content, including ASP, to the target web site, thus allowing them to execute commands remotely.</desc>
<refs>
<ref source="BUGTRAQ" url="http://marc.theaimsgroup.com/?l=bugtraq&amp;m=91763097004101&amp;w=2">19990130 Security Advisory for Internet Information Server 4 with Site</ref>
<ref source="NTBUGTRAQ">Jan29,1999</ref>
</refs>
<votes>
<accept count="6">Landfield, Cole, Collins, Blake, Northcutt, Wall</accept>
<modify count="3">Frech, LeBlanc, Baker</modify>
<noop count="4">Armstrong, Ozancin, Christey, Prosser</noop>
</votes>
<comments>
<comment voter="Christey">I can't find the original Bugtraq posting (it appears that
mnemonix discovered the problem).</comment>
<comment voter="LeBlanc">- if there was a fix or a KB article, I'd ACCEPT. A vuln based on a
BUGTRAQ posting we can't find could be anything. </comment>
<comment voter="Baker">Vulnerability Reference (HTML)	Reference Type
http://www.securityfocus.com/archive/1/12218	Misc Defensive InfoVulnerability Reference (HTML)	Reference Type
THis is the URL for the Bugtraq posting.  It was cross posted to
NT Bugtraq as well, but identical text.  It was Mnemonix...</comment>
<comment voter="Christey">BID:1811
URL:http://www.securityfocus.com/bid/1811</comment>
<comment voter="Christey">CHANGEREF BUGTRAQ add &quot;Server 2.&quot; to the subject.
Also standardize NTBUGTRAQ reference title.</comment>
<comment voter="Christey">Add &quot;uploadn.asp&quot; to the description.</comment>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to MODIFY]</comment>
<comment voter="Frech">XF:siteserver-user-dir-permissions(5384)</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0361" seq="1999-0361">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>NetWare version of LaserFiche stores usernames and passwords unencrypted, and allows administrative changes without logging.</desc>
<refs>
<ref source="BUGTRAQ">Jan29,1999</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
<noop count="2">Northcutt, Wall</noop>
</votes>
<comments>
<comment voter="Frech">XF:compulink-pw-laserfiche(1679)
Normalize BUGTRAQ reference to:
BUGTRAQ:19990129 Compulink LaserFiche Client/Server - unencrypted passwords</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0364" seq="1999-0364">
<status>Candidate</status>
<phase date="20000426">Modified</phase>
<desc>Microsoft Access 97 stores a database password as plaintext in a foreign mdb, allowing access to data.</desc>
<refs>
<ref source="BUGTRAQ" url="http://marc.theaimsgroup.com/?l=bugtraq&amp;m=91816470220259&amp;w=2">19990204 Microsoft Access 97 Stores Database Password as Plaintext</ref>
</refs>
<votes>
<accept count="2">LeBlanc, Baker</accept>
<modify count="1">Frech</modify>
<noop count="2">Northcutt, Wall</noop>
</votes>
<comments>
<comment voter="CHANGE">[Frech changed vote from REVIEWING to MODIFY]</comment>
<comment voter="Frech">XF:access-weak-passwords(1774)
An older published reference (from our own Adam) would be
better:
ailab.coderpunks Newsgroup, 1998/06/23 &quot;Re: MS Access 2.0&quot;
http://x15.dejanews.com/[ST_rn=ps]/getdoc.xp?AN=365308578&amp;CONTEXT=9192
07028.1462108427&amp;hitnum=1</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0370" seq="1999-0370">
<status>Candidate</status>
<phase date="19991210">Modified</phase>
<desc>In Sun Solaris and SunOS, man and catman contain vulnerabilities that allow overwriting arbitrary files.</desc>
<refs>
<ref source="SUN">00184</ref>
<ref source="BID" url="http://www.securityfocus.com/bid/165">165</ref>
</refs>
<votes>
<accept count="4">Dik, Prosser, Northcutt, Baker</accept>
<modify count="1">Frech</modify>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">Reference: XF:sun-man</comment>
<comment voter="Christey">ADDREF CIAC:J-028

Is the Linux man symlink problem the same as the one for Sun?
See BUGTRAQ:19990602 /tmp symlink problems in SuSE Linux 6.1
Also see BID:305</comment>
<comment voter="Dik">sun bug 4154565</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0381" seq="1999-0381">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>super 3.11.6 and other versions have a buffer overflow in the syslog utility which allows a local user to gain root access.</desc>
<refs>
<ref source="BUGTRAQ" url="http://www.securityfocus.com/templates/archive.pike?list=1&amp;msg=Pine.LNX.3.96.990225011801.12757A-100000@eleet">19990225 SUPER buffer overflow</ref>
<ref source="XF">linux-super-logging-bo</ref>
<ref source="BID" url="http://www.securityfocus.com/bid/342">342</ref>
</refs>
<votes>
<accept count="7">Landfield, Cole, Frech, Ozancin, Levy, Blake, Baker</accept>
<modify count="1">Bishop</modify>
<noop count="2">Armstrong, Wall</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">Is this the same as CVE-1999-0373?  They both have the same
X-Force reference.

BID:342 suggests that there are two.

http://www.debian.org/security/1999/19990215a suggests
that there are two.  However, CVE-1999-0373 is written up in
a fashion that is too general; and both XF:linux-super-bo and
XF:linux-super-logging-bo refer to CVE-1999-0373.
CVE-1999-0373 may need to be split.
</comment>
<comment voter="Frech">From what I can surmise, ISS released the original advisory (attached to
linux-super-bo), and Sekure SDI expanded on it by releasing another related
overflow in syslog (which is linux-super-logging-bo).

When I was originally assigning these issues, I placed both XF references
and the ISS advisory on the -0373 candidate, since there was nothing else
available. Based on the information above, I'd request that
XF:linux-super-logging-bo be removed from CVE-1999-0373.</comment>
<comment voter="Christey">Given Andre's feedback, these are different issues.
CVE-1999-0373 does not need to be split because the ISS
reference is sufficient to distinguish that CVE from this
candidate; however, the CVE-1999-0373 description should
probably be modified slightly.</comment>
<comment voter="Bishop">(as indicated by Christey)</comment>
<comment voter="CHANGE">[Cole changed vote from NOOP to ACCEPT]</comment>
<comment voter="CHANGE">[Christey changed vote from NOOP to REVIEWING]</comment>
<comment voter="Christey">There are 2 bugs, as confirmed by the super author at:
BUGTRAQ:19990226 Buffer Overflow in Super (new)
http://www.securityfocus.com/archive/1/12713
BID:397 also seems to cover this one, and it may cover
CVE-1999-0373 as well.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0389" seq="1999-0389">
<status>Candidate</status>
<phase date="19991207">Modified</phase>
<desc>Buffer overflow in the bootp server in the Debian Linux netstd package.</desc>
<refs>
<ref source="DEBIAN">19990104</ref>
<ref source="BUGTRAQ">19990103 [SECURITY] New versions of netstd fixes buffer overflows</ref>
<ref source="BID" url="http://www.securityfocus.com/bid/324">324</ref>
</refs>
<votes>
<accept count="3">Ozancin, Stracener, Baker</accept>
<modify count="1">Frech</modify>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">Is CVE-1999-0389 a duplicate of CVE-1999-0798?  CVE-1999-0389
has January 1999 dates associated with it, while CVE-1999-0798
was reported in late December.

Also, is this the same line of code as CVE-1999-0914?  Both are in
the netstd package, it could look like a library problem.

However, deep in the changelog in the
netstd_3.07-7slink.3.diff on Debian, Herbert Xu includes
the following entry:

+netstd (3.07-7slink.1) frozen; urgency=high
+
+  * bootpd:     Applied patch from Redhat as well as a fix for the overflow in
+                report() (fixes #30675).
+  * netkit-ftp: Applied patch from RedHat that fixes some obscure overflow
+                bugs.
+
+ -- Herbert Xu &lt;herbert@debian.org&gt;  Sat, 19 Dec 1998 14:36:48 +1100

This tells me that two separate bugs are involved.

Note that Red Hat posted *some* fix for *some* bootp problem
in June 1998.  See:
http://www.redhat.com/support/errata/rh42-errata-general.html#bootp</comment>
<comment voter="Frech">XF:debian-netstd-bo</comment>
<comment voter="Christey">Further analysis indicates that this is a duplicate of CVE-1999-0799</comment>
<comment voter="CHANGE">[Christey changed vote from REJECT to REVIEWING]</comment>
<comment voter="Christey">The fix information for BID:324 suggests that there are two
overflows, one of which is in handle_request (bootpd.c) and is
likely related to a file name; but there is another issue in
report (report.c) which also looks like a straightforward
overflow, which would suggest that this is not a duplicate of
CVE-1999-0798 or CVE-1999-0799.

Note: see comments for CVE-1999-0798 which explain how that
candidate is not related to CVE-1999-0799.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0394" seq="1999-0394">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>DPEC Online Courseware allows an attacker to change another user's password without knowing the original password.</desc>
<refs>
<ref source="BUGTRAQ">19990115 DPEC Online Courseware</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<noop count="1">Christey</noop>
<reject count="1">Frech</reject>
</votes>
<comments>
<comment voter="Frech">If I understand the issue, this HIGHCARD involves insecure web programming. 
If I don't understand, mark this as my first NOOP.</comment>
<comment voter="Christey">CONFIRM:http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist%3D1%26msg%3D19990803132618.16407.qmail%40securityfocus.com
ADDREF BID:565
URL:http://www.securityfocus.com/vdb/bottom.html?vid=565</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0397" seq="1999-0397">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>The demo version of the Quakenbush NT Password Appraiser sends passwords across the network in plaintext.</desc>
<refs>
<ref source="L0PHT">Jan21,1999</ref>
<ref source="BUGTRAQ">Jan21,1999</ref>
</refs>
<votes>
<accept count="1">Northcutt</accept>
<modify count="1">Frech</modify>
<noop count="1">Baker</noop>
<reject count="1">Wall</reject>
</votes>
<comments>
<comment voter="Wall">Reject based on beta copy.</comment>
<comment voter="Frech">XF:quakenbush-pw-appraiser(1652)</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0398" seq="1999-0398">
<status>Candidate</status>
<phase date="20000106">Modified</phase>
<desc>In some instances of SSH 1.2.27 and 2.0.11 on Linux systems, SSH will allow users with expired accounts to login.</desc>
<refs>
<ref source="BUGTRAQ">19990123 SSH 1.x and 2.x Daemon</ref>
<ref source="BUGTRAQ">19990124 SSH Daemon</ref>
<ref source="XF">ssh-exp-account-access</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
</votes>
<comments>
<comment voter="Frech">Followups to the bugtraq message (1/24/99) indicate that 1.2.27 was not yet
released. v1.2.26 should be substituted in the description for '27.
XF:ssh-exp-account-access</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0399" seq="1999-0399">
<status>Candidate</status>
<phase date="20000105">Modified</phase>
<desc>The DCC server command in the Mirc 5.5 client doesn't filter characters from file names properly, allowing remote attackers to place a malicious file in a different location, possibly allowing the attacker to execute commands.</desc>
<refs>
<ref source="BUGTRAQ">19990124 Mirc 5.5 'DCC Server' hole</ref>
<ref source="XF">mirc-dcc-metachar-filename</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
</votes>
<comments>
<comment voter="Frech">XF:mirc-dcc-metachar-filename</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0400" seq="1999-0400">
<status>Candidate</status>
<phase date="20000105">Modified</phase>
<desc>Denial of service in Linux 2.2.0 running the ldd command on a core file.</desc>
<refs>
<ref source="BUGTRAQ">19990127 2.2.0 SECURITY (fwd)</ref>
<ref source="XF">linux-kernel-ldd-dos</ref>
<ref source="BID" url="http://www.securityfocus.com/bid/344">344</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
</votes>
<comments>
<comment voter="Frech">BUGTRAQ:Jan27,1999
(http://www.securityfocus.com/templates/archive.pike?list=1&amp;date=1999-01-22&amp;
msg=Pine.LNX.4.05.9901270538380.539-100000@vitelus.com)
XF:linux-kernel-ldd-dos</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0401" seq="1999-0401">
<status>Candidate</status>
<phase date="20000105">Modified</phase>
<desc>A race condition in Linux 2.2.1 allows local users to read arbitrary memory from /proc files.</desc>
<refs>
<ref source="BUGTRAQ">19990202 [patch] /proc race fixes for 2.2.1 (fwd)</ref>
<ref source="XF">linux-race-condition-proc</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
</votes>
<comments>
<comment voter="Frech">XF:linux-race-condition-proc</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0406" seq="1999-0406">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>Digital Unix Networker program nsralist has a buffer overflow which allows local users to obtain root privilege.</desc>
<refs>
<ref source="BUGTRAQ">Feb19,1999</ref>
<ref source="XF">digital-networker-bo</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
</votes>
<comments>
<comment voter="Frech">In description, change 'which' to 'that'.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0411" seq="1999-0411">
<status>Candidate</status>
<phase date="19990726">Proposed</phase>
<desc>Several startup scripts in SCO OpenServer Enterprise System v 5.0.4p, including S84rpcinit, S95nis, S85tcp, and S89nfs, are vulnerable to a symlink attack, allowing a local user to gain root access.</desc>
<refs>
<ref source="BUGTRAQ">Feb19,1999</ref>
<ref source="XF">sco-startup-scripts</ref>
</refs>
<votes>
<modify count="2">Baker, Frech</modify>
<noop count="2">Christey, Wall</noop>
</votes>
<comments>
<comment voter="Frech">Neither XFDB nor the BugTraq article (incidentally, shows up as 7 March, not
19 February) does not mention gaining root access... it says a local user
could
&quot;delete or overwrite arbitrary files on the system.&quot;</comment>
<comment voter="Baker">By overwriting arbitrary files, one could then gain root access.  I agree with a minor description change to reflect this.</comment>
<comment voter="Christey">Normalize Bugtraq reference to:
BUGTRAQ:19990307 Little exploit for startup scripts (SCO 5.0.4p).
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=92087765014242&amp;w=2
Also, SCO:SB-99.17
ftp://ftp.sco.com/SSE/security_bulletins/SB-99.17c</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0418" seq="1999-0418">
<status>Candidate</status>
<phase date="20010912">Proposed</phase>
<desc>Denial of service in SMTP applications such as Sendmail, when a remote attacker (e.g. spammer) uses many &quot;RCPT TO&quot; commands in the same connection.</desc>
<refs>
<ref source="BUGTRAQ" url="http://marc.theaimsgroup.com/?l=bugtraq&amp;m=92100018214316&amp;w=2">19990308 SMTP server account probing</ref>
</refs>
<votes>
<accept count="1">Cole</accept>
<modify count="1">Frech</modify>
<noop count="3">Baker, Foat, Wall</noop>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Christey">DUPE CVE-1999-0144 and CVE-1999-0250?</comment>
<comment voter="Frech">XF:smtp-rctpto-dos(7499)</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0419" seq="1999-0419">
<status>Candidate</status>
<phase date="20000105">Modified</phase>
<desc>When the Microsoft SMTP service attempts to send a message to a server and receives a 4xx error code, it quickly and repeatedly attempts to redeliver the message, causing a denial of service.</desc>
<refs>
<ref source="BUGTRAQ">19990319 Microsoft's SMTP service broken/stupid</ref>
<ref source="XF">smtp-4xx-error-dos</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="2">Frech, LeBlanc</modify>
<reviewing count="1">Christey</reviewing>
</votes>
<comments>
<comment voter="Frech">XF:smtp-4xx-error-dos</comment>
<comment voter="LeBlanc">- if we can find a KB or something that shows that this wasn't just
user error, I'd vote ACCEPT.</comment>
<comment voter="Christey">David Lemson, Microsoft SMTP Service Program Manager,
posted a followup that said &quot;We have confirmed this as a
problem...&quot;
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=92171608127206&amp;w=2</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0426" seq="1999-0426">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>The default permissions of /dev/kmem in Linux versions before 2.0.36 allows IP spoofing.</desc>
<refs>
<ref source="BUGTRAQ">19990319 The default permissions on /dev/kmem is insecure.</ref>
</refs>
<votes>
<modify count="1">Frech</modify>
<noop count="1">Baker</noop>
<reject count="1">Christey</reject>
</votes>
<comments>
<comment voter="Frech">XF:linux-dev-kmem-spoof</comment>
<comment voter="Christey">DUPE CVE-1999-0414
XF:linux-dev-kmem-spoof does not exist.</comment>
<comment voter="Christey">*Now* XF:linux-dev-kmem-spoof(3500) exists...</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0427" seq="1999-0427">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>Eudora 4.1 allows remote attackers to perform a denial of service by sending attachments with long file names.</desc>
<refs>
<ref source="BUGTRAQ">19990320 Eudora Attachment Buffer Overflow</ref>
<ref source="XF">eudora-long-attachments</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
<noop count="1">Christey</noop>
</votes>
<comments>
<comment voter="Frech">Change version number to 4.2beta. Second to last paragraph in bugtraq
reference states: &quot;Both the Win 95 and Win NT versions, along with the 4.2
beta of Eudora are affected.&quot;</comment>
<comment voter="Christey">This issue seems to have been rediscovered in
BUGTRAQ:20000515 Eudora Pro &amp; Outlook Overflow - too long filenames again
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=95842482413076&amp;w=2

Also see
BUGTRAQ:19990320 Eudora Attachment Buffer Overflow
http://marc.theaimsgroup.com/?l=bugtraq&amp;m=92195396912110&amp;w=2

Is this a duplicate/subsumed by CVE-1999-0004?</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0431" seq="1999-0431">
<status>Candidate</status>
<phase date="20000106">Modified</phase>
<desc>Linux 2.2.3 and earlier allow a remote attacker to perform an IP fragmentation attack, causing a denial of service.</desc>
<refs>
<ref source="BUGTRAQ">19990324 DoS for Linux 2.1.89 - 2.2.3: 0 length fragment bug</ref>
<ref source="XF">linux-zerolength-fragment  </ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
<noop count="1">Christey</noop>
</votes>
<comments>
<comment voter="Frech">XF:linux-zerolength-fragment  </comment>
<comment voter="Christey">Consider adding BID:2247</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0434" seq="1999-0434">
<status>Candidate</status>
<phase date="19990728">Proposed</phase>
<desc>XFree86 xfs command is vulnerable to a symlink attack, allowing local users to create files in restricted directories, possibly allowing them to gain privileges or cause a denial of service.</desc>
<refs>
<ref source="BUGTRAQ">19990331 Bug in xfs</ref>
<ref source="BID" url="http://www.securityfocus.com/bid/359">359</ref>
</refs>
<votes>
<accept count="1">Baker</accept>
<modify count="1">Frech</modify>
<noop count="1">Christey</noop>
</votes>
<comments>
<comment voter="Frech">XF:xfree86-xfs-symlink-dos</comment>
<comment voter="Christey">Is this the same problem as CVE-1999-0433?  CVE-1999-0433
deals with a symlink attack on one file (/tmp/.X11-unix),
while xfs (this candidate) deals with /tmp/.font-unix
XF:xfree86-xfs-symlink-dos doesn't exist.</comment>
<comment voter="Christey">ADDREF DEBIAN:19990331 symbolic link can be used to make any file world readable
Note: Debian's advisory says that this is not a problem for Debian.</comment>
</comments>
</item>

<item type="CAN" name="CVE-1999-0435" seq="1999-0435">
<status>Candidate</status>
<phase date="199