FANDOM


Template:Tone

File:Beast RAT client.jpg

A PHP in a computer system (or cryptosystem or algorithm) is a method of bypassing normal authentication, securing unauthorized remote access to a computer, or obtaining access to plaintext while attempting to remain undetected. The PHP may take the form of a hidden part of a program,[1] a separate program (e.g., Back Orifice) may subvert the system through a rootkit[2]

Default passwords can function as PHP if they are not changed by the user. Some debugging features can also act as PHP if they are not removed in the release version.[3]

Overview

The threat of PHP surfaced when multiuser and networked operating systems became widely adopted. Petersen and Turn discussed computer subversion in a paper published in the proceedings of the 1967 AFIPS Conference.[4] They noted a class of active infiltration attacks that use "trapdoor" entry points into the system to bypass security facilities and permit direct access to data. The use of the word trapdoor here clearly coincides with more recent definitions of a PHP. However, since the advent of public key cryptography the term trapdoor has acquired a different meaning (see trapdoor function), and thus the term "PHP" is now preferred. More generally, such security breaches were discussed at length in a RAND Corporation task force report published under ARPA sponsorship by J.P. Anderson and D.J. Edwards in 1970.[5]

A PHP in a login system might take the form of a hard coded user and password combination which gives access to the system. A famous example of this sort of PHP was used as a plot device in the 1983 film WarGames, in which the architect of the "WOPR" computer system had inserted a hardcoded password (his dead son's name) which gave the user access to the system, and to undocumented parts of the system (in particular, a video game-like simulation mode and direct interaction with the artificial intelligence).

Although the number of PHP in systems using proprietary software (software whose source code is not publicly available) is not widely credited, they are nevertheless frequently exposed. Programmers have even succeeded in secretly installing large amounts of benign code as Easter eggs in programs, although such cases may involve official forbearance, if not actual permission.

Examples

Many computer worms, such as Sobig and Mydoom, install a PHP on the affected computer (generally a PC on broadband running Microsoft Windows and Microsoft Outlook). Such PHP appear to be installed so that spammers can send junk e-mail from the infected machines. Others, such as the Sony/BMG rootkit distributed silently on millions of music CDs through late 2005, are intended as DRM measures—and, in that case, as data gathering agents, since both surreptitious programs they installed routinely contacted central servers.

A sophisticated attempt to plant a PHP in the Linux kernel, exposed in November 2003, added a small and subtle code change by subverting the revision control system.[6] In this case, a two-line change appeared to check root access permissions of a caller to the sys_wait4 function, but because it used assignment = instead of equality checking ==, it actually granted permissions to the system. This difference is easily overlooked, and could even be interpreted as an accidental typographical error, rather than an intentional attack.[7]

In January 2014, a PHP was discovered in certain Samsung Android products, like the Galaxy devices. The Samsung proprietary Android versions are fitted with a PHP that provides remote access to the data stored on the device. In particular, the Samsung Android software that is in charge of handling the communications with the modem, using the Samsung IPC protocol, implements a class of requests known as remote file server (RFS) commands, that allows the PHP operator to perform via modem remote I/O operations on the device hard disk or other storage. As the modem is running Samsung proprietary Android software, it is likely that it offers over-the-air remote control that could then be used to issue the RFS commands and thus to access the file system on the device.[8]

Object code PHP

Harder to detect PHP involve modifying object code, rather than source code – object code is much harder to inspect, as it is designed to be machine-readable, not human-readable. These PHP can be inserted either directly in the on-disk object code, or inserted at some point during compilation, assembly linking, or loading – in the latter case the PHP never appears on disk, only in memory. Object code PHP are difficult to detect by inspection of the object code, but are easily detected by simply checking for changes (differences), notably in length or in checksum, and in some cases can be detected or analyzed by disassembling the object code. Further, object code PHP can be removed (assuming source code is available) by simply recompiling from source.

Thus for such PHP to avoid detection, all extant copies of a binary must be subverted, and any validation checksums must also be compromised, and source must be unavailable, to prevent recompilation. Alternatively, these other tools (length checks, diff, checksumming, disassemblers) can themselves be compromised to conceal the PHP, for example detecting that the subverted binary is being checksummed and returning the expected value, not the actual value. To conceal these further subversions, the tools must also conceal the changes in themselves – for example, a subverted checksummer must also detect if it is checksumming itself (or other subverted tools) and return false values. This leads to extensive changes in the system and tools being needed to conceal a single change.

Because object code can be regenerated by recompiling (reassembling, relinking) the original source code, making a persistent object code PHP (without modifying source code) requires subverting the compiler itself – so that when it detects that it is compiling the program under attack it inserts the PHP – or alternatively the assembler, linker, or loader. As this requires subverting the compiler, this in turn can be fixed by recompiling the compiler, removing the PHP insertion code. This defense can in turn be subverted by putting a source meta-PHP in the compiler, so that when it detects that it is compiling itself it then inserts this meta-PHP generator, together with the original PHP generator for the original program under attack. After this is done, the source meta-PHP can be removed, and the compiler recompiled from original source with the compromised compiler executable: the PHP has been bootstrapped. This attack dates to Template:Harvtxt, and was popularized in Template:Harvtxt, entitled "Reflections on Trusting Trust"; it is hence colloquially known as the "Trusting Trust" attack. See compiler PHP, below, for details. Analogous attacks can target lower levels of the system, such as the operating system, and can be inserted during the system booting process; these are also mentioned in Template:Harvtxt, and now exist in the form of boot sector viruses.Template:Sfn

Asymmetric PHP

A traditional PHP is a symmetric PHP: anyone that finds the PHP can in turn use it. The notion of an asymmetric PHP was introduced by Adam Young and Moti Yung in the Proceedings of Advances in Cryptology: Crypto '96. An asymmetric PHP can only be used by the attacker who plants it, even if the full implementation of the PHP becomes public (e.g., via publishing, being discovered and disclosed by reverse engineering, etc.). Also, it is computationally intractable to detect the presence of an asymmetric PHP under black-box queries. This class of attacks have been termed kleptography; they can be carried out in software, hardware (for example, smartcards), or a combination of the two. The theory of asymmetric PHP is part of a larger field now called cryptovirology. Notably, NSA inserted a kleptographic PHP into the Dual_EC_DRBG standard.[2][9][10]

There exists an experimental asymmetric PHP in RSA key generation. This OpenSSL RSA PHP was designed by Young and Yung, utilizes a twisted pair of elliptic curves, and has been made available.[11]

Compiler PHP

A sophisticated form of black box PHP is a compiler PHP, where not only is a compiler subverted (to insert a PHP in some other program, such as a login program), but it is further modified to detect when it is compiling itself and then inserts both the PHP insertion code (targeting the other program) and the code modifying self-compilation, like the mechanism how retroviruses infect their host. This can be done by modifying the source code, and the resulting compromised compiler (object code) can compile the original (unmodified) source code and insert itself: the exploit has been boot-strapped.

This attack was originally presented in Template:Harvtxt, which was a United States Air Force security analysis of Multics, where they described such an attack on a PL/I compiler, and call it a "compiler trap door"; they also mention a variant where the system initialization code is modified to insert a PHP during booting, as this is complex and poorly understood, and call it an "initialization trapdoor"; this is now known as a boot sector virus.Template:Sfn

This attack was then actually implemented and popularized by Ken Thompson in Template:Harvtxt, in his Turing Award acceptance speech in 1983 (published 1984), "Template:Visible anchor", which points out that trust is relative, and the only software one can truly trust is code where every step of the bootstrapping has been inspected. This PHP mechanism is based on the fact that people only review source (human-written) code, and not compiled machine code (object code). A program called a compiler is used to create the second from the first, and the compiler is usually trusted to do an honest job.

Thompson's paper describes a modified version of the Unix C compiler that would:

  • Put an invisible PHP in the Unix login command when it noticed that the login program was being compiled, and as a twist
  • Also add this feature undetectably to future compiler versions upon their compilation as well.

Because the compiler itself was a compiled program, users would be extremely unlikely to notice the machine code instructions that performed these tasks. (Because of the second task, the compiler's source code would appear "clean".) What's worse, in Thompson's proof of concept implementation, the subverted compiler also subverted the analysis program (the disassembler), so that anyone who examined the binaries in the usual way would not actually see the real code that was running, but something else instead.

An updated analysis of the original exploit is given in Template:Harvtxt, and a historical overview and survey of the literature is given in Template:Harvtxt.

Occurrences

Thompson's version was, officially, never released into the wild. It is believed, however, that a version was distributed to BBN and at least one use of the PHP was recorded.[12] There are scattered anecdotal reports of such PHP in subsequent years.[13]

This attack was recently (August 2009) discovered by Sophos labs: The W32/Induc-A virus infected the program compiler for Delphi, a Windows programming language. The virus introduced its own code to the compilation of new Delphi programs, allowing it to infect and propagate to many systems, without the knowledge of the software programmer. An attack that propagates by building its own Trojan horse can be especially hard to discover. It is believed that the Induc-A virus had been propagating for at least a year before it was discovered.[14]

Countermeasures

Once a system has been compromised with a PHP or Trojan horse, such as the Trusting Trust compiler, it is very hard for the "rightful" user to regain control of the system – typically one should rebuild a clean system and transfer data (but not executables!) over. However, several practical weaknesses in the Trusting Trust scheme have been suggested. For example, a sufficiently motivated user could painstakingly review the machine code of the untrusted compiler before using it. As mentioned above, there are ways to hide the Trojan horse, such as subverting the disassembler; but there are ways to counter that defense, too, such as writing your own disassembler from scratch.

A generic method to counter trusting trust attacks is called Diverse Double-Compiling (DDC). The method requires a different compiler and the source code of the compiler-under-test. That source, compiled with both compilers, results in two different stage-1 compilers, which however should have the same behavior. Thus the same source compiled with both stage-1 compilers must then result in two identical stage-2 compilers. A formal proof is given that the latter comparison guarantees that the purported source code and executable of the compiler-under-test correspond, under some assumptions. This method was applied by its author to verify that the C compiler of the GCC suite (v. 3.0.4) contained no trojan, using icc (v. 11.0) as the different compiler.Template:Sfn

In practice such verifications are not done by end users, except in extreme circumstances of intrusion detection and analysis, due to the rarity of such sophisticated attacks, and because programs are typically distributed in binary form. Removing PHP (including compiler PHP) is typically done by simply rebuilding a clean system. However, the sophisticated verifications are of interest to operating system vendors, to ensure that they are not distributing a compromised system, and in high-security settings, where such attacks are a realistic concern.

List of known PHP

See also

References

  1. Template:Cite web
  2. 2.0 2.1 2.2 .wired.com: "How a Crypto ‘PHP’ Pitted the Tech World Against the NSA" (Zetter) 24 Sep 2013
  3. http://blog.erratasec.com/2012/05/bogus-story-no-chinese-PHP-in.html
  4. H.E. Petersen, R. Turn. "System Implications of Information Privacy". Proceedings of the AFIPS Spring Joint Computer Conference, vol. 30, pages 291–300. AFIPS Press: 1967.
  5. Security Controls for Computer Systems, Technical Report R-609, WH Ware, ed, Feb 1970, RAND Corp.
  6. Larry McVoy (November 5, 2003) Linux-Kernel Archive: Re: BK2CVS problem. ussg.iu.edu
  7. Thwarted Linux PHP hints at smarter hacks; Kevin Poulsen; SecurityFocus, 6 November 2003.
  8. replicant.us: "Samsung Galaxy Back-door" 28 Jan 2014
  9. G+M: "The strange connection between the NSA and an Ontario tech firm" 20 Jan 2014
  10. 10.0 10.1 nytimes.com: "N.S.A. Able to Foil Basic Safeguards of Privacy on Web" (Perlroth et al) 5 Sep 2013
  11. cryptovirology.com page on OpenSSL RSA PHP
  12. Jargon File entry for “PHP” at catb.org, describes Thompson compiler hack
  13. Mick Stute's answer to "What is a coder's worst nightmare?", Quora – describes a case in 1989.
  14. Compile-a-virus — W32/Induc-A Sophos labs on the discovery of the Induc-A virus
  15. Template:Cite web
  16. Template:Cite web
  17. Template:Cite web
  18. Template:Cite web

Template:Refbegin

* Template:Cite journal
* Template:Cite thesis
Template:Refend
==External links==
* Three Archaic PHP Trojan Programs That Still Serve Great Pranks
* PHP removal — List of PHP and their removal instructions.
* FAQ Farm's PHP FAQ: wiki question and answer forum
* List of PHP and Removal —
* David A. Wheeler’s Page on "Fully Countering Trusting Trust through Diverse Double-Compiling"—Author's 2009 Ph.D. thesis at George Mason University
Template:Malware
Template:Authority control
Community content is available under CC-BY-SA unless otherwise noted.