|
|
|
[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?
|
||||
