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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 51, views: 27.505 •

Een kwetsbaarheid in MySQL maakt het voor gebruikers met beperkte rechten mogelijk om toegang als beheerder te krijgen. Een beveiligingsmedewerker van Red Hat noemt de mogelijke impact van het beveiligingsprobleem 'zeer ernstig'. Er is nog geen patch beschikbaar.

De kwetsbaarheid is onderzocht door een beveiligingsonderzoeker met de nickname Kingcope. De bevindingen van Kingcope zijn geanalyseerd en gepubliceerd door een andere beveiligingsexpert, Eric Romang, en daaruit blijkt dat het mogelijk is voor een gebruiker met bepaalde, beperkte gebruikersrechten om root-toegang tot MySQL te krijgen.

Om het beveiligingsprobleem te misbruiken, moet een gebruiker dus wel al toegang hebben tot een database, wat de kans op misbruik vermindert. De kwetsbaarheid zou de consequenties van een aanval echter wel kunnen vergroten: een aanval waarbij een gebruiker slechts beperkte toegang tot een database heeft, zou tot gevolg kunnen hebben dat de aanvaller root-toegang krijgt.

Ook lijkt het er op dat een gebruiker in staat moet zijn om op afstand in te loggen op MySQL: een deel van de aanval bestaat uit sql-code die bijvoorbeeld via phpMyAdmin kan worden uitgevoerd, maar voor een ander deel van de aanval moet rechtstreeks op de MySQL-server ingelogd worden. Over het algemeen wordt aangeraden om MySQL-servers niet van buiten het interne netwerk benaderbaar te maken.

Desondanks noemt Kurt Seifried, een medewerker van het beveiligingsteam van Red Hat, de mogelijke consequenties van het beveiligingsprobleem 'zeer ernstig'. Red Hat is zelfs zo ver gegaan om zelf een  zogenoemd CVE-nummer, waarmee beveiligingsproblemen worden geclassificeerd, te koppelen aan de kwetsbaarheid. Normaliter doet de software-ontwikkelaar dat.

Naast het beveiligingsprobleem zijn er dit weekend een aantal bugs opgedoken die het mogelijk maken om een MySQL-database offline te halen, schrijft ZDNet. Om hoeveel bugs het gaat, is nog niet duidelijk: er zijn in totaal vier meldingen van denial of service-kwetsbaarheden, maar mogelijk gaat het in twee gevallen om hetzelfde beveiligingsprobleem, en bij een andere melding gaat het mogelijk om een configuratiefout.

Reacties (51)

Nu zie ik in het voorbeeld:
CREATE DATABASE exampledb

Heeft een standaard account voor webservices wel toegang tot deze commando's? Er staat dan wel dat je reeds toegang moet hebben met 'beperkte' rechten, maar is juist het hele create commando onderdeel van functies die je altijd hebt uitstaan? (behalve bij admin level).

Goed, neem aan dat het gros niet eens werkt met meerdere users binnen MySQL, maar gezien het 2de deel (attacker side), moet je dus of directe toegang hebben tot de PC waarom MySQL draait (als hij enkel localhost accepteert) of dus de PC waar MySQL ook naar luistert?
Patch zal wel even duren gezien de trend van Oracle :)
Dit is toch wel vrij ernstig..

'Om het beveiligingsprobleem te misbruiken, moet een gebruiker dus wel al toegang hebben tot een database, wat de kans op misbruik vermindert. '

Veel bedrijven voor webhosting werken met mysql, waarbij ze ook een mysql user voor je aanmaken met beperkte rechten, in theorie zou je dus eenvoudig vele websites kunnen hacken door simpelweg een site af te nemen bij een hosting provider. Daarnaast draaien er nu al zeer veel mysql accounts met beperkte rechten op vele, vele servers.

[Reactie gewijzigd door paradoXical op 3 december 2012 12:01]

Je moet alleen wel FILE rechten hebben om de triggers te mogen maken, dus zolang je dat al niet hebt (ik dacht standaard niet) kom je nergens
"maar voor een ander deel van de aanval moet rechtstreeks op de MySQL-server ingelogd worden."

Als ik het goed heb kun je bij meeste hosting bedrijven niet direct op de MySQL-server inloggen van buiten het netwerk, dus kan deze laatste stap gelukkig niet uitgevoerd worden (ik neem aan dat dit om een soort van command-line gaat, die je niet kan benaderen vanuit bijvoorbeeld PHP scripts?).
De create database is om te demonstreren dat het om een schone standaard omgeving gaat.

De echte exploit zit in een perl script zie:
http://www.youtube.com/wa...mbedded&v=uCxy6yTynp4
Dat klopt helemaal. Ik heb dit lek gisteren al bekeken. Je moet inderdaad file rechten hebben, die je met een GRANT ALL ON database.* TO [...] niet krijgt. De file-rechten moeten expliciet worden ingeschakeld. Ik heb al m'n mysql servers nagekeken, er bleek er niet een vatbaar.

