[SM-PLUGINS] HEADS UP -- archive_mail plugin may delete messages

[Juergen N. <jue...@fu...>]

Summary:
In our installation, the archive_mail plugin has shown to cause the
unexpected deletion of e-mail messages. This may or may not apply to
other installations. I am not motivated to investigate the problem
further by myself, but am willing to help if someone else is interested.


The day before yesterday I received a report from one of our users who
had tried to use the archive plugin on the over 3000 messages in her
Inbox. She set the option to make SquirrelMail display 4000 messages at
a time, clocked on "Toggle All" to select all messages, and clicked on
"Archive". Several seconds later the message list simply appeared again,
only with all messages after March 7 2012 deleted.

Investigating the issue, I found I could reproduce it reliably with a
large number of messages in a mail folder -- when I click on "Archive",
the message list reappears after a short while -- suspiciously short,
actually -- and quite a number of messages is deleted, something like
1000 in this scenario. (I did not encounter this when I tested the
plugin with a small number of messages to archive, like 20.)

In the syslog I found this:

Jan 10 17:36:47 09:malawi suhosin[839473]: ALERT - configured POST
variable limit exceeded - dropped variable 'msg[995]' (attacker
'130.133.10.14', file '/server/webmail/www-devel/src/move_messages.php')

(There is nothing in the PHP error log that corresponds to this.)

So, apparently suhosin gets suspicious by the size of the POST request
and decides to garble it. The commands that squirrelmail sends to the
IMAP server (with the squirrelmail imapproxy in between, so we see
commands from several connections) are these:

A002 SELECT "grossss"
A003 EXPUNGE
a001 CAPABILITY
a001 GETQUOTAROOT "INBOX"
A004 EXAMINE "grossss"
A005 SELECT "grossss"
A006 EXPUNGE
A007 EXPUNGE
A008 UID SEARCH UID 1:12229
A009 UID FETCH 1:8249 (FLAGS UID RFC822.SIZE INTERNALDATE
BODY.PEEK[HEADER.FIELDS (Date To Cc From Subject X-Priority Importance
Priority Content-Type)])
A010 EXAMINE "grossss"
C64 UNSELECT
A002 STATUS "INBOX" (MESSAGES UNSEEN RECENT)
A003 EXAMINE "Trash"
a001 CAPABILITY
a001 GETQUOTAROOT "INBOX"
C64 UNSELECT
A002 SELECT "grossss"
A003 EXPUNGE
A004 LIST "" "Trash"
A005 UID COPY 7255:8249 "Trash"
A006 UID STORE 7255:8249 +FLAGS (\Deleted)
A007 EXPUNGE
C64 UNSELECT
A002 SELECT "grossss"
A003 EXPUNGE
a001 CAPABILITY
a001 GETQUOTAROOT "INBOX"
A004 EXAMINE "grossss"
A005 SELECT "grossss"
A006 EXPUNGE
A007 EXPUNGE
A008 UID SEARCH UID 1:12229
A009 UID FETCH 1:7254 (FLAGS UID RFC822.SIZE INTERNALDATE
BODY.PEEK[HEADER.FIELDS (Date To Cc From Subject X-Priority Importance
Priority Content-Type)])
A010 EXAMINE "grossss"
C64 UNSELECT

So actually the messages were not really deleted, rather moved to the
Trash (the second A005/A006/A007 group of commands), which makes the
problem only slightly less catastrophic.

I cannot find any code that deletes messages or moves them in the
archive_mail plugin, so I guess the garbled POST request triggers
something else somewhere inside of squirrelmail. I would not totally be
surprised if huge requests of other kinds might also trigger unexpected
behaviour of a similar kind. (This reminds me a bit of the proverbial
nasal demons.)

Perhaps it would be possible to tune suhosin to let requests of this
size pass, but I don't known when it hits a dangerous size again, so I
do not see that as a feasible workaround.


Anyway, as this is apparently not easy to fix, I have decided not to
pursue the issue further; we will simply no longer use this plugin. In
case someone else is more motivated, this is our installation:

Base system is Debian-stable on x86_64; PHP 5.3.3-7+squeeze14 and Apache
2.2.16-6+squeeze10 are installed as Debian packages. PHP gets some
additional configuration; apart from file paths it is this:

-------------------------------------------
upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
suhosin.cookie.max_name_length=128

[Session]
session.gc_maxlifetime = 57600
session.save_path = /home/webmail/var/lib/php5
-------------------------------------------

SquirrelMail is a 1.4.22 with some own patches to adapt it to our local
situation (display, authentication, that stuff). I *think* they are
irrelevant to this issue, but as I have taken over the patches from my
predecessor on the job and have not reviewed them in detail -- my
fluency in PHP is limited --, I wouldn't swear on that. I can provide
the code (or patches) if anyone is interested.

(Side note: most of the above probably could have been done in a plugin
as I know in between. I will probably even do that if I ever do a
replacement of this SquirrelMail installation.)

Installed plugins:

message_details     no version number found; $Id tag:
      message_details_main.php 14084 2011-01-06 02:44:03Z pdontthink
delete_move_next    3.0
quota_usage         1.3.1
add_address         1.0.3
limit_languages     1.0
abook_import_export 1.1
archive_mail        1.2

The specific IMAP server *should* be irrelevant to this issue, but there
is the current SquirrelMail imapproxy in front of some version of
Perdition in front of dovecot 1.1.20 (all on Debian-stable).

Browsers used were Firefox 18.0 (by the reporting user) and Chrome
23.0.1271.97 (by myself), both on Linux (Debian-stable in my case).

If anything else is of interest, feel free to ask.

Regards, Juergen.

-- 
<Jue...@fu...> Tel. +49.30.838-50740
Zentraleinrichtung fuer Datenverarbeitung, Central Systems (Unix)
Freie Universitaet Berlin, Fabeckstrasse 32, 14195 Berlin, DE