Beveiligingsprobleem MySQL geeft gebruiker root-toegang
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?
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?
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
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.
Nouja, jij mag 't ook op je productiedatabase proberen...
Mja, de forks komen niet voor niks als paddestoelen uit de grond.
Itt java is dit opensource tho'. De linux distributeurs selecteren zelf wel een patch die het lek dicht, of die nou van Oracle komt of niet.
Itt java is dit opensource tho'. De linux distributeurs selecteren zelf wel een patch die het lek dicht, of die nou van Oracle komt of niet.
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 maandag 3 december 2012 19:39]
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.
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.
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.
'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 maandag 3 december 2012 12:01]
"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?).
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?).
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.
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.
SSH kan anders ook port forwarding en SOCKS proxy. Gebruik het zelf genoeg, handiger dan de zoveelste VPN client 
.
.
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
Edit: Oh ik zeg nu precies hetzelfde als .oisyn hieronder
[Reactie gewijzigd door Rutix op maandag 3 december 2012 12:36]
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.Direct wil zeggen dat je de MySQL server direct aanspreekt
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!!)
(heb even gekeken en ja: http://docs.oracle.com/cd.../ol_about_containers.html je kan het dus gewoon allemaal in een cointainer duwen!!)
Het is nu een perl script wat je uit moet voeren maar ik zie niets wat niet in PHP gedaan kan worden.
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.Als ik het goed heb kun je bij meeste hosting bedrijven niet direct op de MySQL-server inloggen van buiten het netwerk
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.ik neem aan dat dit om een soort van command-line gaat, die je niet kan benaderen vanuit bijvoorbeeld PHP scripts?
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 maandag 3 december 2012 12:54]
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:
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..
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:
Die regel specificeert van wie het object is en daarmee onder welke rechten het draait.CREATE DEFINER=`root`@`localhost
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..
Bedankt, je maakt precies duidelijk wat ik miste in het artikel; dat het inderdaad om de root -database- gebruiker gaat, en niet de systeemaccount. Sowieso draait de MySQL server als het goed is niet onder je root account, alhoewel ik niet weet hoe Red Hat dat standaard heeft ingericht. Onder Debian is er in ieder geval een aparte mysql user voor, zoals bij de meeste 'grote' daemons.
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".
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).
- "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).
"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.
Alleen kan Red Hat dat niet, omdat zij het systeem niet beheren.
Ze kunnen dat inderdaad niet. Ze hebben wel een entry ingeschoten die nu gereviewed moet worden door de CVE Editorial Board.
Bovendien wordt in het artikel nu ten onrechte nu de suggstie gewekt dat het krijgen van een CVE nummer iets te maken heeft met hoe ernstig een lek is.
Echter CVE-nummer worden ook uitgedeeld voor relatief minder gevaarlijke lekken.
CVE kent namelijk ook een rating van 1-10 die de ernst aangeeft van het lek.
Echter CVE-nummer worden ook uitgedeeld voor relatief minder gevaarlijke lekken.
CVE kent namelijk ook een rating van 1-10 die de ernst aangeeft van het lek.
Op http://seclists.org/fulldisclosure/2012/Dec/36 staat wat er gebeurd is:
En dus heeft Red Hat onder de tijdsdruk weldegelijk een CVE-nummer aan de kwetsbaarheid gekoppeld.However in this case we have a bit of a time constraint (it's a weekend and this is blowing up quickly) and the impacts are potentially quite severe. So I've spoken with some other Red Hat SRT members and we feel it is best to get CVE #'s assigned for these issues quickly so we can refer to them properly.
[..]
Please use CVE-2012-5613 for MySQL (Linux) Database Privilege Elevation Zeroday Exploit
[Reactie gewijzigd door GlowMouse op maandag 3 december 2012 14:43]
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.
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 maandag 3 december 2012 12:18]
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).
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.
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 maandag 3 december 2012 21:48]
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 maandag 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!
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?
- 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.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht Galaxy S
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
