MySQL Buffer Overflow; Secure PHP Coding

02/20/2001

Welcome to Security Alerts, an overview of recent Unix and open-source security advisories. In this column, we look at buffer-overflows in MySQL, analog, vixie cron, and Kerberos IV; problems with kicq, licq, and kaim; root exploits in NetBSD i386 kernels; and a discussion of insecure coding with PHP and MySQL using a vulnerability in PHP-Nuke as an example.

MySQL has a buffer overflow in the libmysqlclient library that can be exploited using the command-line client, and a buffer overflow in the DROP SQL command. It is not clear if exploiting either of the buffer overflows can be used to gain additional privileges.

The analog web server log-file analysis package has a buffer overflow in all versions released prior to Feb. 13, 2001. A malicious user can use the ALIAS command to create a long string that will overflow a buffer in analog. If the form interface is installed remote users can exploit this buffer overflow.

The author of analog recommends that users upgrade to version 4.16 or 4.90beta3 as soon as possible.

A free implementation of the SSH-1 protocol, FreeSSH, may use an unsafe method for generating its seed value. Using an unsafe seed can lead to a compromise of the encrypted communications. This only affects systems that do not provide a random device, (for example /dev/urandom or /dev/random).

The author of FreeSSH has updated it so it will run only if it can open the random device. It is recommended that users upgrade to FreeSSH version 0.3.1 or 0.8.1 and not use FreeSSH on systems that lack a random device.

vixie cron has a buffer overflow that can potentially be exploited to gain root privileges. vixie cron uses a 20-byte buffer to hold the user name. Any user name larger than 20-bytes will cause a buffer overflow in vixie cron. An attacker can use this vulnerability to execute arbitrary code with the permission of the root user.

If your system uses names larger than 20-bytes you should remove the suid bit from vixie cron and watch your vendor for an updated version.

The chat clients kicq, licq, and kaim open URLs passed to the user without checking for meta-characters. An attacker can send a user a carefully crafted URL that will cause the chat client to execute arbitrary commands. These commands will run with the permissions of the user running the chat client. kicq and kaim show the user only the link name. licq will show the user the entire URL including the embedded commands.

Users of kicq, licq, and kaim should not open URLs from untrusted sources until an updated version of their chat client has been released.

Three vulnerabilities have been announced in the FreeBSD Kerberos IV package. The vulnerabilities are: a temporary-file race condition in the ticket handling code, improper handling of two environmental variables, and a buffer overflow in the libkrb authentication library. These vulnerabilities are all exploited through the telnetd daemon. All three of these vulnerabilities can be exploited to gain root access.

Users should disable telnet until they have upgraded to a patched version of FreeBSD 4.2-STABLE or 3.5-STABLE.

PHP-Nuke is a weblog system similar to Slash or PHPWeblog written using PHP, MySQL, and Apache. Two advisories about PHP-Nuke vulnerabilities were released this week. The first advisory reports that a user can view arbitrary files on the server by defining an uninitialized variable as part of a URL and the second reports on additional problems with unchecked and uninitialized variables that may allow an attacker to execute arbitrary SQL commands.

It is recommended that all sites using PHP-Nuke update to the latest version. It is also recommended that users of the PHP-Nuke package watch the PHP-Nuke web site for future bug-fixes.

Because PHP will create a global variable from data passed to PHP as part of the URL, an attacker can set any variable name he desires to any value. If you use this variable in your script without checking its value or initializing it you leave your script vulnerable to an attack.

An example of this from code I have written was a page number variable. The variable was passed to PHP as part of the URL and the code never checked to ensure that it was a number.

A friendly user (lucky for me) pointed out that he could replace the page number with arbitrary SQL commands. The code was changed to ensure that the page number variable was a number.

The URL calling your script can set the value of any variable. If you do not check or set the value of every variable before using it you can create a vulnerability.

If an unchecked variable is passed to MySQL_query() an attacker may be able to execute arbitrary SQL commands. This can include dropping tables, inserting or deleting rows, or if you are using a read-only user ID for the query the damage may be limited to reading protected data such as passwords.

A variable passed to a system() call that has not been checked can allow an attacker to execute arbitrary commands on the server with the permissions of the user that is executing the PHP code.

Apache, MySQL, and PHP provide a powerful and easy-to-use environment for developing web applications. To prevent problems we should audit our code to ensure that we are checking or initializing all variables before we use them.

Noel Davis is a Unix system
administrator. He has been using Linux for more than six years and
working as a system administrator for more than five years.