BUZ.CH Security Advisory 200109041: Inter7 vpopmail DB pw problem

2001-09-05T00:00:00
ID SECURITYVULNS:DOC:1998
Type securityvulns
Reporter Securityvulns
Modified 2001-09-05T00:00:00

Description


BUZ.CH Security Advisory 200109041: Inter7 vpopmail DB pw problem

Subject: local password problem in vpopmail when installed with MySQL module and all other programs linked against libvpopmail.a Written by: Gabriel Ambuehl <gabriel_ambuehl@buz.ch> Impact: - MySQL authentication data can get stolen which means that all the data the respective user has access to is in danger. - Probably remote command execution under the vpopmail user (untested). Affected: All vpopmail =< 4.10.35 Setups using MySQL NOT affected: vpopmail setups without DB based authentication Credits: Inter7 (earlier advisory on < vpopmail-4.10.34, see below for details)


I first want to say that Ken Jones of Inter7 was really responsive when I reported the bug and that they fixed the vulnerability fast. I also want to say that vpopmail really does a great job!

1. Introduction

Some days ago, Inter7 released a security advisory concerning passwords saved in libvpopmail.a cause they feared people could link against that lib with code that segfaults to steal the authentication data out of the core dump file and thus made the file chmod 400 so that only root has access to the compiled passwords. While this fixes this particular vulnerability, it really only fixes one particular problem with libvpopmail.a.

2. Description of the Problem

As pointed out above, the passwords to the MySQL server get compiled into libvpopmail.a which is where they belong for various reasons, which basically means that one can get them out of there rather easily (a short description for FreeBSD 4.3/gcc 2.95.2 is below). Now since all the command line utilities link against libvpopmail.a, they all contain the passwords too. This means that there's absolutely no need to write some code that will segfault as all binaries are chmod 755 which means that every user can read their contents, including the passwords.

3. Principal attack

On FreeBSD 4.3/gcc 2.95.2 and vpopmail-4.10.35/4.10 (first one is the development snapshot) the username and password is saved in the same line as the error message could not connect to mysql All you have to do now is to open the file in a text editor, search for the string and grab the passwords a few bytes earlier. You now can connect to the DB server and do whatever you like with the data you gained access to. (the following paragraph is based on assumptions, as we don't run the mysql module ourselves) In some versions, this probably involves access to forwards which means that you could be able to spawn an arbitrary executable under the uid vpopmail runs (normally vpopmail, which means that all the email data is in danger, but when the multi Unix user scheme is used root, i.e. complete control of the system).

4. Background

It's widely known that saving DB passwords anywhere on the system causes a big risk that they will be stolen but there isn't any other solution for daemons to work with databases as it is obviously impossible to run them interactively typing the password every time they are used. There ain't any real solution against this for interpreted code, but for binaries one can at least remove the r bits from the permissions to prevent users stealing the passwords out of the binaries. We suspect that there are many other programs out there that suffer of the same problem.

5. Solution

Run

chmod 711 ~vpopmail/bin/*

chmod 400 ~vpopmail/lib/*

(substitute the second argument with the directory vpopmail is located on your system, if needed). Or install the latest vpopmail release, where the binaries are installed this way from begin with. Another approach would be to run qmail/vpopmail on a dedicated server without any users despite root but we understand that this isn't an option in many environments.

6. Final comments

With the increasing dependance on DBMS (not just MySQL) for more and more tools which potentially could do a lot a of damage to the system given the DBMS data is altered in a malicious way, it of course becomes increasingly important that the DBMS is secure.


Copyright (c) 2001 BUZ.CH, permission for archival and reproduction is hereby granted, provided that this copyright modification remains intact and that any modifications are clearly marked so.


Best regards, Gabriel