Note: This page is part of the archive.

This document is part of the US-CERT website archive. These documents are no longer updated and may contain outdated information. Links may also no longer function. Please contact if you have any questions about the US-CERT website archive.

Use Authorization Mechanisms Correctly

Author(s): William L. Fithen SDLC Life Cycles: Implementation  Copyright: Copyright © Carnegie Mellon University 2005-2012.


Incorrect use of, or failing to use, authorization mechanisms can introduce vulnerability.


The following are frequent authorization design defects that lead to vulnerability:

  • Trying to interpret access control rules for lower level subsystems instead of using the subsystems to interpret their rules. This is a common error in setuid programs on UNIX.

  • Designing authorization systems with an insufficiently rich privilege menu that encourages privilege overloading. The exemplar for this is the UNIX superuser [POSIX.1e, VU#706838].

  • Unauthenticated authorization systems that appear to control access, but without proper authentication don't control anything [VU#258834].

  • Ambiguity of authentication. Many authorization systems use ambiguous symbols (i.e., principal names) to identify principals allowing circumvention of authorization by using a different, though equivalent, principal name. For example, there are many implementations for restricting remote host access to local services that may allow many proper—but apparently different—names for unique hosts (e.g., fully qualified domain names, shortened names, CNAMEs, IPv4 addresses, IPv6 addresses).

Applicable Context

Missing, incomplete, or incorrect application of an authorization mechanism.

Impacts Being Mitigated

  • Impact #1:

    • Minimally: The least impact of this class of vulnerability is allowing/granting access to a computing resource to a--presumably authentic--individual.

    • Maximally: The greatest impact of this class of vulnerability depends on the nature of the resource to which access has been incorrectly granted. In the worse case, the result would be a complete loss of system integrity.

Security Policies to be Preserved

  • Policy #1

    • Access to each computing resource should be granted to only those that have a legitimate requirement for it.


CitationBibliographic Entry

Draft Standard for Information Technology--Portable Operating System Interface (POSIX)--Part 1: System Application Program Interface (API)--Amendment #: Protection, Audit, and Control Interfaces [C Language]. IEEE/CS JTC1 22.42. (1997).

[VU#258834]Gennari, Jeff. Vulnerability Note VU#258834: WebEOC privileges are based on client-side authorization. (2005).
[VU#706838]Dormann, Will. Vulnerability Note VU#706838: Apple Mac OS X vulnerable to buffer overflow via vpnd daemon. (2005).
[Wright 02]

Wright, Chris; Cowan, Crispin; Morris, James; Smalley, Stephen; & Kroah-Hartman, Greg. Linux Security Module Framework. (2002).