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.326 •

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
Port 1433 toch ? Staat me iets van bij van vroeger
Toen was er ook een hack
het valt allemaal wel mee,

1. je moet ssh/ftp access hebben op de mysql server
2. je moet FILE rechten hebben

als je een van deze 2 niet goed hebt ingesteld op een server dan ben je niet slim bezig
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]

Dus als ik het goed heb is dit een beveiligingsprobleem dat al 10 jaar bestaat?
En wordt nu weer aangekaart door een onderzoeker, terwijl dit al bekend is?
Waarom denkt iedereen als ik dat en dat heb afgesloten ben ik niet vatbaar voor de hack.

Het gaat er om dat een hacker, als hij in het systeem zit vrij simpel als root door je mysql server loopt ondanks de extra wachtwoorden en dergelijke.

Dus het is wel een vrij ernstig lek.

Daar als je dit script via een andere hack wel weet te draaien binnen de perl of php omgeving van een server je als nog de sjaak bent ondanks alle ssh en andere beveiligingen.
Storm in een glas water...

Bekijk de (met alle respect) onzin en troep eens waar deze Kingcope de full-disclosure mailinglists mee volspammed! (zie bijvoorbeeld insecure.org\full disclosure)

Toevallig is hij nu ergens op gestuit wat een boel mensen zelf verkeerd configureren.
Dit is geen bug/exploit, dit is een feature; gedocumenteerd en wel!
De definitie van een bug kan nogal rekbaar zijn. Een database engine zou mijns inziens by default de gebruiker moeten beschermen en iedere afwijking daarvan moet bewust gemaakt worden.

Daarmee zou dit een bug zijn. Evenals het ongevraagd verwijderen van spaties uit VARCHAR of standaard case insensitive gedrag, delen door 0 zonder foutmelding etc.

Ik snap dat het vast allemaal gedocumenteerd is, maar dat is niet mijn punt. Een bug houdt niet op een bug te zijn door hem te documenteren. Of door te zeggen dat het default is die je kunt aanpassen.
- Default is dit dus NIET mogelijk; een waarschuwing ieder moment dat je een krachtige functie importeert lijkt me wat overdreven... UAC anyone?
- eval (php e.d.) is ook een 'gevaarlijke' functie; iedereen weet dat en gaat er zorgvuldig mee om. Hoezo is het nu ineens dan een beveiligingsprobleem?

In dit geval is, zoals zoooo vaak, de onwetende gebruiker het probleem.
Dit is gewoon een feature, welke wegens de risico's standaard uit staat.
Nu zet iemand hem aan en blèrt: "ik heb een beveiligingsrisico gevonden!"
No shit Sherlock!

Deze exploit is bij juiste configuratie (van mysql of op file-niveau) geen enkel issue meer.
Keren we het om: Door onjuiste configuratie is dit een beveiligingsrisico.

Get the point?
Zo slecht is UAC helemaal niet, het geeft aan dat je een krachtige functie activeerd. Hell, 90% van de mensen die de melding te zien krijgt weet niet eens wat het is en hoe het uit te schakelen. Voor mensen die weten wat ze doen is het overdreven irritant :)

Wat ik dan niet begrijp waarom red hat hier zown probleem van maakt, aan het artikel te zien, als het working as intended is?
Sorry hoor maar permission evaluation hoort nooit een feature te zijn hoe goed zoiets ook gedocumenteerd is en zeker niet op deze manier. Het zeer gevaarlijk om toe te staan files aan te maken op het systeem en dan meteen de user van die file te veranderen in root@localhost terwijl die daar niet vanaf komt.

[Reactie gewijzigd door Rutix op 3 december 2012 13:44]

Standaard wordt dit ook niet toegestaan, dit is het 'gewone' gedocumenteerde gebruik van de FILE-permissies.
Daarmee kun je, met de rechten van de gebruiker waaronder de mysql-daemon draait, bestanden wegschrijven op locaties waar deze rechten op heeft.

Dit is gewoon een gevaarlijke functie die, indien je hem toch wilt gebruiken, goed geconfigureerd moet worden.

Dat root-toegang wordt verkregen is ook niet altijd waar; enkel wanneer mysqld draait onder root of vergelijkbare rechten heeft, is dit via deze weg te bemachtigen.

Working as intended; het is niet de taak van mysql te voorkomen dat de user zichzelf in de voet schiet. Het is de taak mr bullet zo snel en efficient mogelijk af te leveren in mr. voet wanneer de gebruiker dat wenst. Bij deze dus!
Mijn MySQL server is sowieso alleen bereikbaar vanaf 127.0.0.1 (en ::1) dus zijn nauwelijks vatbaar. Remote inloggen doe ik dan via SSH, en inloggen daarop gaat weer met een certificaat. Knappe jongen die daar in komt.

Nee, niet waterdicht, maar wel heul erg waterafstotend :)
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]

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.
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]

Op dit item kan niet meer gereageerd worden.