'MySQL bevat lek dat op afstand uitvoeren van code mogelijk maakt'

Beveiligingsonderzoeker Dawid Golunksi heeft een kwetsbaarheid in MySQL, MariaDB en PerconaDB gevonden die het op afstand uitvoeren van code mogelijk maakt als de aanvaller al toegang heeft tot de database. Het lek is onder andere aanwezig in de laatste versie van MySQL.

Voor de forks MariaDB en PerconaDB zijn eind augustus patches beschikbaar gekomen, zo schrijft de onderzoeker. Het beveiligingsprobleem met kenmerk cve-2016-6662 is onderdeel van meerdere kwetsbaarheden, voegt Golunksi daaraan toe. Het lek heeft gevolgen voor alle MySQL-servers in standaardconfiguratie, van de vroegste tot de huidige versies in verschillende branches, namelijk 5.7.15, 5.6.33 en 5.5.52. Het lek kan op afstand en door een lokale aanvaller gebruikt worden, zowel via sql-injectie als via geauthenticeerde toegang, en maakt het kunnen uitvoeren van willekeurige code als root mogelijk.

Volgens de onderzoeker is dit ook mogelijk als er beveiligingsmaatregelen als SELinux en AppArmor aanwezig zijn met standaard policies. Het lek bestaat daarin dat bij het starten van MySQL een script wordt uitgevoerd om bepaalde gedeelde libraries te laden. Door een pad naar een kwaadaardige bibliotheek in het my.cnf-configuratiebestand te injecteren, kan een aanvaller een willekeurige bibliotheek laden en op die manier code uitvoeren op een systeem. In dat geval moet het configuratiebestand eigendom zijn van, of schrijfbaar zijn door de 'mysql user'.

Golunski heeft een proof of concept geschreven om zijn claims te ondersteunen. Hij zegt dat beheerders met de Oracle-versie van MySQL in afwachting van een patch ervoor kunnen zorgen dat er geen configuratiebestanden eigendom zijn van de gebruiker 'mysql user'. Ook zou het aanmaken van een dummyversie van ongebruikte my.cnf-bestanden in eigendom van de root-gebruiker aan te raden zijn. Dit zou het probleem echter niet volledig verhelpen en het installeren van patches zou alsnog vereist zijn zodra deze uitkomen.

Op Reddit is enige kritiek ontstaan op de presentatie van de kwetsbaarheid, omdat het niet zomaar op afstand te gebruiken zou zijn, waardoor het eerder zou gaan om privilege escalation. Ook zou een aanvaller over 'super'- en 'file'-rechten moeten beschikken. De onderzoeker onderbouwt zijn keuze voor het publiceren van de kwetsbaarheid in afwezigheid van een patch, met het feit dat de patches van de andere partijen door kwaadwillenden opgemerkt kunnen zijn. Het zou inmiddels veertig dagen geleden zijn dat het lek bij Oracle is gemeld, maar een patch wordt pas in oktober verwacht.

Reacties (56)

[lesander]

MySQL bevat lek dat op afstand uitvoeren van code mogelijk maakt

Paniek! Paniek! Of zou het toch anders zitten dan de titel doet denken?

Het lek bestaat daarin dat bij het starten van MySQL een script wordt uitgevoerd om bepaalde gedeelde libraries te laden. Door een pad naar een kwaadaardige bibliotheek in het my.cnf-configuratiebestand te injecteren, kan een aanvaller een willekeurige bibliotheek laden en op die manier code uitvoeren op een systeem. In dat geval moet het configuratiebestand eigendom zijn van, of schrijfbaar zijn door de 'mysql user'.

Oke, dus de aanvaller moet een MySQL gebruikersaccount hebben en zelf toegang tot een my.cnf hebben. De meeste aanvallers geef ik geen gebruikersaccounts. Pfieuw, gelukkig.

En verder, zoals op [url="[url]https://www.reddit.com/r/netsec/comments/52dgxh/mysql_remote_root_code_execution_privilege/[/url]"]Reddit[/url] al aangegeven wordt:

