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 , , 51 reacties, 27.739 views •

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
(Java is ook open source via OpenJDK)
@Biinjo: Je hebt gelijk, ik had net zo goed de host wel kunnen noemen want daar kom je inderdaad gemakkelijk achter. Maar mijn website gebruikt geen database en trekt weinig bezoekers, dus ik maak me er niet heel druk om.
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?
Port 1433 toch ? Staat me iets van bij van vroeger
Toen was er ook een hack
Offtopic; @Blaise

Wel een volledig ingevuld profiel op internet plaatsen, maar 'voor de zekerheid' niet de naam van je hosting provider noemen gaat niet goed samen. 1 whois op je domein vertelt genoeg.
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
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.
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?
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!
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.
Tenzij de SSH deamon niet draait op de MySQL-server.
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.
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.
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.
Patch zal wel even duren gezien de trend van Oracle :)
Het staat Oracle altijd vrij om een patch te gebruiken van de fork.

Een fork creŽer je als je het niet eens bent met de richting van het origineel. maar niets weerhoudt de forks ervan om vervolgens leentjebuur bij elkaar te spelen.

Verder heeft geld verdienen met open source geen enkel verband met een open source gedachte. Open source is vrij, niet per definitie gratis. je zou verwachten dat dat nu toch wel bekend was.
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]

Niet al te beste opname, maar inderdaad is het resultaat tamelijk pijnlijk.
Als je in de gedachte van opensource zou willen handelen, dan zou je als je een patch hebt deze aan de MySQL community aanbieden en niet fork uitbrengen voor je eigen gewin.

[Reactie gewijzigd door Cobalt op 3 december 2012 19:39]

Ja maar hoe is dat dan ingericht? Aangezien het shared virtual hosting is??: Zou kunnen dat ze LXC hebben met beperkte rechten? (opvolger van chrootjails onder Unix) Weet ook niet of je dan Mysql hebt draaien in 1 container of meerdere containers op KVM. Het opzetten daarvan is een heel gedoe maar uiteindelijk ben je minder kwijt aan beveiliging en onderhoud (je kloont gewoon de containers) En dan kunnen mensen maar beperkt ui hun containers. Natuurlijk kun je dan totaal de zooi verkloten door de database om zeep te helpen maar dat is het dan ook. Aangezien uit een chrootjail breken wel kan maar met LXC toch een stuk moeilijker is!

(heb even gekeken en ja: http://docs.oracle.com/cd.../ol_about_containers.html je kan het dus gewoon allemaal in een cointainer duwen!!)

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