Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Ontwikkelaars dichten kwetsbaarheid in PHPMailer

Door , 41 reacties, submitter: kuurtjes

Oudere versies van het populaire php-script voor het automatisch versturen van mail, PHPMailer, blijken een kwetsbaarheid te bevatten die het voor een aanvaller mogelijk maakt op afstand code uit te voeren. In de laatste versie hebben de ontwikkelaars het probleem opgelost.

Om de PHPMailer-kwetsbaarheid met aanduiding CVE-2016-10033 te misbruiken, hoeft een aanvaller de webapplicatie alleen een mail te laten versturen door de kwetsbare PHPMailer-klasse, bijvoorbeeld via contact-, feedback- en registratieformulieren of het resetten van e-mailwachtwoorden. Vervolgens kan de aanvaller als webservergebruiker op afstand code uitvoeren. Dat beschrijft de Poolse beveiligingsonderzoeker Dawid Golunski van Legal Hackers, die ook een exploit ontwikkeld heeft. De precieze details maakt hij op een later moment bekend om beheerders tijd te geven de code bij te werken.

De ontwikkelaars van PHPMailer dringen er voor alle gebruikers op aan dat ze hun versie bijwerken naar versie 5.2.18. Bij deze actuele versie is het probleem opgelost. PHPMailer is een van de meestgebruikte php-libraries en is onder andere verwerkt in WordPress, Joomla, Drupal, SugarCRM en Mantis. Volgens BleepingComputer is inmiddels ook door derde partijen ontwikkelde exploitcode online verschenen.

Olaf van Miltenburg

NieuwscoŲrdinator

27 december 2016 15:10

41 reacties

Submitter: kuurtjes

Linkedin Google+

Reacties (41)

Wijzig sortering
Het is niet dť oplossing, maar als je zelf het mailadres server-side op invoervalidatie controleert met bijv. Filter_var(), dan lijkt de exploit niet uitgevoerd te kunnen worden.
Am i right?

[Reactie gewijzigd door AW_Bos op 28 december 2016 11:45]

Afhankelijk van hoe streng de filter voor e-mail is, in het verleden was deze niet RFC compliant.
Wat in deze situatie juist een voordeel blijkt te zijn, want de de RFC accepteert [code]"Attacker@test.com\" -X/var/www/test_swiftmailer/phpcode.php -oQ/tmp test"@test.com[/code] als geldig e-maiadres 8)7 (Want wie gebruikt er nu geen aanhalingstekens en dubbele @ in het e-mailadres?)

Maar filter_var() daarin tegen accepteert dit niet, https://github.com/swiftmailer/swiftmailer/issues/844 De e-mailadres RFC accepteer zelfs new lines en comments :? geen wonder dat dit fout gaat.
De stabiele versie is inmiddels al 5.2.19
Ondertussen blijkt de patch ook kwetsbaar te zijn: CVE-2016-10045
Heb de redactie gevraagd een update bij dit nieuwsbericht te plaatsen.
And there is a fix, just merged (11:11):
https://github.com/PHPMailer/PHPMailer/pull/929

Edit Lees het commentaar in #1 van de fix:
Needs to be tested to ensure no significant functionality is broken. Will avoid sending -f argument to sendmail when it's deemed unsafe to do so. Note that while this is a big step forward, more work needs to be done to increase security on Windows. sendmail and mail transport options should not be used on Windows for the time being.

[Reactie gewijzigd door Jan-E op 28 december 2016 11:20]

De fix is nog niet compleet zo te zien en er zitten nog fouten in, dus ik zou wachten met updaten tot de release 5.2.20 officieel klaar staat.

Joomla zelf geeft btw aan niet kwetsbaar te zijn:
No action required for Joomla users, the updated library will be included in the next scheduled release and additional mechanisms exist in Joomla core to prevent triggering the vulnerability. Users of the PHPMailer library separate from Joomla are advised to upgrade to 5.2.18 or newer ASAP.
Bron: http://feeds.joomla.org/JoomlaSecurityNews

