Re: squirrelmail CVE-2020-14933

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Fri, October 15, 2021 10:36, James B. Byrne via squirrelmail-users wrote:
> n Thu, October 14, 2021 18:09, Paul Lesniewski wrote:
>> On Thu, October 14, 2021 7:28 pm, James B. Byrne via squirrelmail-users
>> wrote:
>>> See:
>>> Has this been patched?
>> There is no vulnerability here.  Per OWASP:
>> =====
>> In order to successfully exploit a PHP Object Injection vulnerability two
>> conditions must be met:
>>   The application must have a class which implements a PHP magic method
>> (such as __wakeup or __destruct) that can be used to carry out malicious
>> attacks, or to start a â??POP chainâ??.
>>   All of the classes used during the attack must be declared when the
>> vulnerable unserialize() is being called, otherwise object autoloading
>> must be supported for such classes.
>> =====
>> SquirrelMail doesn't qualify for that scenario.  Whoever accepted/assigned
>> this CVE seems to have only taken the word of the reporter, who has no
>> proof that I know of that there is any security issue.  If anyone knows
>> differently, please get in touch.

This is the CVE origin (

Date: Sat, 20 Jun 2020 10:47:01 +0200
From: Hanno Böck <hanno@xxxxxxxxx>
To: oss-security <oss-security@xxxxxxxxxxxxxxxxxx>
Subject: Squirrelmail: Use of unserialize() on user data


The PHP-based webmail tool Squirrelmail uses unserialize() for
untrusted data.

unserialize() is generally not considered safe for this, PHP does not
treat memory safety issues in unserialize as security bugs since a
while and there are other attacks.

In compose.php [1] you can see that squirrelmail uses unserialize on
$mailtodata, which directly comes from a GET variable.

This data usually comes from the mailto.php script which opens a mail
compose interface with a passed mail address.

I've written a patch to convert this to json_encode/json_decode [2].

Unfortunately this is not the only place using unserialize on untrusted
data, later in the same file you can see that $attachments is also
parsed with unserialize, which comes from POST data, thus also
user-controlled. Trying to patch this with a similar strategy broke the
attachment functionality. If someone else wants to give it a try happy
to accept patches. (I'm collecting squirrelmail patches that avoid
warnings, add compatibility to latest PHP versions and fix security
issues here [3]. For reasons unclear to me the squirrelmail developers
only irregularly answer when I send patches and seem to ignore some of
these issues. While they haven't made a release in a long time, they
still sometimes fix security issues in their svn repo.)

It is unclear to me how big of a risk these issues are. There are some
attack strategies on unserialize that involve constructors of objects
[4], but the squirrelmail code doesn't have many objects, so it is
unclear if this is a feasible attack strategy.

I had reported the unserialize security issue to Squirrelmail on May
23rd. Unfortunately I haven't received a reply.

Hanno Böck

>> I'll put something on our /security page to reflect the situation.
>> Cheers,
> My problem is that I am in the midst of a PCI audit; and we use SquirrelMail;
> and this CVE is an issue with them.  I doubt that either I or anyone else can
> convince the auditors to ignore what is on the NIST website identified as a
> Critical error respecting SM.  That said, I will show them your response.  One
> never knows what can happen when dealing with people having much authority and
> little knowledge.
> I checked some Linux distros and the seem to have issued some sort of patch to
> deal with this.  I have seen a request made to the FreeBSD bug tracker to deal
> with this as well.
> I need something done to address this CVE, either by having it removed from
> NIST as invalid or through some sort of patch, meaningless or not, that
> convinces NIST that the issue is resolved.  That probably requires a new CPE,
> and that will no doubt require the FreeBSD port maintainer to issue a version
> upgrade.  Otherwise  I am going to be forced into an unwanted, and evidently
> unnecessary, migration.  For which I have neither the time nor resources to
> effect.
> Regards,

***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
   Unencrypted messages have no legal claim to privacy
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:ByrneJB@xxxxxxxxxxxxx
Harte & Lyne Limited
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

squirrelmail-users mailing list
Posting guidelines:
List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx
List archives:
List info (subscribe/unsubscribe/change options):

[Index of Archives]     [Video For Linux]     [Yosemite News]     [Yosemite Photos]     [gtk]     [KDE]     [Cyrus SASL]     [Gimp on Windows]     [Steve's Art]     [Webcams]

  Powered by Linux