[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CONTENT DECISION: Data Access Configuration Problems
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.