Why is thttpd Secure?

Commentary and Possible Holes

The security of this program depends, to some extent, on the proper operation of all of the system and compiler functions it calls. We doubt if these programs have been subjected to a similar analysis to assure that they retain confinement properties, and this introduces potential problems.

Confinement Properties

Notwithstanding these limitations, the secure daemon described here has been shown to enforce the confinement properties required for secure operation against intentional abuse as well as many of the other properties that are appropriate to secure daemon operation.


From a standpoint of integrity, we believe that this daemon is very safe and that it effectively protects the server it operates on from corruption during its operation.


From a standpoint of denial of services, an attacker can use large numbers of requests to cause some requests to fail by overrunning the available number of files and processes on the server, however the sequential nature of file access in this daemon and the fact that a very small number of files are opened for only the minimum necessary time reduces this vulnerability compared to insecure implementations.


From a standpoint of confidentiality, we believe that these programs are at least as strong as the environment they operate in and that they do not lessen security whatsoever. Furthermore, the redundant protection provided by defense-in-depth assures that even under circumstances where leakage would be expected with other daemons, this daemon provides effective protection. Only information explicitly made available to outside access is released by this daemons.

Interrupts and Exceptions

The program has no interrupts and no exception conditions that are not properly handled in its current operation. Even in cases where the underlying environment changes during operation, the code operates without causing any substantial security problems.