Vlákno názorů k článku PHPMailer má kritickou chybu, ohrožuje miliony webů od Pajk - Co říkáte na tento námět na omezení dopadu...
-
Pajk (neregistrovaný)
Co říkáte na tento námět na omezení dopadu (mitigation): Když jde o problém injektáže "nepořádku" přes pátý parametr funkce mail, tak proč nepoužít php.ini direktivu mail.force_extra_parameters s hodnotou třeba -fapache@hostname (samořejmě dosadit apache runtime usera a server hostname). Tím pádem žádný pátý parametr z aplikace nepřijde a prakticky to stále bude fungovat (dostatečně dobře) ...
-
Pajk (neregistrovaný)
No podle mého názoru phpmailer a cokoliv jiného v režimu použití funkce mail pošle něco do pátého parametru a php to prostě bude ignorovat a dosadí si hodnotu (bezpečnou) z konfiguráku ... Ano, mail nemůže mít envelope adresu z aplikace, bude mít pouze From: v hlavičce dopisu, ale podle mého názoru je to minimálně "good enough".
-
Pajk (neregistrovaný)
Ale pokud mám nastaveno v class.phpmailer.php
public $Mailer = 'mail';
(což je zřejmě default) a navíc mám v php.ini zakázané funkce jako system/exec/proc_open/popen, tak (imho) posílám pomocí fce mail a třeba nedávné CVE-2016-9920 řeší podobný problém pro Roundcube a zmiňuje se, že problém je právě injektáž v tom zpracování pátého parametru funkce mail, kdy sendmail není volán z php aplikace, ale ze samotného vnitřku php - https://blog.ripstech.com/2016/roundcube-command-execution-via-email/ . A je jasné, že phpmailer dokáže odesílat maily bez nastaveného smtp a se zakázaným popen, tj. pomocí mail ... Takže si myslím, že můj návrh může pomoci při tom defaultním použití funkce mail.
-
Aha, teď jsem prozkoumal zdroják PHPMaileru lépe a vypadá to, že někdy se skutečně používá funkce mail a injekce by šla do jejího pátého parametru. Tzn. útok by nemusel jít výhradně přes PHPMailer používající sendmail (popř. qmail), ale i přes PHPMailer používající funkci mail. Sice podle oficiální dokumentace by to mělo skrze escapeshellcmd zabránit přímému shell injection, ale mělo by to jít oklikou.
Potom by mělo jít o použitelný způsob mitigace útoku této zranitelnosti, pokud se používá funkce mail. Pokud ne, pak to nepomůže.
Ale:
1. Jak jsem tu postoval, oprava byla nekompletní. Zatím nedovedu říct, jestli i tu druhá část opravy lze nahradit tímto workaroundem.
2. Způsob odesílání se rozhodně nenastavuje v class.phpmailer.php! Tam je uvedena pouze defaultní hodnota, kterou lze přepsat za běhu, například metodou isSendmail(). V souboru class.phpmailer.php by se ale nic měnit nemělo. -
Pajk (neregistrovaný)
Nejsem programátor web aplikací, jsem administrátor serverů. Takže z mého pohledu vynucené přebití zranitelného pátého parametru je "good enough" mitigace v situaci, kdy blokuju použití popen a spol. (tj. přímé volání sendmail a jiných execů není možné) a tedy zbývá mail (doufám, že opravený přebitím) nebo smtp (které by mělo být v pohodě samo od sebe). Že by se sendmail někdy nějak použil k přípravě materiálu pro fci mail, to jsem ve zdrojáku phpmaileru nevyčetl ...
-
Pajk (neregistrovaný)
Samozřejmě souhlasím s tím, že správné řešení je update. Ale podle dostupných informací to vypadá, že problém by mohly mít i jiné podobné mailovací nástroje založené na volání php funkce mail (viz. časově předcházející publikovaný problém Roundcube) a tedy mnou navržená mitigace je pro mne preventivním řešením, které jsem nasadil. Rád si přečtu kvalifikovanější rozbor nebo vyvrácení mého názoru ...
Ohledně rozbití - jsem v pozici, kdy vidím, že maily odcházejí, v mail klientech vypadají správně (From:), envelope from a received headers mé zákazníky snad "netankují", ip adresa pro spf v envelope je nedotčena, takže "u mne dobrý", aspoň teda zatím. -
> mnou navržená mitigace je pro mne preventivním řešením, které jsem nasadil.
Souhlas. Původně se mi to nezdálo (myslel jsem, že s funkcí mail to nijak nesouvisí, navíc nápad nastavit tam natvrdo from zněl jako snaha ovlivnit PHPMailer, což by nešlo), ale teď to beru jako dobrý napad.
Ad rozbití – OK, ale obecně vzato: to záleží.
ČLÁNKY DO MAILU