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

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
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
Direct wil zeggen dat je de MySQL server direct aanspreekt
Leuk hoor, die semantische discussie, maar misschien moet je niet de letterlijke tekst van dit artikel gebruiken om tot een conclusie te komen, maar kijken naar waar daadwerkelijk het probleem ligt. Het gaat er uiteindelijk om dat je gewoon specifieke SQL commando's door kunt sturen naar de mysql server. Wat voor verbinding je daarvoor gebruikt is niet zo heel erg relevant.
het gaat om de database 'root' user, niet het machine root user. Je logt in met bijvoorbeeld root@localhost.

Het lijkt erop dat de 'test' user een script kan aanmaken op het filesystem, maar vervolgens direct de eigenaar kan veranderen naar 'root@localhost. Het bestand zelf is niet van root. Mysql database objecten zitten niet in een enkel binair bestand, maar staan per object ergens op het filesystem. Deze exploit maakt het mogelijk om feitelijk buiten de database om zelf een bestand aan die directory toe te voegen en mysqld heeft daar schrijf rechten, want anders kan het zelf ook geen objecten aanmaken..

Vervolgens blijkt die trigger dan onder de database root rechten te draaien. Dit is eigenlijk de boosdoener:
CREATE DEFINER=`root`@`localhost
Die regel specificeert van wie het object is en daarmee onder welke rechten het draait.

En deze exploit betreft zeer zeker alle mysql versies. Oracle kan dus niet zomaar even alle bestanden in een archive opslaan, of de manier waarop de eigenaar wordt opgeslagen veranderen. Men zou select into outfile eruit kunnen slopen, maar ook dat zal dingen kapot maken..

De oplossing is dus nog niet zo eenvoudig omdat het probleem ligt in de database structuur van mysql zelf. Als quick-fix zou Oracle in mysql een safe-mode optie kunnen doorvoeren zoals die jaren geleden ook bij PHP is doorgevoerd. In safe-mode kun je dan standaard niet select into outfile gebruiken, maar dat hangt er vanaf hoe vaak deze feature wordt gebruikt..
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".
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).
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).
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!
- 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?

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 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