CONTENT DECISION: Data Access Configuration Problems

["Steven M. Christey" <coley@linus.mitre.org>]

The following content decisions are related to the DATA candidate
cluster.

Many configuration problems are related to the incorrect specification
of access restrictions for data.  In many cases, the data may be
critical to maintaining the system's security.  But even if the data
is restricted to a group of users, the enterprise may believe that one
of those users should not have access to that data.  The
interpretation of "security" in these cases is very
enterprise-specific.  But it's fairly universal that if "anyone" can
access critical data, then it poses a security problem.

Other data may not be critical to the entire system, but it is
critical to the effective operation of a particular application.

The variety of configurations available is further complicated by user
groups, different types of data manipulation
(read/write/create/execute), different types of data objects
(file/folder/share), and different types of authentication methods.

To enumerate each permutation could make the CVE unmanageable and
unnecessarily complicated.  Consider the thousands of NT registry keys
used by hundreds of applications.  With different
read/write/etc. permissions, the myriad user groups, local and network
users, and different administration roles, it could take more than
10,000 CVE entries to enumerate all the permutations for registry keys
alone.

I suggest that at this time, further research is required to determine
the appropriate levels of abstraction for these types of problems.
Perhaps a more robust representation is required to effectively
identify these kinds of problems at a level that is appropriate for
productive data sharing.  I have made some simplifications that I
outline below.  While I created these definitions to apply to data
access configuration problems, they might be useful for describing
many other kinds of configuration errors.




*********************************
Background Definitions (informal)
*********************************

Data Service
------------

An application or network service that provides data to a user,
e.g. NFS, FTP, TFTP, NETBIOS/Samba, a database server, etc.


Network-Accessible
------------------

A Data Service is network-accessible to an entity if network
configuration does not prevent that entity from establishing a
connection with a Data Service.  This does *NOT* include any
restrictions that are defined on the host which provides the Data
Service itself; but it does include restrictions such as firewalls,
filtering routers, etc.


User Groups
-----------

There are two fundamentally different groups of users that can access
the data: "Anyone" or "Restricted Group."


"Anyone" is defined as:
  - Network access
    - For every Network-Accessible host, there is at least one user
      (or administrator) on that host who can access the data
  - Local access
   - Every user on the system has access

"Restricted Group" is defined as:
  - Network access
    - There is at least one Network-Accessible host in which at least
      one user (or administrator) on that host can NOT access the data
  - Local access
    - At least one user on the system does not have access


I will grant that "Anyone" is a slight misnomer.  From the network
perspective, "Anyone" is defined in a way that ignores what privileges
are required to conduct an attack, and effectively allows us to treat
an entire host as if it were compromised.  For example, suppose an NFS
file system is exported to the world; any Unix machine could
conceivably access that data, although only the root user would be
able to mount the file system.  While privileges are important in
terms of risk, likelihood of attack, and the success of an attack,
they should not be considered by the CVE.


Data Operations
---------------

Read, Write, Execute, Delete, Create, etc.


Data Formats
------------

Folders, Directories, Files, File Systems, Partitions, Shares,
Messages, etc.


Security Aspects of Data
------------------------

System-Critical Data - data is system-critical if there is a Data
Operation which, if used, could allow some entity to:
  - gain privileges as a user or admin on the system
  - gain access to otherwise restricted data residing on the system
  - deny service to the entire system (or other systems with
    dependencies on that system)

If such a Data Operation exists for an attacker who is not a
designated administrator for that system, then the associated
configuration is *inappropriate*.

Examples: a password file is System-Critical Data, since (a) if any
non-root user can write to it, they gain access, and (b) if any
non-local user can read it, they (most likely) gain access.  A user's
..cshrc file is System-Critical since, if an attacker modifies it, that
file allows the attacker to execute commands as the user.


Application-Critical Data - data is application-critical if there is a
Data Operation which, if used, could allow some entity to:
  - gain privileges *as an application-defined user*
  - gain access to otherwise restricted data *in that application*
  - deny service *for that application only* (or other applications
    that depend on that application).

If such a Data Operation exists for an attacker who is not a
designated administrator for that system, then the associated
configuration is *inappropriate*.

Examples of Application-Critical data includes any application's
configuration file.  A web server's ACL list for certain URLs would be
Application-Critical.


Non-Critical Data - Data that is not System-Critical or
Application-Critical


The Application-Critical definition limits the scope of access to what
the application is designed to handle.  For example, a database server
or a web server may have its own set of "users" which are not the same
as "users" in the underlying OS; it may restrict access to pages or
tables to some "users," but not to others.

Data that is both Application-Critical and System-Critical, will be
considered to be System-Critical.



*****************
Content Decisions
*****************

1) Different Data Operation, Same Vulnerability

Separating reads from writes is entirely dependent on what type of
data is involved.  It's whether the data is critical or not that
represents a vulnerability.


2) Different Data Format, Same Vulnerability

There are many different data formats that are effectively different
flavors of two primary formats, i.e. "file" and "directory."  I
haven't found a good reason to keep the two separated; yes, there is
different risk involved, but risk is not a discriminator due to the
high-level "Different Risk Same Vulnerability" content decision for
configuration problems.


3) Different Data Service, Different Vulnerability

Distinguish between NFS, FTP, etc.


4) Restricted Group Access is not a CVE vulnerability

This is too dependent on the enterprise's interpretation of group
membership for specific individuals.  It's security-related in the
sense that if the wrong individual is given access, the enterprise's
security may suffer; but if *specified* access allows an individual to
perform certain operations, that in itself should not be regarded as a
vulnerability.


5) Access to Non-Critical data is not a CVE vulnerability

Inappropriate access to Non-Critical data results in inconvenience or
release of restricted information; it may be critical from an
enterprise's perspective in terms of the value of the data, but it's
not critical from the perspective of keeping the network safe from
attack.


6) Different Criticality, Different Vulnerability

(Distinguish between System-Critical data and Application-Critical
data.)

This appears to be in direct violation of the more general content
decision "Different Risk, Same Vulnerability."  But it *feels* right
to me to separate these two.  Application-Critical configuration
vulnerabilities, by definition, limit the scope and type of activities
that an attacker can perform; the "identity" of the attacker is as an
application-level user, not a user on the entire system.  This to me
is a fundamental difference.