Kan iemand bevestigen dat dit het geval is?
Ja, tenzij je 3rd party modules gebruikt met een mailformulier die niet via de Joomla 'api' werken. Dan heb je kans dat er niet goed gefilterd wordt.
Ik gebruik nog steeds versie 2.3. Ik vraag me af of die veiliger is omdat die al zo oud is dat er toch geen onveilige toeters en bellen in zitten? :) Ik gebruik alleen Mail, geen SMTP.
Hij is ook 3x zo klein qua bestandsgrootte. :)

[Reactie gewijzigd door Slingeraap2 op 4 januari 2017 21:56]

Sterker nog: 5.2.18 bevat een forse bug. Als je kiest voor sendmail als verzendmethode loop je tegen deze Exception aan:
https://github.com/PHPMai...class.phpmailer.php#L1368

Ze testen daar of '/usr/sbin/sendmail met alle opties' een file is en executable. Zo niet: plof. Die fout is er pas in 5.2.19 uitgehaald:
https://github.com/PHPMai...f578139c491c256ab1933c7c9

Edit: Wordpress zit nog op PHPMailer 5.2.14. Ik heb mijn installatie maar even met het handje gepatcht.

[Reactie gewijzigd door Jan-E op 27 december 2016 17:28]

WordPress core is niet kwetsbaar, omdat die de kwetsbare functionaliteit in PHPMailer niet gebruikt.
Er staat in het artikel dat Drupal core gebruik maakt van PHPMailer, maar dat is niet zo. Ze waarschuwen er wel voor: https://www.drupal.org/psa-2016-004.
Inmiddels is 5.2.20 verschenen:
https://github.com/PHPMailer/PHPMailer/releases
Important security update!

This release patches the critical vulnerability described in CVE-2016-10045 a remote code execution vulnerability, responsibly reported by Dawid Golunski, and patched by Paul Buonopane (@Zenexer).

Possible side effect - complex sender addresses (such as those used in VERP addressing) may no longer work. We advise switching to the SMTP transport if you need that functionality, and it offers higher performance anyway.

Please update your systems as soon as possible.

Additional notes on this incident are available in the PHPMailer wiki.

Note that the vulnerability described in here likely affects many other projects in a similar way, so please practice responsible disclosure, and help project maintainers fix security issues.
Edit. En zojuist ook nog 5.2.21 zonder functional changes. Het regent releases.

[Reactie gewijzigd door Jan-E op 28 december 2016 16:40]

Weet iemand of Swiftmailer gebruikt maakt van deze libraries?
---Edit---
Ik zie net dat dit juist concurrenten zijn O-)

[Reactie gewijzigd door nathan-96 op 27 december 2016 15:13]

Er is nu ook een kwetsbaarheid in SwiftMailer gevonden: https://legalhackers.com/...-CVE-2016-10074-Vuln.html.
Dat is wel goed om te weten, heel erg bedankt!
--edit--
Someone give this guy an upvote

[Reactie gewijzigd door nathan-96 op 29 december 2016 12:40]

Nope, Swiftmailer is zelf een library.
Ik denk zelf dat de bug in het aanroepen van mail() of sendmail zit, of een outdated aanroep naar een preg* met de 'e' modifier.
Natuurlijk kan Swiftmailer het zelfde probleem in een andere context hebben.
Als je de CVE bekijkt dan is dit een traditionele exploit waarbij men niet correct omgaat met parameters die worden doorgezet naar de sendmail executable. Als je overstapt naar het SMTP protocol om je mail te injecteren ipv mail() ben je van veel van dit soort problemen af. Oa PHPMailer en Swift Mailer ondersteunen dit al enige tijd gelukken en andere volgen ook omdat het handig is om een mailservice te hebben op je webserver.
Als je overstapt naar het SMTP protocol om je mail te injecteren ipv mail() ben je van veel van dit soort problemen af.
En je krijgt er weer andere voor terug. Door daadwerkelijk via een socket te connecten naar een MTA weet je niet meer welke gebruiker het is in de MTA. Ratelimiting is daar niet meer mee mogelijk in de MTA. Tevens heeft dit nogal wat overhead vergeleken met de overhead van direct injecteren via sendmail.

Desondanks zou ik de sendmail binary (hoeft niet de MTA sendmail te zijn) vermijden als het kan, dat ding is historisch altijd setuid root. MTAs zijn historisch gezien vaak een probleem geweest wat betreft privilege escalation (vooral de daadwerkelijke MTA sendmail).
Wat een niveau zeg :') over PHP te zeiken, maar als Ruby of Python lek is dan horen we niemand zeggen dat de taal/systeem zo slecht is.

