Drupal har kritisk SQL-sårbarhed

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.

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.

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Uffe Seerup

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.

  • 3
  • 0
#4 Jari Wiklund

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.

  • 0
  • 0
#5 Peter Makholm Blogger

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.

  • 3
  • 0
#6 Jari Wiklund

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.

  • 0
  • 0
#7 Uffe Seerup

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.

  • 2
  • 0
#8 Rune Larsen

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

  • 0
  • 2
#9 Peter Makholm Blogger

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

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

  • 1
  • 1
Log ind eller Opret konto for at kommentere