[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: First candidate cluster for validation: CERT


Here are my comments on the CERT candidate cluster... a few more
MODIFY's than I might have liked, considering I created 'em in the
first place, but there ya go.  At least I didn't have any REJECT or
RECAST comments :)

I removed most of the candidate information when commenting.  For
those who review my comments - would you have preferred to have the
other candidate information included (e.g. description or references)?
I want to avoid "clutter" as much as possible.

- Steve



------------------------------------------
ACCEPT CAN-1999-0003

------------------------------------------
MODIFY CAN-1999-0004

Add reference: MS:MS98-008

[We don't *need* to make sure we have *all* references, but I believe
that if we run across one, why not add it?]

Change description:

"MIME buffer overflow in email clients, e.g. Solaris mailtool and
Outlook."

------------------------------------------
MODIFY CAN-1999-0005

It's difficult to distinguish between this vulnerability and another
IMAP vulnerability via just the textual description.  (The other
vulnerability is CVE-00042, not yet proposed as a candidate for some
odd reason).  I had to reference the different CERT advisories to
distinguish between this candidate and CVE-00042.  The X-Force
database says that "[the CVE-00042 vulnerability is in] the IMAP LOGIN
command whereas [CAN-1999-0005] affects the IMAP AUTHENTICATE
command."  I propose modifying the description to say something to
this effect, though the typical analyst may still need to rely on the
references.

------------------------------------------
ACCEPT CAN-1999-0006
ACCEPT CAN-1999-0007
ACCEPT CAN-1999-0008
ACCEPT CAN-1999-0013
ACCEPT CAN-1999-0014

------------------------------------------
REVIEWING CAN-1999-0017

"FTP bounce attack to connect to arbitrary ports on machines other
than the FTP client."

I think Steve Northcutt makes a good point.  The description needs to
be modified.

------------------------------------------
MODIFY CAN-1999-0018

No need to mention the CERT advisory in the text of the description.

------------------------------------------
ACCEPT CAN-1999-0019
ACCEPT CAN-1999-0021

ACCEPT CAN-1999-0022
ACCEPT CAN-1999-0023

Note that the descriptions of CAN-1999-0022 and CAN-1999-0023 are
extremely similar; this is a case where someone looking up the name
for "rdist buffer overflow" might have to look at the references to
see which "rdist buffer overflow" is associated with which CERT
advisory.

------------------------------------------
ACCEPT CAN-1999-0024
ACCEPT CAN-1999-0032
ACCEPT CAN-1999-0033
ACCEPT CAN-1999-0034
ACCEPT CAN-1999-0035
ACCEPT CAN-1999-0036
ACCEPT CAN-1999-0038
ACCEPT CAN-1999-0039
ACCEPT CAN-1999-0040
ACCEPT CAN-1999-0041
ACCEPT CAN-1999-0043
ACCEPT CAN-1999-0045
ACCEPT CAN-1999-0046
ACCEPT CAN-1999-0049
ACCEPT CAN-1999-0050
ACCEPT CAN-1999-0051


------------------------------------------
MODIFY CAN-1999-0067

I agree with Adam that "shell metacharacters" is too high a level of
abstraction.  I believe that phf and php and the others should be
distinguished.  However, it might be better to change the description
to say "CGI phf program allows remote command execution via shell
metacharacters."

------------------------------------------
ACCEPT CAN-1999-0073

------------------------------------------
MODIFY CAN-1999-0078

I don't believe that the XF:nfs-pcnfsd reference exists any more, so
we can delete it.  (Andre?)

------------------------------------------
ACCEPT CAN-1999-0080
ACCEPT CAN-1999-0099
ACCEPT CAN-1999-0117
ACCEPT CAN-1999-0128

Note: CAN-1999-0128 refers to "oversized ICMP ping packets."  We
should try to standardize on terminology for "oversized" (not to
mention various other terms).  There are other vulnerabilities where
you can cause a buffer overflow with a "long URL" or a "long HELO
command" and the like.  I thing I prefer using the term "oversized."
Comments?  Alternates?

------------------------------------------
ACCEPT CAN-1999-0129
ACCEPT CAN-1999-0130
ACCEPT CAN-1999-0131
ACCEPT CAN-1999-0132
ACCEPT CAN-1999-0133
ACCEPT CAN-1999-0134
ACCEPT CAN-1999-0135
ACCEPT CAN-1999-0136
ACCEPT CAN-1999-0137
ACCEPT CAN-1999-0141

------------------------------------------
REVIEWING CAN-1999-0142

Noting Steve Northcutt's comments, perhaps we would need to modify the
description somewhat to distinguish between current Java versions and
the one that had this vulnerability.  However, the CERT reference
associates a general place and time for where this vulnerability
arose, so I don't think it's too big of a deal.

------------------------------------------
ACCEPT CAN-1999-0143
ACCEPT CAN-1999-0155
ACCEPT CAN-1999-0164
ACCEPT CAN-1999-0207
ACCEPT CAN-1999-0208
ACCEPT CAN-1999-0209
ACCEPT CAN-1999-0267
ACCEPT CAN-1999-0277
ACCEPT CAN-1999-0334
ACCEPT CAN-1999-0337
ACCEPT CAN-1999-0338

------------------------------------------
REVIEWING CAN-1999-0513

"ICMP messages to broadcast addresses are allowed, allowing for a Smurf
attack that can cause a denial of service."

This one is an interesting case.  As Steve noted, this configuration
problem could allow for ping mapping as well.  I think the distinction
is that for Smurf, there's a forged source IP address, and that's
generally not the case when you're doing ping mapping.  So do we have
a single vulnerability (ICMP to broadcast) with 2 separate
implications?  Or, do we have two separate vulnerabilities, where one
accounts for the "design flaw" of spoofed IP addresses and another one
is a vulnerability because it allows information gathering?
Page Last Updated or Reviewed: May 22, 2007