PHPMailer is een library die al aardig wat jaren bestaat, en ondanks verschillende verbeteringen en ontwikkelingen in PHP zelf worden niet alle php projecten bijgewerkt om beter gebruik te maken van deze verbeteringen, waarom? Compatibiliteit, als ze plots klap alles gaan aanpassen kan je niet direct overstappen naar de nieuwste versie. Gevolg, mensen blijven liever de oude (niet onderhouden versie) gebruiken want die werkt te minste! Dus oude versies onderhouden, hoe vervelend ook is toch echt belangrijker dan altijd maar het nieuwste verplichten, geldelijk alles aanpassen is dan een betere optie (zie Symfony bijvoorbeeld, die maken een overstap van 2.8 naar 3.0 zo pijnloos mogelijk).

Is dit schuld van PHP? Nee! PHP is flink verbeterd sinds het 4.3 tijdperk, maar aangezien een project aanpassen geld en tijd kost blijven mensen nu eenmaal bij oude versies, ze zijn tevreden als iets werkt en zullen niet snel overstappen naar het nieuwere, veiligere, en snellere PHP 7 en diens verbeterde syntax.

Dat is niet de schuld van PHP maar de schuld van oude gewoontes, en koppige mensen. Beter bekend als software ontwikkeling O-)

Edit. Grammatica fouten.

[Reactie gewijzigd door s.stok op 27 december 2016 16:05]

weer Windows, weer Linux, weer een OpenSource pakket (C++), weer Java .... Ow wacht die zijn ook allemaal populair, zou er een verband zijn ? O+
Nee niet PHP maar een veelgebruikt script wat PHP gebruikt :|
Dit heeft vrij weinig te maken met PHP, maar met verkeerde code geschreven in PHP. :p Had net zo goed kunnen gebeuren met C#, Java, Python of welke taal dan ook...
Ik lees een heleboel negatieve reacties over PHPMailer en PHP expliciet.
Ooit schreef ikzelf een mailerscript in PHP en liep continue tegen problemen op die veel tijd kosten.
Als dan een club een prima script schrijft en dan ook nog eens onderhoudt, dan kan ik alleen maar zeer blij zijn.
Ik vind PHPMailer een geweldig script dat veel vervelend werk uit handen neemt, ondanks alle negatievelingen ten spijt.
Er is ook een alternatief voor PHPMailer genaamd Swiftmailer die meer moderne technieken gebruikt, uiteraard is dit ook niet vrij van bugs (vooral edge cases). Maar dat is meer te wijten aan de complexiteit van de verschillende RCF's (https://github.com/swiftm...mailer/tree/4.1/notes/rfc, oude links gaat meer om de hoeveelheid).

Ik heb zelf meegeholpen met het inbouwen van S/MIME wat gezien de geweldige API van OpenSSL niet zonder slag of stoot ging 8)7
Interessant, ga ik zeker eens bekijken.
Bedankt.
De fix die in v5.2.19 is doorgevoerd verhelpt de kwetsbaarheid niet: https://legalhackers.com/...45-Vuln-Patch-Bypass.html. Er staat nu een PR open met hopelijk de juiste fix: https://github.com/PHPMailer/PHPMailer/pull/930.
Volgens mij staat hier gewoon haarfijn uitgelegd hoe de kwetsbaarheid gebruikt kan worden: https://legalhackers.com/...-CVE-2016-10033-Vuln.html
haha 82% van het internet bestaat uit php :|
Tweakers runt op PHP.
Haha de programmeertaal waar heel Facebook op draait (al dan niet gecompiled naar C++ vanuit PHP) en dus bewezen stabiel is...
Volgens mij draait Facebook niet echt standaard PHP, maar Hack (http://hacklang.org/), via HHVM ipv de standaard PHP engine. Dus Facebook is misschien niet het beste voorbeeld ;)
Haha goede argumenten
Ze komen de laatste tijd wel steeds vaker langs. Misschien heeft het iets te maken met die k*treclames op de radio :r

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*