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.

Treat the Entire Inherited Process Context as Unvalidated Input

Author(s): William L. Fithen Maturity Levels and Audience Indicators: L4  / D/P  SDLC Life Cycles: Implementation  Copyright: Copyright © Carnegie Mellon University 2005-2012.


Inherited process context that is not validated like other inputs can introduce vulnerability.


It is necessarily the case that when a program starts execution, it inherits an execution context that is potentially malicious. The only parts of the execution context that can be malicious are those aspects that are both dynamic and subject to influence by an adversary. That is, anything that an invoking adversary could change offers the potential of being a trap for the program. Static aspects of the execution environment are accommodated in the normal engineering approaches.

The only approach to this situation is to design a protocol to establish trust in the context. This includes

  • correcting or discarding aspects of the context

  • validating those aspects of the context that cannot be corrected

Note that the adversary can change some aspects of the execution context while the program is running. That is not covered here. Those are generally considered time and state problems.

Dynamic Assembly

Many operating systems and programming languages support assembly of executable programs immediately before or during execution. The pieces from which the ultimate executable is composed must be acquired from many places. The most common are

  • files from local filesystems

  • files from remote (network) filesystems

  • files from web, code, or application servers on the network

The specific locations for these component files are generally configured into the operating systems or runtime environments of the programming languages. In some cases, these locations are incorrectly configured or can be fooled into loading pieces from vulnerable locations—locations where adversaries can pre-position maliticous code.

Environments where this has been known to occur include the following:

  • Virtually all modern UNIX operating systems have support for shared object libraries. An adversary may be able to fool the system into loading a shared library before or instead of those the engineer of the program expects.

  • All modern versions of Microsoft Windows operating systems have support for dynamically loaded libraries. As in the case of UNIX, adversaries may be able to load their DLLs before or instead of those expected.

  • Many modular scripting languages, including

    • PERL,

    • Ruby, and

    • Python.

  • Java and .NET include dynamic assembly is an integral part of the platforms themselves. That is, while most of the execution environments described above use dynamic assembly for efficiency, Java and .NET use it functionally. Consequently, it cannot be avoided.


CitationBibliographic Entry

[CA-1995-14] CERT® Advisory CA-1995-14 Telnetd Environment Vulnerability (1997).

[Gosling 05]

Gosling, James; Joy, Bill; Steele, Guy; & Bracha, Gilad. The Java Language Specification, Third Edition. Boston, MA: Addison-Wesley Professional, 2005.

[Grubb 02]

Grubb, Steven. A Survey of Process Environments. (2002).

[McClure 99]

McClure, Stuart; Scambray, Joel; & Kurtz, George. Hacking Exposed: Network Security Secrets & Solutions, 316-317. Computing Mcgraw-Hill, 1999.

[Thompson 05]

Thompson, Herbert & Chase, Scott. The Software Vulnerability Guide, 211-222. Charles River Media, 2005.

[VU#602625] Vulnerability Note VU#602625: KTH Kerberos environment variables krb4proxy and KRBCONFDIR may be used insecurely. (2001).

[VU#943633] Vulnerability Note VU#943633: FreeBSD can be compromised locally via signal handlers. (2002).