which the password is passed "on the wire" in a plaintext or easily decrypted format. In a default configuration (that
Sybase warns against, but which we have still seen in use) Sybase passes passwords in plaintext. By default,
Microsoft SQL Server obfuscates passwords by swapping the nibbles (4-bit halves of a byte) and XORing with
0xA5. In both of these cases, the vendors warn against using the plaintext versions of their authentication protocols
and provide strong, encrypted mechanisms that are relatively easy to deploy—but the defaults are still there, and
still dangerous.
MySQL has historically had a number of serious problems with its authentication protocol. Although the protocol
isn't plaintext, the mathematical basis of the authentication algorithm prior to version 4.1 was called into question by
Ariel Waissbein, Emiliano Kargieman, Carlos Sarraute, Gerardo Richarte, and Agustin Azubel of CORE SDI (CVE-
2000-0981). Their paper describes an attack in which an attacker that can observe multiple authentications is
quickly able to determine the password hash.
A further conceptual problem with the authentication protocol in MySQL prior to version 4.1 is that the protocol only
tests knowledge of the password hash, not the password itself. This leads to serious problems if a user is able to
somehow determine another user's password hash—and MySQL has been subject to a number of issues in which
that was possible.
Robert van der Meulen found an issue (CVE-2000-0148) in MySQL versions prior to 3.23.11 whereby an attacker
could authenticate using only a single byte of the expected response to the server's challenge, leading to a situation
whereby if you knew a user's username, you could authenticate as that user in around 32 attempts.
Chris Anley recently found a very similar problem in MySQL (CAN-2004-0627) whereby a user could authenticate
using an empty response to the server's challenge, provided he or she passed certain flags to the remote server.
This category of bugs is almost as dangerous as the "unauthenticated flaws in network protocols" category,
because in many cases the traffic simply looks like a normal authentication. Attackers don't need to exploit an
overflow or do anything clever, they simply authenticate without necessarily needing the password—or if they've
been able to sniff the password, they just authenticate.
The best defense against this kind of bug is to ensure that your database patches are up-to-date, and that you don't
have any plaintext authentication mechanisms exposed on your databases. If your DBMS cannot support encrypted
authentication in your environment, you could use IPSec or SSH to provide an encrypted tunnel. MySQL provides
explicit guidelines on how to do this in its documentation, though recent versions of MySQL allow authentication to
take place over an SSL-encrypted channel.
Unauthenticated Access to Functionality
Some components associated with databases permit unauthenticated access to functionality that should really be
authenticated. As an example of this, David Litchfield found a problem with the Oracle 8 and 9i TNS Listener,
whereby a remote, unauthenticated user could load and execute an arbitrary function via the "extproc" mechanism
(CVE-2002-0567). The function can have any prototype, so the obvious mode of attack is to load the libc or msvcrt
library (depending upon the target platform) and execute the "system" function that allows an attacker to execute an
arbitrary command line. The command will be executed with the privileges of the user that the database is running
as—"oracle" on UNIX systems, or the local system user on Windows.
Recently, David Litchfield disclosed an issue that allows any local user to execute commands in the security context
of the user that Oracle is running as (CAN-2004-1365). This bug works in exactly the same way as the bug listed
earlier (CVE-2002-0567), except that it takes advantage of the implicit trust that extproc places in the local host.
Oracle does not consider this to be a security issue (!) but we would caution you not to allow users to have shells
on Oracle servers without seriously considering the security ramifications. Clearly, allowing a user to have a shell
on a database server is dangerous anyway, but in this particular case there is a known, documented vector for
attack that the vendor will not fix.