CVE-2017-20187 (published 2023-11-05T21:15Z)

** UNSUPPORTED WHEN ASSIGNED ** A vulnerability was found in Magnesium-PHP up to 0.3.0. It has been classified as problematic. Affected is the function formatEmailString of the file src/Magnesium/Message/Base.php. The manipulation of the argument email/name leads to injection. Upgrading to version 0.3.1 is able to address this issue. The patch is identified as 500d340e1f6421007413cc08a8383475221c2604. It is recommended to upgrade the affected component. VDB-244482 is the identifier assigned to this vulnerability. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

CVSS v3 base score: 9.8, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-74
cwe_name: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
description: The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
extended_description: Software or other automated logic has certain assumptions about what constitutes data and control respectively. It is the lack of verification of these assumptions for user-controlled input that leads to injection problems. Injection problems encompass a wide variety of issues -- all mitigated in very different ways and usually attempted in order to alter the control flow of the process. For this reason, the most effective way to discuss these weaknesses is to note the distinct features that classify them as injection weaknesses. The most important issue to note is that all injection problems share one thing in common -- i.e., they allow for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows, and many other flaws, involve the use of some further issue to gain execution, injection problems need only for the data to be parsed.
         

Fix information:
repo_url: https://github.com/floriangaerber/Magnesium-PHP
commit_details: repo_url: https://github.com/floriangaerber/Magnesium-PHP
author: Florian Gärber
author_date: 2017-05-26 13:19:47+02:00
msg: Fix exploit of user's names/emails breaking "To"

Before being added to the "To" string, emails and names are cleared of <
> , and names are additionally cleared of @. See
Magnesium\Message\Base::removeToStringBreakingSymbols() DocBlock for
more details.
repository: repo_url: https://github.com/floriangaerber/Magnesium-PHP
repo_name: floriangaerber/Magnesium-PHP
description: Wrapper for Mailguns PHP API-client
repo_language: PHP
owner: floriangaerber
file_changes: filename: Base.php
change_type: ModificationType.MODIFY
diff: @@ -227,8 +227,35 @@ class Base
     protected function formatEmailString(string $email, string $name = null)
     {
         return $name
-        ? sprintf('%s <%s>', $name, $email)
-        : $email;
+        ? sprintf(
+            '%s <%s>',
+            $this->removeToStringBreakingSymbols($name, false),
+            $this->removeToStringBreakingSymbols($email, true))
+        : $this->removeToStringBreakingSymbols($email, true);
+    }
+
+    /**
+     *
+     * Should a user have chosen a name like "no1@example.com, Not Okay <no2@example.com>, Sherbert",
+     * Mailgun would accept the following to: "user@example.com, user2@example.com, no1@example.com, Not Okay <no2@example.com>, Sherbert <hello@example.com>"
+     * and would send it accordingly, which is unwanted behavior.
+     * Removing only "," breaks the To-string, sending the message to
+     * "user@example.com, user2@example.com, no1@example.com Not Okay <no2@example.com> Sherbert" hello@example.com,
+     * revealing email addresses of other users.
+     * Removing only either of "<,>" or "@," breaks the string the same way.
+     * Only removing "<>@," from the string prevents breaking (as far as I know).
+     *
+     * Also use an input validation library like Respect/Validation or find
+     * another way to prevent emails and names from containing "<>,"!
+     *
+     * @param string $string
+     * @param bool   $isEmail
+     *
+     * @return string
+     */
+    protected function removeToStringBreakingSymbols(string $string, bool $isEmail)
+    {
+        return str_replace($isEmail ? ['>', '<', ','] : ['>', '<', ',', '@'], '', $string);
     }
 
     /**

programming_language: PHP