Donate Share

MailManager

Tracker: Bugs

9 Postgres encoding security hole - ID: 1494281
Last Update: Comment added ( kevca )

Not fully investgiated, but the following is my
response to the users list regarding the latest
postgres security hole:

The problem in question is quite complex, and I haven't
had much time to


go over this in depth. It would appear that MailManager
may be vulnerable


in the case that the database encoding is set to a
multibyte encoding type.


This will depend on your distribution's configuration
of postgres, and can


be checked using the command \l+ in the psql command
line client.






For now, if this security vulnerability is a concern I
would advise that


you upgrade to the latest version of postgres, which
should resolve the


issue. Looking at the DTML layer in Zope, it appears to
use the '' string


escaping method which should be safe for all encoding
types with postgres


8.1.4.







Our SQL layer which we introduced to allow us to
convert and wrap queries


should mean that any exploit can be prevented from
within MailManager


itself, rather than having to rely on a fix in Zope's
DTML layer or in


Postgres. I will investigate this properly and issue a
fix if necessary


asap.


Kevin Campbell ( kevca ) - 2006-05-24 13:06

9

Closed

Fixed

Kevin Campbell

Security

v2.0.9

Public


Comments ( 6 )

Date: 2006-05-26 14:23
Sender: kevcaSourceForge.net SubscriberProject Admin

Logged In: YES
user_id=1241761

Fixed in both 2.0.10 and 2.1-rc4


Date: 2006-05-25 09:32
Sender: kevcaSourceForge.net SubscriberProject Admin

Logged In: YES
user_id=1241761

This may also need a binary wrapper for the MySQL database
adapter, so that we can discern between utf-8 strings and
binary data which should not be translated. If MySQL is not
affected (if it treats all data as ascii), then the fix in
the sql later should be made specific to postgres.


Date: 2006-05-24 15:00
Sender: kevcaSourceForge.net SubscriberProject Admin

Logged In: YES
user_id=1241761

There is now a premliminary fix in SVN. The web interface
still needs directly tested to ensure:

* Direct access to http://.../ticket/id still works
correctly, similar for account and attachment
* That direct access is restricted to authenticated users
with the correct permissions



Date: 2006-05-24 14:58
Sender: kevcaSourceForge.net SubscriberProject Admin

Logged In: YES
user_id=1241761

Broken second reply to this bug should read

If exploited, the vulnerability will allow access to the
admin user. Escalation to access the underlying operating
system should not be possible, and any attacker should still
be contained within the zope process.


Date: 2006-05-24 13:33
Sender: kevcaSourceForge.net SubscriberProject Admin

Logged In: YES
user_id=1241761

The following ZSQL Method which is hardcoded into
MailManager appears to be vulnerable. This may be a problem
to replace as it may be accessed directly through the web
interface, and cannot be put through the SQL wrapper.

manage_addZSQLMethod(self, id='account', title='',
connection_id='mailmanager_db',
arguments='email',
template='SELECT * '
'FROM <dtml-var
schema>mm_account '
'WHERE <dtml-sqltest
email type=nb>')



Date: 2006-05-24 13:26
Sender: kevcaSourceForge.net SubscriberProject Admin

Logged In: YES
user_id=1241761

Moving this to the 2.0.9 release. It should be the case that
2.1 is not vulnerable, given that unicode strings should be
used throughout the code internally. Python will not allow
the creation of a unicode string which will translate into
0xc8 ' as there is no unicode code point which translates
into that value in utf-8 (it is an invalid utf-8 string).

The updated SQL wrapper in 2.1 will correct the issue if
backported to 2.0. Any SQL calls which manually encode data
will still need audited. This specifically means any SQL
queries which are not from dtml code stored in the sql/v2_x
directory on disk.

If exploited, the vulnerability


Attached File

No Files Currently Attached

Changes ( 4 )

Field Old Value Date By
status_id Open 2006-05-26 14:23 kevca
resolution_id None 2006-05-26 14:23 kevca
close_date - 2006-05-26 14:23 kevca
artifact_group_id v2.1-rc3 2006-05-24 13:26 kevca