Drupal har kritisk SQL-sårbarhed

16. oktober 2014 kl. 09:0911
Drupal har kritisk SQL-sårbarhed
Illustration: Drupal.
Der er fundet en yderst kritisk SQL-injektion sårbarhed i det populære CMS, som gør det muligt for en person, fra eksternt ståsted, at kompromittere sårbare installationer.
person
Christian Bartels
Journalist
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.
person
Christian Bartels
Journalist

Sårbarheder, sikkerhedshuller er der nok af. Nu der fundet flere af slagsen i et system, som mange af de store websites bruger.

Sikkerhedsfirmaet CSIS har onsdag morgen fundet endnu en sårbarhed i et stort og omfattende system. Et af de mest udbredte og populære CMS (Content Management Systemer) er ramt af en yderst kritisk svaghed, som gør det muligt for en anonym angriber at overtage kontrollen med webserveren.

Derfor bør alle Drupal-installationer med det samme opgraderes til version 7.32, skriver CSIS Security Group på deres hjemmeside.

Angiveligt bruger op mod 12 procent af verdens 100.000 største hjemmesider Drupal som kernen i deres system. CSIS råder derfor, som før nævnt, til at man med det samme opdaterer til version 7.32 af Drupal og hvis dette, af forskellige årsager og hensyn, ikke er en mulighed, er der publiceret et patch som kan hentes her, skriver CSIS på deres hjemmeside.

Artiklen fortsætter efter annoncen

Den tekniske del af fejlen skriver CSIS om sådan her:

»Sårbarheden introduceres i et database abstraction API, som ironisk nok skal sikre, at forespørgsler mod databasen bliver saniteret for at forhindre SQL-injektion. Igennem netop dette API er det muligt for en angriber at sende særligt udformede anmodninger, som kan resultere i arbitrær SQL-eksekvering. Angreb kan føre til rettighedseskalering, arbitrær PHP eksekvering m.v. Resultatet, er som før nævnt, kompromittering af webserveren.«

»Den pågældende sårbarhed har fået tildelt CVE-ID: CVE-2014-3704 og berører alle versioner af Drupal fra version 7.0 og tidligere end version 7.32. Drupal regner også med at frigive en opdatering til Drupal 6 core, men det er uvist om det er relateret,« skriver CSIS på deres hjemmeside.

11 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Køb abonnementFå prøveabonnement

Jobs

Dine job
Vis alle

Fortsæt din læsning

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
10
Dennis Nielsen
19. oktober 2014 kl. 22:57

Som om at der aldrig er blevet SQL injected i andre sprog før. Eller i andre store løsninger som ikke er bygget i PHP. ;)

  • more_vert
    • insert_linkKopier link
8
Rune Larsen
18. oktober 2014 kl. 11:06

Abstraktionen, at arrays er en afart af hashtables, kan være funktionelt korrekt, men holder ikke sikkerhedsmæssigt. Man er vant til, at et array ikke kan have arbitrære nøgler og derfor er imun overfor nøgle-injektioner. Når man bruger den slags "genveje", som python har gjort her, bør man være meget grundig med at forklare, hvor abstraktionen IKKE holder vand ift. non-funktionelle aspekter, som sikkerhed, skalerbarhed og fejlisolering. Det er her, python har fejlet som platform med konsekvens for Drupal og sikkert mange andre systemer. https://docs.python.org/3/library/array.html

  • more_vert
    • insert_linkKopier link
9
Peter Makholm
18. oktober 2014 kl. 13:56

Det er her, python har fejlet som platform med konsekvens for Drupal og sikkert mange andre systemer. <a href="https://docs.python.org/3/library/array.html">https://docs.python.org/3…;

Drupal er ikke skrevet i Python men i PHP.

Python har både rigtige arrays og rigtige hashtables så udvikleren vil kunne vælge den datastruktur der passer med intentionen. Derfor er det langt mindre sansynligt at fejlen ville have været opstået hvis Drupal var skrevet i Python (eller stort set et vilkårligt andet sprog).

  • more_vert
    • insert_linkKopier link
3
Uffe Seerup
16. oktober 2014 kl. 15:34

Fejlen er i et modul som (ironisk nok) lige netop havde til formål at forhindre SQL injections.

Når man ser koden, ser det umiddelbart også fornuftigt nok ud.

Men PHPs designere har i deres visdom (og modsat alle andre sprog jeg kender) besluttet, at arrays jo "bare er hashtables med numeriske nøgler". Så i PHP er en hashtable og et array den samme datastruktur.

Og dét er netop hvad der overraskede udviklerne af dette Drupal modul: Når det "array" som blev sendt over med SQL parametre faktisk havde ikke-numeriske nøgler (men derimod PHP og/eller SQL kode som nøgler) så blev nøglerne bagt ind i det resulterende udtryk.

Så ja, det er en fejl i Drupal - men det er nok engang en besynderlig PHP design-beslutning som har lagt fælden.

  • more_vert
    • insert_linkKopier link
4
Jari Wiklund
17. oktober 2014 kl. 10:41

