RE: PROPOSAL: Cluster 23 NETCONF - (12 candidates)

["Northcutt, Stephen, CIV, BMDO/DSC" <Stephen.Northcutt@bmdo.osd.mil>]

My modifier to the rule of thumb below, would be or known serious
harm could occur.  Votes are in line.

-----Original Message-----
From: Steven M. Christey [mailto:coley@LINUS.MITRE.ORG]
Sent: Monday, July 26, 1999 8:23 PM
To: cve-editorial-board-list@lists.mitre.org
Subject: PROPOSAL: Cluster 23 NETCONF - (12 candidates)


The following candidates are associated with network configuration,
mostly dealing with filters of one sort or another.

Some of these candidates satisfy the CVE vulnerability definition
because they are useful for information gathering activities, even
though they "work as advertised."  Consider allowing traceroute or DNS
zone transfers.  Should those candidates be treated the same as
running finger?

Let's consider Gene Spafford's rule of thumb:

>Any software that functions according to its specification, and whose
>correct functioning is within the bounds of a common security policy
>(but not necessarily *every* policy) will NOT be considered a
>vulnerability for inclusion in the CVE."
>
>the finger program would not be a vulnerability so long as all
>of its functions are correct and known.   We might allow its use in
>an academic environment, so it is not a vulnerability.

Does this rule of thumb apply to the candidates in this NETCONF
cluster?

A different issue - how far do we go to separate the functions of
various devices on the network?  In the draft CVE, I've identified two
different types of devices: hosts, and network management devices
(e.g. routers, firewalls, IDSes) which deal with managing the traffic
between hosts.  The roles of routers/firewalls/IDSes/etc. are nearly
interchangeable, so I do not think it is appropriate to make separate
CVE entries for each one, in most cases.  I call this the "Two
Different Network Devices" content decision, which is a specialization
of "Different Functionality, Different Configuration Problem."

- Steve




Summary of votes to use (in ascending order of "severity"):

ACCEPT - member accepts the candidate as proposed
NOOP - member has no opinion on the candidate
MODIFY - member wants to change some minor detail (e.g.
reference/description)
REVIEWING - member is reviewing/researching the candidate
RECAST - candidate must be significantly modified, e.g. split or merged
REJECT - candidate is "not a vulnerability", or a duplicate, etc.

Please write your vote on the line that starts with "VOTE: ".  If you
want to add comments or details, add them to lines after the VOTE: line.


=================================
Candidate: CAN-1999-0510
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

A router or firewall allows source routed packets from arbitrary
hosts.

VOTE: ACCEPT

=================================
Candidate: CAN-1999-0511
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

IP forwarding is enabled on a machine which is not a router or
firewall.

VOTE: ACCEPT

=================================
Candidate: CAN-1999-0523
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

ICMP echo (ping) is allowed from arbitrary hosts.

VOTE: REJECT
(Though I sympathize with this one :)

=================================
Candidate: CAN-1999-0524
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

ICMP information such as netmask and timestamp is allowed from
arbitrary hosts.

VOTE:REJECT

=================================
Candidate: CAN-1999-0525
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

IP traceroute is allowed from arbitrary hosts.

VOTE:REJECT

=================================
Candidate: CAN-1999-0528
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

A router or firewall forwards external packets that claim to come from
inside the network that the router/firewall is in front of.

VOTE:ACCEPT

=================================
Candidate: CAN-1999-0529
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

A router or firewall forwards packets that claim to come from IANA
reserved or private addresses, e.g. 10.x.x.x, 127.x.x.x, 217.x.x.x,
etc.

VOTE:REJECT
I have seen ISPs "assign" private addresses within their domain

=================================
Candidate: CAN-1999-0532
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

A DNS server allows zone transfers.

VOTE:REJECT
(With split DNS implementations this is quite appropriate)

=================================
Candidate: CAN-1999-0533
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

A DNS server allows inverse queries.

VOTE:REJECT 
(rule of thumb)

=================================
Candidate: CAN-1999-0550
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

A router's routing tables can be obtained from arbitrary hosts.

VOTE:RECAST
Don't you mean obtained by arbitrary hosts

=================================
Candidate: CAN-1999-0571
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF
Reference: BUGTRAQ:Feb5,1999

A router allows arbitrary hosts to connect to its configuration
service, or related services such as telnet.

VOTE:NOOP

=================================
Candidate: CAN-1999-0588
Published:
Final-Decision:
Interim-Decision:
Modified:
Announced: 19990726
Assigned: 19990607
Category: CF

A filter in a router or firewall allows unusual fragmented packets.

VOTE:REJECT

I want to vote to accept this one, but unusual is a shade broad.