[dev] Fwd: IMP 2.x SQL injection vulnerabilities

[Ronnie Garcia]

FYI
Bugtraq, today.

Rgds,
Ronnie.

>Mailing-List: contact bugtraq-help at securityfocus.com; run by ezmlm
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq at securityfocus.com>
>List-Help: <mailto:bugtraq-help at securityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe at securityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe at securityfocus.com>
>Delivered-To: mailing list bugtraq at securityfocus.com
>Delivered-To: moderator for bugtraq at securityfocus.com
>Date: Wed, 8 Jan 2003 19:34:16 +0200 (EET)
>From: Jouko Pynnonen <jouko at solutions.fi>
>To: <bugtraq at securityfocus.com>
>Subject: IMP 2.x SQL injection vulnerabilities
>
>
>
>IMP is a popular webmail package written in PHP. It ships with some UNIX
>systems and is also used on Windows servers. The version 2 of the program
>contains some SQL injection flaws which allow any remote user to access
>the webmail system's database. Valid user authentication is not required
>in order to exploit the flaws.
>
>The error happens in some database functions in PHP files named
>lib/db.<databasename>. An example from db.pgsql, function check_prefs:
>
>   $sql="select username from $default->db_pref_table where 
> username='$user@$server'";
>
>Including user-supplied strings directly in an SQL query is a mistake.
>The fix is to use something like the addslashes() PHP function.
>
>As a proof of concept:
>
>$ lynx 
>"http://webmail.server/imp/mailbox.php3?actionID=6&server=x&imapuser=x';somesql+--&pass=x"
>
>IMP would try to execute "somesql" and the result would be this kind
>of PHP error (presuming the PHP configuration allows displaying error
>messages on web pages):
>
>    Warning:  PostgreSQL  query  failed:  ERROR:  parser: parse error at 
> or near "somesql" in
>    /usr/share/horde/imp/lib/db.pgsql on line 127
>
>Even though SQL query results aren't directly readable from the screen
>in the above example, the attacker might e.g. update his/her mail
>signature to contain wanted query results and then view it on the
>preferences page of IMP. This requires a valid login, but isn't a
>problem for an attacker because IMP allows the use of any remote IMAP
>server. Use of the server_list option doesn't affect this behaviour; the
>attacker-controlled IMAP server may be still passed to mailbox.php3 in the
>URL.
>
>The impact of SQL injection depends heavily on the underlying database
>and its configuration. If PostgreSQL is used, it's possible to execute
>multiple complete SQL queries separated by semicolons. The database
>contains session id's so the attacker might hijack sessions of people
>currently logged in and read their mail. In the worst case, if the
>hordemgr user has the required privilege to use the COPY SQL command
>(found in PostgreSQL at least), a remote user may read or write to any
>file the database user (postgres) can. The attacker may then be able to
>run arbitrary shell commands by writing them to the postgres user's
>~/.psqlrc; they'd be run when the user starts the psql command which
>under some configurations happens regularly from a cron script.
>
>If other database servers are used, the exploitation possibilities may
>be more limited.
>
>The vendor has been informed about this bug last month. Although there
>hasn't been any direct reply, there was a comment on this on the IMP
>mailing list: "2.2.x is officially deprecated/unsupported. This does not
>apply to 3.x.".
>
>Versions up to and including 2.2.8 seem vulnerable. According to the
>author, version 3 isn't affected so upgrading to IMP 3 is recommended.
>This, and more information about IMP is available at http://horde.org/imp/.
>
>
>
>   Jouko Pynnönen
>   jouko at solutions.fi

-- 
BOFH excuse # 51
Cosmic ray particles crashed through the hard disk platter