GLEXEC-2009-0001


Summary:

 

Any user that can run the glexec executable, can insert arbitrary lines into the glexec log file.


Component Vulnerable Versions Platform Availability Fix Available
glexec all all not known to be publicly available no
Status Access Required Host Type Required Effort Required Impact/Consequences
Verified local user glexec low low / medium
Fixed Date Credit
n/a Jim Kupsch

Access Required:

local user

This vulnerability requires local access to the machine with the ability to execute glexec.

Effort Required:

low

To exploit this vulnerability requires the ability to write a simple C program.

Impact/Consequences:

low / medium

The impact of this vulnerability depends upon the use of the log file produced by glexec. The impact is a low level nuisance if the log file is used solely for debugging purposes. On the other hand, if the log file is used for audit or billing purposes the impact can be of a high consequence.

If glexec is configured to use syslog instead of directly writing to a log file, and the syslog on the machine prevents new-lines in the log record from being written to the log file, then this vulnerability does not exist.

Full Details:

 

Log records in glexec are written using the function glexec_log. This function has an interface similar to printf. The function does not verify that the resulting string does not contain a new-line character, it leaves this important task up to the caller.

None of the format strings include a new-line character, and most of the user supplied values are checked to make sure they do not contain a new-line character by the function glexec_sane_environment, but not all.

The value of argv[0] by convention contains the name (or path) of the executable. Glexec uses it to get the name of the executable which is then used as a prefix in all the log records. This value is not checked to see if it contains a new-line character. It is also logged before the user white list of authorized users is checked meaning that anyone that can run glexec can write this log record.

The the argv[0] convention is enforced by shells, and the system and popen functions. The exec family of function calls can be used to set the value to an arbitrary value. For instance the following snippet of code will start glexec with argv[0] consisting of 3 lines:

    execl("/sbin/glexec", "line 1\nline 2\n line 3", NULL);
  

An attacker can insert a valid log line ending for "line 1", a complete log record for "line 2", and a log prefix for "line 3" to evade detection, by making it appear that all log lines are formatted correctly.

There are other values passed as parameters to the glexec_log function that are not checked in glexec_sane_environment that are controlled by the user and can contain new-lines. These values are logged after the check for the authorized users of glexec, so these problems would require an authorized user of glexec. The vulnerability still exists, but these users should be of a more trusted nature, making them slightly less risky than the argv[0] vector.

Cause:

improper data validation

This vulnerability is caused by failure to verify the validity of all the data used to create log records. This includes values used internally in glexec_log to create the log line prefix, and the data passed to the function itself.

Proposed Fix:

 

Once the entire log line is created, the entire line should be scanned for new-line characters. If found these characters should be replaced by valid character (or sequence of characters). This would catch all current and future problems that arise by user supplied data injecting a new-line character in the values used to create the prefix and by the values passed to glexec_log.

Also the value of argv[0] should not be used to create the prefix since it is user controllable. It would be better to use a compiled-in constant or a value taken from the configuration file.

Acknowledgment:

 

This research funded in part by National Science Foundation grant OCI-0844219, NATO grant CLG 983049, and National Science Foundation grants CNS-0627501 and CNS-0716460.