First off, you need to be able to run SQL queries on the server. Not just injection (since MySQL doesn't support stacked queries) but actual full SQL queries. Not only that, but the user needs to be able to create stored procedures. You also need to have the ability to upload a malicious .so file to the system at a known path, accessible by the mysql user.

De aanvaller moet behalve een MySQL account op de server, ook nog een .so bestand mogen uploaden naar het systeem op een heel specefieke plek die de gebruiker moet weten, en toegang tot moet hebben.

Ik weet niet hoe het zit bij shared hosting servers, maar hopelijk geven goed ingestelde hosters niet zomaar MySQL logins weg die al administrator privileges hebben:

Second, SET GLOBAL requires the SUPER privilege on the database user. If the user you can make queries as is non-administrative, you can't set the general_log_file or general_log variables. So you already have to be an administrative SQL user to break out, at which point you've got access to call the more traditional file writing functions (SELECT INTO, etc.)

Sorry hoor, maar zo ernstig lijkt het niet te zijn. Ja oke, het is een security vulnerability, maar eerder een Privelige Escalation voor hele specefieke gevallen, omdat deze exploit voor lang niet iedere server die MySQL draait te gebruiken is.

Die details mis ik toch wel een beetje in het artikel

Leesvoer:
https://www.reddit.com/r/...ecution_privilege/d7jefp0
http://legalhackers.com/a...rivesc-CVE-2016-6662.html

[Reactie gewijzigd door lesander op 27 juli 2024 04:54]

[Cybje]

Voor webservers kan dit wel degelijk een groot probleem zijn, zeker bij shared hosting omgevingen. Als je 100 shared hosting klanten hebt welke allemaal Wordpress hebben, heb je tegenwoordig eigenlijk de garantie dat er een remote exploitable bug in zit waarbij PHP code kan worden uitgevoerd. Zeer bekend voorbeeld hiervan is de revslider exploit. In dat geval hebben ze dus eigenlijk al een paar mogelijkheden om die MySQL bug te misbruiken:

* Je hebt MySQL toegang (je kunt namelijk de Wordpress MySQL logingegevens uit wp-config.php uitlezen en verbinding maken)
* Je kunt volledige SQL queries uitvoeren
* Je hebt toegang tot het filesystem (je kunt bijv. het .so bestand in /tmp plaatsen)

Ik vind dus wel een heel ernstige bug, maar het verschilt per omgeving. Het vervelende hiermee is namelijk dat ze via de eerste laag binnenkomen op je server (Wordpress) en daarna veel verder de server in kunnen.

[MadEgg]

Je kan dan wel bestanden op het file-system zetten, je moet ook nog toegang tot my.cnf hebben. In een degelijke configuratie is dat bestand géén eigendom van de user die MySQL draait. Doorgaans zijn de meeste configuratiebestanden in /etc op Linux eigendom van de root-user, terwijl MySQL als de user mysql draait. De daemon hoeft de configuratie immers alleen maar te lezen en niet te schrijven. Basis-beveiliging, want configuratiebestanden zijn vaak erg krachtig en kunnen misbruikt worden. Zo ook hier.

Al met al dus een storm in een glas water. Het is niet heel vreemd dat een daemon shared libraries kan inladen op basis van een configuratiebestand. Goed, het zou veiliger zijn als dat alleen vanuit een vast pad, zoals /usr/lib/mysql/ zou zijn, waar, als het goed is, ook alleen de root-user toegang toe heeft, maar ondanks dat is het toch niet zo'n groot probleem als het artikel doet voorkomen.

Misschien is dit wel slechter geregeld op Windows, daar heb ik geen idee van. Op Linux stelt het niet heel veel voor.



Zoals Kees in 'nieuws: 'MySQL bevat lek dat op afstand uitvoeren van code mogelijk ... hier aanwees is het probleem toch even net wat ernstiger dan ik dacht, door een serie fuck-ups in de afhandeling van configuratie- en logging-bestanden. Zie MadEgg in 'nieuws: 'MySQL bevat lek dat op afstand uitvoeren van code mogelij... voor mijn rectificatie.

[Reactie gewijzigd door MadEgg op 27 juli 2024 04:54]

[Jaded]

Dit is een mooie samenvatting inderdaad, zojuist op mijn Linux-servers gecontroleerd.
MySQL-draait onder user mysql en /etc/my.conf heeft alleen schrijfrechten voor root. Geen probleem dus.

[Kees]

en wat is de homedirectory van de mysql gebruiker, en mag die daar wel een my.cnf bestand wegschrijven? Dan ben je net zo kwetsbaar want die word ook uitgelezen.

[MadEgg]

Damn, je hebt gelijk. Ernstiger dan ik dacht.

Er gaan dus meerdere dingen fout:

1) Het wrapper-script mysqld_safe parsed zonder problemen foutieve configuratie-files, voorzien van logging-cruft die de exploit gebruikt. De daemon zelf verslikt zich hierin, maar het bash-script gebruikt gebrekkige regexp's om een ini-parser te bouwen in plaats van een correcte ini-parser. Hierdoor is het mogelijk om met de preloaded shared library de configuratiefile te herstellen naar een juist formaat zodat de MySQL daemon ook gewoon netjes opstart.

