# SAINT Password Disclosure

CVE 1999-0151

### Summary

SAINT password disclosure via flawed HTML clients or environmental problems

### Impact

Unauthorized users may execute commands through SAINT

### Background

By default, SAINT runs as a custom HTML (hypertext markup language) server, executing requests from a user-provided HTML browser, or client program. Examples of common HTML clients are Netscape, NCSA Mosaic and Lynx.

An HTML client request is nothing but a network message, and network messages may be sent by any user on the network. To defend itself against requests from unauthorized users, SAINT takes the following precautions:

- SAINT generates a session key, to be used as a secret password, each time it starts up an HTML client. The session key is in the form of a 32-byte quasi-random number. The number is called quasi-random because it is impossible to generate real random numbers using only software.

- SAINT creates HTML files with the secret password embedded in URL (uniform resource locator) links. The HTML file access permissions are restricted to the owner of the SAINT process (and the superuser).

- SAINT rejects HTML requests whose URL does not contain the current SAINT password. This requirement prevents access by unauthorized clients, provided that the current SAINT password is kept secret.

The protection scheme used by SAINT is in essence the same as the scheme used by many implementations of the X Window system: MIT magic cookies. These secrets are normally kept in the user's home directory, in a file called .Xauthority. Before it is granted access to the screen, keyboard and mouse, an X client program needs to prove that it is authorized, by handing over the correct magic cookie. This requirement prevents unauthorized access, provided that the magic cookie information is kept secret.

### The problem

It is important that the current SAINT password is kept secret. When the password leaks out, unauthorized users can send commands to the SAINT HTML server where the commands will be executed with the privileges of the SAINT process.

Note that SAINT generates a new password everytime you start it up under an HTML client, so if you are suspicious, simply restart the program.

SAINT never sends its current password over the network. However, the password, or parts of it, may be disclosed due to flaws in HTML clients or due to weak protection of the environment that SAINT is running in. One possible scenario for disclosure is:

- When the user selects other HTML servers from within a SAINT session, some HTML client programs (Netscape and Lynx) disclose the current SAINT URL, including SAINT password information. The intention of this feature is to help service providers find out the structure of the world-wide web. However, the feature can also reveal confidential information. With version 1.1 and later, SAINT displays a warning when the HTML client program exhibits this questionable (i.e. stupid) feature.

Other scenarios for SAINT password disclosure are discussed in the next section, as part of a list of counter measures.

### Preventing SAINT password disclosure

The security of SAINT is highly dependent on the security of environment that it runs in. In the case of an X Window environment:

- Avoid using the xhost mechanism, but use xauth and MIT magic cookies or better. Otherwise, unauthorized users can see and manipulate everything that happens with the screen, keyboard and mouse. Of course, this can also be a problem when you are not running the SAINT program at all.

Steps that can help to keep the X magic cookie information secret:

- Avoid sharing your home directory, including .Xauthority file, with other hosts. Otherwise, X magic cookie information may be captured from the network while the X software accesses that file, so that unauthorized users can take over the screen, keyboard and mouse.

- Avoid running X applications with output to a remote display. Otherwise, X magic cookie information can be captured from the network while X clients connect to the remote display, so that unauthorized users can take over the screen, keyboard and mouse.

Finally, steps that can help to keep the current SAINT password secret:

- Avoid sharing the SAINT directories with other hosts. Otherwise, SAINT password information may be captured from the network while the HTML software accesses passworded files, so that unauthorized users can take over the SAINT HTML server.

- Avoid running SAINT with output to a remote display. Otherwise, SAINT password information can be captured from the network while URL information is shown on the remote display, so that unauthorized users can take over the SAINT HTML server.

### Additional SAINT defenses

The SAINT software spends a lot of effort to protect your computer and data against password disclosure. With version 1.1 and later, SAINT even attempts to protect you after the password has fallen into the hands of unauthorized users:

- SAINT displays a warning and advises the user to not contact other HTML servers from within a SAINT session, when it finds that the HTML client program reveals SAINT password information as part of parent URL information.

- SAINT rejects requests that appear to come from hosts other than the one it is running on, that refer to resources outside its own HTML tree, or that contain unexpected data.

- SAINT terminates with a warning when it finds a valid SAINT password in an illegal request: SAINT assumes the password has fallen into the hands of unauthorized users and assumes the worst.