Het probleem is dan dat de gebruiker .MYD/.MYI bestanden (mysql data bestanden) met crafted data kan schrijven op het filesystem en deze in de databaseserver kan openen. De crafted data kan gebruikt worden om database-root te worden.

Dit lek is vergelijkbaar met "OMG, als ik een gebruiker rechten geef om /etc/passwd te schrijven, kan hij z'n rechten verhogen".
"Red Hat is zelfs zo ver gegaan om zelf een zogenoemd CVE-nummer, dat de ernst van een beveiligingsprobleem aanduidt, te koppelen aan de kwetsbaarheid."

Alleen kan Red Hat dat niet, omdat zij het systeem niet beheren.
Bij mijn host, die shared virtual hosting aanbiedt (en die ik voor de zekerheid maar even niet noem), kan dat wel. Daar kan je inloggen op de SSH server, waar vanuit je direct kan inloggen op de MySQL database.
Inderdaad heb je hiervoor twee cruciale dingen nodig namelijk FILE privileges en remote-toegang tot de databaseserver.

Dat laatste komt nog wel eens voor maar dat eerste meestal niet. Ook kun je jezelf dit vaak niet geven omdat je als het goed is geen GRANT privs hebt.

[Reactie gewijzigd door mace op 3 december 2012 12:18]

Nouja, jij mag 't ook op je productiedatabase proberen...
Het is nu een perl script wat je uit moet voeren maar ik zie niets wat niet in PHP gedaan kan worden.
Dat is dus niet direct. Direct wil zeggen dat je de MySQL server direct aanspreekt. Standaard op poort 3306. In jouw situatie moet je eerst de ssh server binnen komen om mysql vanaf de command line aan te spreken.
Als ik het goed heb kun je bij meeste hosting bedrijven niet direct op de MySQL-server inloggen van buiten het netwerk
Het hoeft ook niet van buiten het netwerk. Het is een hosting provider, je kan gewoon op die machine een scriptje runnen dat intern contact maakt met de MySQL server.
ik neem aan dat dit om een soort van command-line gaat, die je niet kan benaderen vanuit bijvoorbeeld PHP scripts?
Nee, het gaat erom dat je direct naar de server kunt connecten om commando's door te sturen. Het voorbeeld gebruikt een perl scriptje, maar dat kan natuurlijk ook in PHP. MySql interpreteert de net uitgeschreven file vervolgens gewoon als valide trigger alsof ie aangemaakt is met CREATE TRIGGER. Met het verschil dat er op CREATE TRIGGER natuurlijk wel een rechtencheck zit, terwijl het voor aangemaakte file net is alsof de root user die trigger gemaakt heeft.

En eerlijk gezegd vraag ik me af of het niet ook gewoon via phpMyAdmin kan. Hier staat het Perl script. Blijkbaar werkt het door een trigger aan te maken met root rechten in de juiste mysql folder mbv SELECT ... INTO OUTFILE. Blijkbaar is er dus geen enkele controle over waar de file wordt geschreven, en met wat voor rechten.

En tenzij de msql server in zijn eigen aparte user runt met gelimiteerde rechten, gaat dit nog veel verder dan alleen volledige rechten over de database verkrijgen. Want een mysql server die onder root runt kan dus gewoon overal naar schrijven.

.edit: ik lees verderop in de comments dat file schrijf rechten dus blijkbaar niet standaard aan staan.

[Reactie gewijzigd door .oisyn op 3 december 2012 12:54]

Ze kunnen dat inderdaad niet. Ze hebben wel een entry ingeschoten die nu gereviewed moet worden door de CVE Editorial Board.
Dank voor de verduidelijking. Dat maakt de impact al een stuk beperkter gelukkig.
Dat laatste hoeft volgens mij niet perse. Je kunt ook een scriptje hebben bij een hosting provider die je dan laat draaien op de machine waar mysql draait en dan zou het in theorie ook werken.
hij zegt net dat ie ssh access heeft, dus ja hij kan direct met de mysql server praten. Overigens, als jer er vanuit php bij kan, dan kan je dus ook de exploit draaien, moet je alleen even het perl script omschrijven naar php.
Dat hoeft niet. Op de FTP komen is in principe ookal voldoende omdat je dan deze exploit ook kan laten runnen op de mysql database.

Edit: Oh ik zeg nu precies hetzelfde als .oisyn hieronder :P

[Reactie gewijzigd door Rutix op 3 december 2012 12:36]

En nu de grote vraag: "was er ook maar 1 persoon, die met mysql gewerkt heeft, GESCHOKT dat er zo'n enorm lek inzit?"

Kunnen we er 1 in dit forum vinden?

MySQL is natuurlijk al heel lang old school. ofschoon nog veelgebruikt.

Vergis je niet - al deze databases worden ook gebruikt voor backups van de grote bedrijven. Bacula (het backupsysteem waarop zoveel gebaseerd is wat met taperobots werkt) werkt bijvoorbeeld met verschillende open source databases.

Natuurlijk zitten in die andere soortgelijke beveiligingsproblemen.

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneAsus

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013