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: https://nvd.nist.gov/vuln/detail/CVE-2020-14933#match-5399106 >>> >>> Has this been patched? >> >> There is no vulnerability here. Per OWASP: >> >> https://owasp.org/www-community/vulnerabilities/PHP_Object_Injection >> >> ===== >> 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 (https://www.openwall.com/lists/oss-security/2020/06/20/1). 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 Hi, 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. [1] https://svn.code.sf.net/p/squirrelmail/code/branches/SM-1_4-STABLE/squirrelmail/src/compose.php [2] https://github.com/hannob/squirrelpatches/blob/main/patches/squirrelmail-security-mailto-avoid-unserialize.diff [3] https://github.com/hannob/squirrelpatches [4] https://blog.ripstech.com/2018/php-object-injection/ -- Hanno Böck https://hboeck.de/ >> 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 http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ----- squirrelmail-users mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List archives: http://news.gmane.org/gmane.mail.squirrelmail.user List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
