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

Door , , 51 reacties

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)

Reactiefilter:-151051+136+211+32
Moderatie-faq Wijzig weergave
Port 1433 toch ? Staat me iets van bij van vroeger
Toen was er ook een hack
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.
Alle software van een bepaalde complexiteit heeft wel eens te maken met kritieke lekken of bugs. Dat blijkt zelfs waar te zijn voor open source software die vaak gereviewed wordt als BSD of Chrome.

Dus nee, het is geen verrassing dat MySQL een lek bevat. Op basis van enkele gevallen kun je ook niet veel zeggen over de kwaliteit van de code.
Misschien meer van belang is de kwaliteit van de achterliggende community / onderneming. Welk beleid hebben ze, hoe snel reageren ze etc. Oracle heeft in het verleden nogal steken laten vallen hierin, maar aangezien ik geen MySQL gebruiker ben, weet ik niet van de huidige stand. Laten we van een incident iig geen algemeenheden afleiden.

Ik ben het wel met je eens dat de keuze voor MySQL tegenwoordig lastig te verdedigen is. Voor lichtgewicht integratie zal de keuze naar SQLite gaan en nieuwe projecten zullen vaak kiezen voor de kwaliteit van Postgres (+gemeenschap).
Alles gaat naar Postgres inderdaad. De gemeenschap doet overigen nooit een drol. Het gaat erom of er een paar bedrijven wat geld en tijd steken in de database te verbeteren.

SQLlite wordt steeds minder ondersteund overigens.

Het overnemen van MySQL door oracle was een geniale zet vanuit oracle. Laten we hopen dat ze geen truuk weten te verzinnen om Postgres met een list over te nemen.

Dat 'alles wel eens een lek' heeft ben ik niet met je eens. Want je veronderstelt toevalligheid en het is niet toevallig dat dit soort lekken erin zitten.

Kijk eens goed om je heen. In elk belangrijk project, zitten Russen die als je ze uitcheckt 'toevallig' op een plek in moskou werken waar je niet zo maar naar binnenloopt.

Als je dan kijkt welke code ze produceren, dan heeft dat vaak met gesteggel met het filesysteem te maken.

Russen contributies zien 'doneren' aan open source projecten waar verder niemand mee valt te hacken, dat heb ik nog NOOIT gezien.

Nu zijn zij niet de enigen. In dit soort projecten zie je ook steeds vaker Brazilianen en Chinezen (al dan niet gecloakt). Allemaal doneren ze code, maar open source projecten die niet te maken heeft met data die veel geld waard is, daar heb ik Brazilianen en Chinezen nog nooit een regel code zien doneren.

Dus het woord 'toevallig', wat je overigens niet gebruikt, maar wel impliceert, dat is geheel niet van toepassing hier.

You get what you pay for.

Als je deze open source databases gebruikt voor data die geld waard is, al dan niet confidentieel - dan neem je een onaanvaardbaar risico simpelweg.

[Reactie gewijzigd door hardwareaddict op 3 december 2012 21:48]

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?
Nouja, jij mag 't ook op je productiedatabase proberen...
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
Niet al te beste opname, maar inderdaad is het resultaat tamelijk pijnlijk.
Hm, ik vraag me af of MariaDB dit probleem ook heeft.

Edit:

CVE-2012-5613 MySQL (Linux) Database Privilege Elevation Zeroday Exploit
Not a bug. MySQL manual specifies many times very explicitly [regarding granting access of the FILE privilege]. Thus, CVE-2012-5613 is not a bug, but a result of a misconfiguration, much like an anonymous ftp upload access to the $HOME of the ftp user.

http://openquery.com/blog/mariadb-security-updates

[Reactie gewijzigd door quannah op 3 december 2012 14:27]

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
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".
Dank voor de verduidelijking. Dat maakt de impact al een stuk beperkter gelukkig.
Dit is inderdaad een van die lekken, als je deze kan misbruiken dan heb je de beveiliging sowieso niet goed op orde:
- "GRANT ALL PRIVILEGES" wordt afgeraden, beter geeft je toegang tot een beperkte set tabellen.
- "GRANT FILE" is iets wat je niet snel zal gebruiken en wat standaard uitstaat.
- Elke DB beheerder zal via een firewall toegang van buitenaf beperken tot hooguit een paar vertrouwde IP adressen

Dit past in het straatje van "beveiligings"onderzoekers die hun 2 seconds of fame willen behalen. Je geeft namelijk niet volledige toegang tot een database (incl. drop table) aan gebruikers die je niet vertrouwd. Het lijkt meer op iemand die even snel naam voor zichzelf wil maken (dat neemt niet weg dat dit probleem zo snel mogelijk opgelost moet worden).

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True