CVE List
| Id | CVE No. | Status | Description | Phase | Votes | Comments | Actions |
|---|---|---|---|---|---|---|---|
| 197 | CVE-1999-0197 | Candidate | finger 0@host on some systems may print information on some user accounts. | Proposed (19990726) | ACCEPT(1) Baker | MODIFY(2) Frech, Shostack | REJECT(1) Northcutt | Shostack> fingerd may respond to "finger 0@host" with account info | Frech> Need more reference to establish this "exposure". | CHANGE> [Frech changed vote from REVIEWING to MODIFY] | 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) | View |
| 221 | CVE-1999-0222 | Candidate | Denial of service in Cisco IOS web server allows attackers to reboot the router using a long URL. | Proposed (19990714) | ACCEPT(1) Baker | MODIFY(3) Frech, Levy, Shostack | NOOP(3) Balinsky, Northcutt, Wall | RECAST(1) Ziese | REJECT(1) Christey | Shostack> I follow cisco announcements and problems pretty closely, and haven"t | seen this. Source? | Frech> XF:cisco-web-crash | 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? | Levy> BUGTGRAQ: http://www.securityfocus.com/archive/1/60159 | BID 1154 | Ziese> The vulnerability is addressed by a vendor acknowledgement. This one, if | recast to reflect that "...after using a long url..." should be replaced | with | "...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 "http://router-ip/anytext?/" is attempted, and the enable | password is supplied when requested. This defect can be exploited to produce | a denial of service (DoS) attack." | Then I can accept this and mark it as "Verfied by my Company". If it can"t | be recast because this (long uri) is diffferent then our release (special | url construction). | CHANGE> [Christey changed vote from REVIEWING to REJECT] | 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. | View |
| 528 | CVE-1999-0531 | Candidate | ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: None. Reason: this candidate is solely about a configuration that does not directly introduce security vulnerabilities, so it is more appropriate to cover under the Common Configuration Enumeration (CCE). Notes: the former description is: "An SMTP service supports EXPN, VRFY, HELP, ESMTP, and/or EHLO." | Modified (20080731) | MODIFY(1) Frech | NOOP(1) Christey | RECAST(1) Shostack | REJECT(1) Northcutt | Shostack> I think expn != vrfy, help, esmtp. | Frech> XF:lotus-domino-esmtp-bo(4499) (also assigned to CVE-2000-0452 and | CVE-2000-1046) | XF:smtp-expn(128) | XF:smtp-vrfy(130) | XF:smtp-helo-bo(886) | XF:smtp-vrfy-bo(887) | XF:smtp-expn-bo(888) | XF:slmail-vrfyexpn-overflow(1721) | XF:smtp-ehlo(323) | | Perhaps add RCPT? If so, add XF:smtp-rcpt(1928) | Christey> XF:smtp-vrfy(130) ? | View |
| 550 | CVE-1999-0565 | Candidate | A Sendmail alias allows input to be piped to a program. | Proposed (19990728) | ACCEPT(1) Northcutt | NOOP(1) Baker | RECAST(1) Shostack | REVIEWING(1) Christey | Shostack> Is this a default alias? Is my .procmailrc an instance of this? | Christey> It is not entirely clear whether the simple fact that an alias | pipes into a program should be considered a vulnerability. It | all depends on the behavior of that particular program. This | is one of a number of configuration-related issues from the | "draft" CVE that came from vulnerability scanners. In | general, when we get to general configuration and "policy," | it becomes more difficult to use the current CVE model to | represent them. So at the very least, this candidate (and | similar ones) should be given close consideration and | discussion before being added to the official CVE list. | | Because this candidate is related to general configuration | issues, and we have not completely determined how to handle | such issues in CVE, this candidate cannot be promoted to an | official CVE entry until such issues are resolved. | View |
| 490 | CVE-1999-0492 | Candidate | The ffingerd 1.19 allows remote attackers to identify users on the target system based on its responses. | Proposed (19990726) | ACCEPT(3) Armstrong, Collins, Northcutt | MODIFY(4) Baker, Blake, Frech, Shostack | NOOP(4) Christey, Cole, Landfield, Wall | REVIEWING(1) Ozancin | Shostack> isn"t that what finger is supposed to do? | Landfield> Maybe we need a new category of "unsafe system utilities and protocols" | Blake> Ffingerd 1.19 allows remote attackers to differentiate valid and invalid | usernames on the target system based on its responses to finger queries. | Christey> CHANGEREF BUGTRAQ [canonicalize] | BUGTRAQ:19990423 Ffingerd privacy issues | http://marc.theaimsgroup.com/?l=bugtraq&m=92488772121313&w=2 | | Here"s the nature of the problem. | (1) FFingerd allows users to decide not to be fingered, | printing a message "That user does not want to be fingered" | (2) If the fingered user does not exist, then FFingerd"s | intended default is to print that the user does not | want to be fingered; however, the error message has a | period at the end. | Thus, ffingerd can allow someone to determine who valid users | on the server are, *in spite of* the intended functionality of | ffingerd itself. Thus this exposure should be viewed in light | of the intended functionality of the application, as opposed | to the common usage of the finger protocol in general. | | Also, the vendor posted a followup and said that a patch was | available. See: | http://marc.theaimsgroup.com/?l=bugtraq&m=92489375428016&w=2 | Baker> Vulnerability Reference (HTML) Reference Type | http://www.securityfocus.com/archive/1/13422 Misc Defensive Info | CHANGE> [Frech changed vote from REVIEWING to MODIFY] | Frech> XF:ffinger-user-info(5393) | View |
Page 20929 of 20943, showing 5 records out of 104715 total, starting on record 104641, ending on 104645