Konsekvensen af det du siger er vel at alle programmeringssprog er dårligt designede, med mindre sproget umuliggør hashtables. Det har ikke noget med php som sådan at gøre, men mere den kultur omkring php som alt for ofte bruger hashtables i alle mulige uhensigtsmæssige sammenhænge. Man kan synes hvad man vil om svagt typede sprog som PHP, det kræver mere disciplin fordi man ikke blindt kan stole på typen, som denne fejl som jeg læser det, er en konsekvens af. Drupal udviklerne kunne have valgt (og bevæger sig vist i den retning med v. 8) at være mere stærkt typet, men det er ikke/har ikke været kulturen i (php)communitiet. Så jeg læser det som en konsekvens af en udisciplineret kultur omkring et svagt typet sprog, mere end at det kan lægges svag typing generelt til last.

  • more_vert
    • insert_linkKopier link
5
Peter Makholm
17. oktober 2014 kl. 11:08

Konsekvensen af det du siger er vel at alle programmeringssprog er dårligt designede, med mindre sproget umuliggør hashtables.

Nej.

Der er et helt specielt problem med PHP på grund af sammenhængen mellem hashtables og arrays. Det kan godt være at man som udvikler har intention om at bruge en hashtable, men hvis man tilfældigvis kun har numeriske nøgler, så vil PHP i visse tilfælde opfatte det som et (sparse) array. Det betyder blandt andet at man i nogle tilfælde kan opleve at nøglerne bliver smidt væk og erstattet af fortløbende indicer. (Heldigvis for lang tid siden jeg har kodet PHP til at kunne huske den use-case hvor det bed mig)

Jeg kender ikke til andre sprog der har en lignede sammenhæng mellem disse to typer datastrukture.

Skal dog tilstå at jeg ikke har sat mig ind i den aktuelle sårbarhed. Jeg kan kun uddybe på Uffes beskrivelse.

  • more_vert
    • insert_linkKopier link
6
Jari Wiklund
17. oktober 2014 kl. 13:57

Det er jo netop et der er problemet, man har i dette tilfælde blindt stolet på at det var et (sparse) array, men programmeret som om det var et hashtable (man bruger foreach i stedet for en for). Det er for mig at se dog ikke det største problem i denne sammenhæng, for selvom man havde programmeret netop denne funktion til at tage en type som fx SplDoublyLinkedList som parameter, eller System.Collection.Hashtable, hvis vi taler C#, ændrer det jo ikke ved det grundlæggende problem, at key-værdien i den pågældende situation, åbenbart er brugerpåvirkelig og sidenhen påvirker SQL statementet.

  • more_vert
    • insert_linkKopier link
7
Uffe Seerup
17. oktober 2014 kl. 23:40

Det er jo netop et der er problemet, man har i dette tilfælde blindt stolet på at det var et (sparse) array, men programmeret som om det var et hashtable (man bruger foreach i stedet for en for).

Ja, og det er også derfor at det (formelt) er en fejl i Drupal.

Men min pointe er, at Drupal-udviklerne bliver vildledt af PHP - fordi hashtable og array er den samme datastruktur i PHP. Sjældent (hvis nogensinde?) er du interesseret i at udnytte denne dobbelte personlighed. Som udvikler tænker du enten array (nøglerne er underforstået numeriske) eller hashtable (du tager selv ansvar for nøglerne).

Mentalt har udviklerne her brugt et "array". Men de har i realiteten kun brugt arraypersonligheden fra PHPs besynderligt sammenblandede datastruktur. Det er bare ikke inde på lystavlen - for man bruger aldrig begge personligheder sammen.

Og pludselig stikker en anden personlighed hovedet frem: "Ha ha - dine array indexes (hvad de fleste ville forvente er numeriske værdier) er slet numeriske, for dit array er slet ikke et array men en hashtable!"

Et programmeringssprog - specielt et web-orienteret sprog - bør gøre det sikre nemt og det farlige besværligt. Her fejler PHP igen og igen.

Og særligt når man opfinder en ny feature (her dobbelt-personlighed datastruktur) skal man være varsom, for så er der ingen historie man kan undersøge for hvordan den bliver brugt/misbrugt. Til web-programmering bør sprog-designere være en lille smule konservative og spørge sig selv: Hvorfor skulle vi lave det anderledes end alle andre? Hvad er risikoen? Hvad er gevinsten?

... eller System.Collection.Hashtable, hvis vi taler C#, ændrer det jo ikke ved det grundlæggende problem, at key-værdien i den pågældende situation, åbenbart er brugerpåvirkelig

Forkert. Netop hvis Drupal havde været skrevet i C#, Java, Ruby, Python eller lignende så ville udviklerne have brugt et array (eller Vector) - for det var dét som var intentionen i koden. Og de sprog garanterer, at der ikke pludselig er brugerpåvirkede strenge i nøgle-delen af en array datastruktur.

  • more_vert
    • insert_linkKopier link
2
Nicolaj Hansen
16. oktober 2014 kl. 13:45

Istedet for altid at fremhæve CSIS var det måske på tide at finde andre kilder, når det gælder IT-sikkerhed :)

  • more_vert
    • insert_linkKopier link
1
Arne Jørgensen
16. oktober 2014 kl. 10:13

Sikkerhedsfirmaet CSIS har onsdag morgen fundet

Nu var det godt nok ikke CSIS der fandt hullet (de har højst fundet annonceringen af hullet), men derimod SektionEins.

  • more_vert
    • insert_linkKopier link