2) Het wrapper-script mysqld_safe is dermate crufty dat ook die het toestaat om configuratie te overriden. Dat /etc/mysql/my.cnf overruled kan worden door een my.cnf in je homedirectory is al discutabel (en zou mijns inziens alleen mbv command line parameters moeten kunnen), maar dat een wrapper-script die alleen de boel launcht dat ook doet is nog veel ernstiger.

3) De logging-output staat het toe dat naar arbitraire bestanden geschreven wordt, zoals my.cnf. Een dergelijke functionaliteit zou moeten forceren dat er een .log extentie toegevoegd wordt om te voorkomen dat enig goedgeschreven programma gaat trachten om de logfile als configuratie uit te voeren. Helaas is er ook nog voldoende software die alle bestanden in /etc/*.d/ slikt in plaats van een extensie te vereisen (zoals .cnf of .conf).

4) Hoewel niet toegelicht is het schijnbaar mogelijk om uit /var/lib/mysql/my.cnf de logging-cruft te verwijderen zodat de ini-parser van MySQL zich hier niet op verslikt

5) En dan zit er ook nog een bug in het trigger-systeem waarmee je als gebruiker privilege escalation kan krijgen waardoor je zelf dan misschien geen administrative user bent maar je triggers wel als administrative user draaien. Hiermee is het mogelijk om de logging-parameters aan te passen terwijl dat anders niet mogelijk zou zijn.


Da's wel even een rijtje ernstige exploits. I stand corrected, ik ga mijn post hierboven aanpassen want dat is absoluut niet waar. Je bent wel snel kwestbaar. Het minste wat je kunt doen is:

sudo touch /var/lib/mysql/my.cnf
sudo touch /var/lib/mysql/.my.cnf

Zodat je root-owner configuratie-files hebt die niet aangepast kunnen worden door de MySQL-user.

[Reactie gewijzigd door MadEgg op 27 juli 2024 04:54]

[maxnl]

Het minste wat je kunt doen is:

sudo touch /var/lib/mysql/my.cnf
sudo touch /var/lib/mysql/.my.cnf

Zodat je root-owner configuratie-files hebt die niet aangepast kunnen worden door de MySQL-user.

Dan zul je ook iets aan de permissies van /var/lib/mysql moeten doen.
Want die zien er doorgaans zo uit:

$ ls -ld /var/lib/mysql
drwx------ 11 mysql mysql 4096 Sep 12 13:48 /var/lib/mysql

Gebruikers met schrijfrechten op een map, kunnen ook bestanden van anderen in die map verwijderen (tenzij er een sticky bit op zit, zoals bij /tmp).
De door jou als root aangemaakte bestanden kunnen met hetzelfde gemak dus gewoon door gebruiker mysql verwijderd worden.

[Reactie gewijzigd door maxnl op 27 juli 2024 04:54]

[MadEgg]

Niet helemaal. De grap is dat je met wat trucjes bestanden kunt schrijven als MySQL user, door de log-uitvoer naar dat bestand te zetten. Via deze weg kun je geen bestanden verwijderen. Het wordt sowieso een puinhoop als je die directory niet schrijfbaar maakt, dan kun je namelijk ook geen nieuwe databases meer aanmaken.

Om het bestand te verwijderen zul je toch echt shell-toegang moeten hebben, iets wat voor deze exploit niet nodig is. Een voorgaande, vergelijkbare exploit maakte gebruik van de SELECT INTO OUTFILE constructie met ruwweg hetzelfde effect, maar als bijverschijnsel dat de gecreeerde file world writable was. Door een patch accepteert mysql geen config files meer die world writable zijn, wat die aanval onmogelijk maakt. Via de logging-configuratie worden de files niet world writable aangemaakt wat dezelfde attack weer mogelijk maakt, zij het langs een iets andere route.

[maxnl]

>Om het bestand te verwijderen zul je toch echt shell-toegang
>moeten hebben, iets wat voor deze exploit niet nodig is.

Ah, daar heb je wel een punt.


Viel me verder op dat het opstartscript van bijvoorbeeld Ubuntu dat safe_mysqld script uberhaupt niet als root start, maar als mysql gebruiker.

==
# Start MySQL!
su - mysql -s /bin/sh -c "/usr/bin/mysqld_safe > /dev/null 2>&1 &"
==

Als je wel shell toegang zou hebben, valt er in zo'n geval met de exploit dus weinig extra te bereiken.
root krijg je er op Ubuntu niet van, en mysql had je al.

[Reactie gewijzigd door maxnl op 27 juli 2024 04:54]

[WillySis]

Dit lek is inderdaad zonder patch te dichten en een beetje admin heeft al op één of meerdere punten de instellingen zo staan dat dit lek in de echte wereld eigenlijk geen probleem mag zijn.

Op een Windows server is het iets meer werk om de file-rights zo beperkt mogelijk te houden. Het is nu zeker aan te raden om de schrijfrechten eens na te lopen.

[Muz1ekje]

Precies wat ik dacht, na het lezen van het artikel. Ik vind de toevoeging van dit stuk:

Op Reddit is enige kritiek ontstaan op de presentatie van de kwetsbaarheid, omdat het niet zomaar op afstand te gebruiken zou zijn, waardoor het eerder zou gaan om privilege escalation. Ook zou een aanvaller over 'super'- en 'file'-rechten moeten beschikken.

Wel bijzonder, gezien de titel... clickbait anyone?

[dimitrivisser]

Het zijn niet alleen de details die ontbreken...

"MySQL is een systeem voor databasemanagement"...

[wow7]

Oke, dus de aanvaller moet een MySQL gebruikersaccount hebben en zelf toegang tot een my.cnf hebben. De meeste aanvallers geef ik geen gebruikersaccounts. Pfieuw, gelukkig.

Dit is een beetje een rare statement , neem aan er is een installer van ergens een blog en of shop of what so ever over op een server die de gebruiker niet heeft verwijderd , je kan op de meeste servers gewoon remote met een MySQL server communiceren en dan installeren , zo mee heb je dan ook op je eigen remote MySQL server toegang tot de config die je gebruikt.

Misschien dan toch gewoon zeggen dat de myconf op de root server die user accounts beheerd moet zijn om de hack bruikbaar te maken ?.

Dus ook hier moet je wel vertellen hoe het zit , er zijn dus meerdere mogelijkheden om een myconfig in je bezit te hebben je hoeft niet eens op de root server te zijn remote kan ook en dan heb je gewoon volledig MySQL toegang.

[kozue]

Behalve dat je toegang moet hebben tot zowel de database als het bestandssysteem, gaat het blijkbaar om het laden van een library waar de exploit in zit. Zo kan ik ook wel exploits verzinnen, dit geldt namelijk voor iedere software die dynamisch libraries laadt.
Dus zegmaar net zoiets als firefox de schuld geven van lekken in flash player, want flash player is ook een externe library.
Niet alleen heel moeilijk te misbruiken, maar ook nog eens niet de schuld van mysql. Veel gedoe om niks dus.

[johnkeates]

Er ontbreekt nog wat:

Dit probleem komt voor op systemen die mysqld_safe gebruiken en geen LD preloading bescherming hebben, en dan ook alleen als een aanvaller een query kan uitvoeren om my.cnf aan te passen, en dat heeft ook alleen maar effect als je mysqld_safe parameters laat lezen uit my.cnf terwijl het als root draait voor dat je dropt naar de mysql user en het daadwerkelijke RDBMS programma start.

In de default opstelling komt dit voor:

- my.cnf kan door MySQL bewerkt worden (nergens voor nodig! uitzetten dus!)
- mysqld_safe leeft als root my.cnf
- mysqld_safe doet LD preloading op basis van wat in my.cnf staat

Stel dat je dus een dylib kan parkeren en die in my.cnf kan zetten en MySQL kan herstarten, dan heb je effectief de server geroot.

Dit is natuurlijk op te lossen:
- MySQL kan op afstand herstart worden via MySQL zelf (nergens voor nodig! wegdoen!)
- MySQL users kunnen via DQL files wijzigen, nergens voor nodig!
- mysqld_safe hoeft helemaal geen LD PRELOAD te doen! Uitzetten!
- MySQL random herstarten zonder te kijken waarom is niet bepaald een best practise, eerst kijken, dan pas wat doen!

Dat laatste is vooral van toepassing voor gevallen waarbij my.cnf injection en dylib droppen lukt, maar MySQL herstarten niet, dan kan je het laten crashen of een DOS doen, in de hoop dat de admin langs komt om het te herstarten zonder om te kijken.

Los van dit allemaal:

- met goede configuratie management gaat my.cnf natuurlijk OOB geen wijzigingen krijgen, implementeer dit dus
- met goede service management gaat een service niet random herstarten zonder opmerkingen
- met zaken als snort en naxsi kom je er toch vrij rap achter als iemand met je database loopt te rommelen via externe requests, en .so droppers zijn dan ook niet 'onzichtbaar' ofzo

Geen van deze oplossingen is extreem complex of door ofzo, stel dat je dus zelf MySQL gaat draaien, doe het dan ook meteen goed, en als je het niet kan, doe het dan ook niet! Zat goedkope prima werkende hosting pakketjes met MySQL waarbij het probleem lekker naar de hostende partij verschuift.

[StackMySwitchUp]

Houdt dit dan in dat als je website is beveiligd tegen injecties, dat iemand -om dit lek te kunnen gebruiken- eerst file of DB toegang moet krijgen? Want dan is het m.i. een stuk minder urgent dan dit artikel (of wellicht dat van de onderzoeker) doet voorkomen.

[mkools24]

Hoe beveilig je je website tegen injecties dan? Je kan wel iets als mod_security doen maar dat is ook niet 100% waterdicht?

[hdullink]

Fout! Met prepared statements alleen voorkom je geen injectie. Daar zijn prepared statements ook niet voor ontworpen. Met enkel stored procedures ook niet.

Je voorkomt injectie met "Parameterized Queries" (of "Variable Binding"). Dit kan in combinatie met prepared statements en stored procedures.

Prepared statements gebruik je als je een query heel vaak achterelkaar gebruikt, in een lus dus. Het heeft geen zin om een query te "preparen" als je die na één keer gebruiken weer weggooid.

Stored procedures gebruik je als de query heel groot is en je niet teveel bandbreedte op je netwerk wilt verspillen.

[Verwijderd]

Misschien een stomme vraag maar, waarom wordt zoiets niet bij de bron aangepakt. Bij de SQL taal zelf? Of is dit gewoon een legacy issue welke moderne databases zonder SQL niet hebben? Gewoon injecties onmogelijk maken in plaats van plakband oplossingen.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 04:54]

[hdullink]

"Code" injecties zijn niet beperkt tot SQL. Overal waar informatie, meestal in tekstvorm, van de gebruiker zonder controle worden verwerkt is kwetsbaar.

Vooral in gevallen waar de datastructuren in tekstvorm zijn (HTML, XML, JSON) of code in tekstvorm (scripts dus: JavaScript, PHP, .cmd, shell).

[RoyD]

Bij een SQL injectie wordt de gebruikersinvoer een (meestal opzettelijke) verandering van het SQL statement ipv een waarde om in een veld te zoeken. Dus het probleem zit niet in de SQL taal zelf, maar in hoe de SQL taal gegenereerd wordt door het programma.

[StackMySwitchUp]

https://www.owasp.org/ind...on_Prevention_Cheat_Sheet
Een mooi begin.. Je kunt al heel veel voorkomen door user input te escapen.

[mkools24]

Ja als developer maar ik bedoel meer als website beheerder die vaak afhankelijk is van software van derden, zoals vbulletin ofzo.

[cracking cloud]

Zorg er in ieder geval voor dat de software up-to-date is. Anders: website uitzetten, maar dat is meestal niet zo praktisch...

[Woet]

Prepared statements.

[RoyD]

Dat heeft wel prestatie nadelen mocht je gebruik maken van wildcards in je zoekstring.
B.v.:
Zoeken in een geindexeerd string veld (b.v. NAAM van iets). Wanneer je zoekt met "like" en je hebt de wildcard aan het einde staan (b.v. "zoeken%") dan kan het plan voor de query de index gebruiken. Bij de zoekvoorwaarde "%zoeken%" dan weer niet. Echter bij een prepared statement is niet bekend of er gezocht gaat worden met "zoeken%" of "%zoeken%". Hierom zal het query plan voor het prepared statement nooit de index gebruiken en bij veel zoekopdrachten onnodig traag zijn.

[EdDeNtEr]

Met prepared statements voorkom je injections dan hoef je niet alles te escapen zodat het ook in andere locales goed werkt.

[mcDavid]

Als je op een shared hosting pakket zit, zijn er al snel honderden andere gebruikers die die rechten hebben. Dat kan dus een aanzienlijk risico vormen.

[StackMySwitchUp]

Ik dacht altijd dat je je eigen instantie kreeg? (ik host mijn eigen websites dus geen idee)

[Blokker_1999]

Wanneer je gebruik maakt van shared hosting is ook de database server gedeeld met vele andere gebruikers. Evenwel door de manier waarop de rechten zijn ingesteld zie je die andere databases niet, net zo min als dat je de schemas van MySQL zelf ziet.

De kans dat je op een gedeelde MySQL server evenwel rechten hebt om de configuratie aan te passen of om de server te herstarten zijn nagenoeg nihil.

[Tozz]

Maar die users hebben geen SUPER of FILE permissies, dus imho nog steeds een non-issue.

Overigens, op mijn out-of-the-box Debian machine heeft user mysql /nonexistant als homedir, is /etc/mysql eigendom van user root. Kortom, alle requirements die genoemd worden worden op Debian zo te zien al niet aan voldaan.

Op mijn Debian systeem zijn de enige 2 users die 'super' en/of 'File' permissies hebben alleen user 'root' en user 'debian-sys-maint'.

[xoniq]

Met shared hosting zit je op 1 omgeving die dmv vhosts en user accounts wordt gescheiden. Met dedicated hosting draai je in een eigen instantie (vm) en dus een afzonderlijke (dedicated) Linux / windows server.

[mimic]

Uit de advisory:

If attackers do not have administrative rights required to access logging settings
and only have standard user privileges with the addition of FILE privilege then
they could still gain the ability to write to / modify configuration files.

This could be achieved by writing a malicious trigger payload:

Zonder exploitvoorbeeld. Deze staat in de advisory.

[Verwijderd]

Dat klopt, de 'korte uitleg' is dat iemand met de juiste rechten (zoals in het artikel genoemd de "super" en "file" rechten) en kwade bedoelingen via mySQL functionaliteiten (voor o.a. het automatisch starten van librarys) code kan uitvoeren op het gehele systeem.

Oftewel, iemand met toegang tot een server waar MySQL op draait kan (in specifieke gevallen; als de rechten zo staan ingesteld) MySQL misbruiken om verdere toegang tot de server te krijgen.

Al met al een beetje overtrokken dus, natuurlijk valt er wat voor te zeggen dat het niet cool is dat MySQL hiervoor misbruikt kan worden (en dat word dus als het goed is binnenkort gepatcht) maar je moet al behoorlijk wat toegang hebben (die je, toegegeven, via sql injectie zou kunnen krijgen) wil je hier uberhaupt iets mee kunnen.

Lang verhaal kort, als je site beveiligd is tegen sql injectie (en dat moet ie ook zijn) en je vertrouwd je developers, dan is er niets aan de hand.

[Wim-Bart]

Als er een lek is in je software, bijvoorbeeld wordpress of joomla en je kan SQL code uitvoeren dan ben je kwetsbaar.

[pug205]

Dat vroeg ik me dus ook af

[Jaded]

Het is te hopen dat meneer 'gsuberland' op Reddit gelijk heeft, anders staat vrijwel elke shared hosting server open om gehackt te worden. Even afwachten wie er gelijk krijgt...

[mimic]

Dat heeft 'ie niet, praktisch elke shared hosting staat 'open'. Er is een een exploit mogelijk om je eigen libs in te laden met een CREATE trigger.

If attackers do not have administrative rights required to access logging settings
and only have standard user privileges with the addition of FILE privilege then
they could still gain the ability to write to / modify configuration files.

[Jaded]

De FILE-privilege staat gelukkig in Plesk standaard uit. Hoe het in CPANEL geregeld is weet ik niet. Plesk zou dus veilig moeten zijn.

[Tozz]

Plesk is inderdaad veilig. Net gechecked. Die geeft geen SUPER en/of file privleges uit aan klantaccounts.

[Verwijderd]

dat dacht ik ook

[RoestVrijStaal]

IX. VENDOR RESPONSE / SOLUTION
-------------------------

The vulnerability was reported to Oracle on 29th of July 2016 and triaged
by the security team.
It was also reported to the other affected vendors including PerconaDB and MariaDB.

The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of
30th of August.
During the course of the patching by these vendors the patches went into
public repositories and the fixed security issues were also mentioned in the
new releases which could be noticed by malicious attackers.

As over 40 days have passed since reporting the issues and patches were already
mentioned publicly, a decision was made to start disclosing vulnerabilities
(with limited PoC) to inform users about the risks before the vendor's next
CPU update that only happens at the end of October.

No official patches or mitigations are available at this time from the vendor.
As temporary mitigations, users should ensure that no mysql config files are
owned by mysql user, and create root-owned dummy my.cnf files that are not in
use.

Een glibberige aanname is dus dat met de laatste "vendor" Oracle bedoeld wordt. Want MariaDB en Percona zijn al gepatched.

Dit is wel een eye opener om van MySQL naar MariaDB, Percona of Drizzle te switchen. Als Oracle zo laks is met updaten, moet het bloeden. Bij de overname van Sun Microsystems door Oracle was het al zo klaar als een klontje dat MySQL niet veel prioriteit zou krijgen.

[Reactie gewijzigd door RoestVrijStaal op 27 juli 2024 04:54]

[Dreamvoid]

MySQL is open source, iedereen kan een patch schrijven, niet enkel Oracle.

[RoestVrijStaal]

De vraag is waarom je in hemelsnaam het vuile werk van Oracle zou willen opknappen als die lui daar zich daar niet verantwoordelijk voor voelen om het te doen.

Terwijl er zat forks van MySQL zijn waar extra handjes welkom zijn, en waarvan de ontwikkelaars die wèl iets geven om hun MySQL-fork.

[Tozz]

MySQL is open source, iedereen kan een patch schrijven, niet enkel Oracle.

Dat is leuk, maar jouw patch komt niet in de MySQL broncode repository. Dat moet Oracle doen. Dus voor het patchen van alle systemen die werken middels packages is het toch echt wachten op oracle.

[bush]

Oracle has a bad track record for security patching
http://www.infoworld.com/...lnerability-reports-.html

[biglia]

Beveiligingsonderzoeker Dawid Golunksi heeft een kwetsbaarheid in MySQL, MariaDB en PerconaDB gevonden die het op afstand uitvoeren van code mogelijk maakt als de aanvaller al toegang heeft tot de database. Het lek is onder andere aanwezig in de laatste versie van MySQL.

Misschien is het gevaarlijk bij shared hosting?

[_the_mars_]

Geeft geen problemen op Ubuntu of Debian, omdat root daar standaard eigenaar van /etc/mysql/my.cnf is.

[BliXem]

Laatste MariaDB 10 is 10.0.27, bevat deze de patch of moeten we nog wachten hierop?

Update: de exploit is in versie 10.0.27 opgelost.

[Reactie gewijzigd door BliXem op 27 juli 2024 04:54]

[Rabb]

Als ik het goed begrijp bevat linux dezelfde "bug", je kunt immers andere repositories toevoegen.

De bugs die de laatste tijd naar voren komen slaan bijna nergens op. Ze geven eerder aan dat we het momenteel goed doen.

[Dutch_CroniC]

Offtopic:
Grappig. Ik las voor het eerst over CVE tijdens die stagefright lekken op Android.
Dacht dat ze daar specifiek CVE aan geplakt was, maar kom net tegen dat dat al sinds '99 gebruikt wordt