Patch-kaos i kølvandet på Shellshock: Flere sikkerhedshuller skaber forvirring

Først var der én sårbarhed og én patch, og så blev forvirringen komplet. Efter flere uofficielle patches står vi nu med mindst fire og måske fem sårbarheder i Bash og mangler mindst to officielle patches.

Det har været en travl uge for systemadministratorer med systemer, som benytter open source-kommandofortolkeren Bash, efter at en kritisk sårbarhed blev afsløret for godt en uge siden. Adskillige opdateringer er blevet udsendt, hvorefter der er opstået tvivl om, hvorvidt de overhovedet har lukket sikkerhedshullet.

»Det har været et kæmpe kaos. Da den første sårbarhed slap ud, mente man, at patchen ikke lukkede hullet fuldstændigt,« forklarer researchchef Kasper Lindgaard fra sikkerhedsfirmaet Secunia til Version2.

Læs også: Shellshock: Linux- og Mac-systemer ramt af omfattende og alvorlig sårbarhed

Sikkerhedshullet, som har fået tilnavnet Shellshock, findes som sagt i Bash og har eksisteret i 22 år, uden at nogen har opdaget det før nu. Sikkerhedshullet vurderes af flere sikkerhedseksperter til at være et af de mest alvorlige, fordi det har givet mulighed for at overtage kontrollen med sårbare Unix-, Linux-, BSD- og Mac OS X-systemer. Ganske vist under forudsætning af bestemte konfigurationer.

Da den første patch blev frigivet, og nyheden om sikkerhedshullet slap ud i sikkerhedskredse, blev både patch og Bash gransket, og hurtigt lød meldingen, at patchen kun delvist lukkede sårbarheden.

Derfor gik udvikleren bag patchen i gang med at lave en bedre version, men i mellemtiden havde historien om Shellshock bredt sig, og flere gik i gang med at lave uofficielle sikkerhedsopdateringer, som også blev samlet og udsendt af visse Linux-distributioner.

»Nogle af disse uofficielle patches sås også at være ufuldstændige, og det viste sig, at den første patch ikke var ufuldstændig, men at man blot troede det, fordi der var et andet sikkerhedshul i Bash,« fortæller Kasper Lindgaard.

Et 22 år gammelt sikkerhedshul i denne kaliber fik flere til at lede efter sårbarheder i softwaren. Bash er open source med rødder i GNU, hvor Bash i mange år var den foretrukne kommandofortolker.

Siden den første sårbarhed blev fundet, er der fundet yderligere én anden sårbarhed, som der også er lavet en patch til. Derudover er der fundet yderligere to, som ikke er patchet endnu, og derudover er der mindst én ubekræftet sårbarhed.

»Vi forventer, at der nok dukker flere op. Efter 22 år er der én, som fandt en sårbarhed lidt ud af det blå og åbnede for Pandoras æske,« siger Kasper Lindgaard til Version2.

Læs også: Botnets kaster sig over kritisk Shellshock-sårbarhed for at shanghaje Linux-servere

Det åbenlyse spørgsmål er, hvordan et så alvorligt sikkerhedshul i et stykke software, som tusindvis af personer med forstand på it-sikkerhed har benyttet dagligt, har kunnet eksistere uopdaget så længe?

»Det er gammel kode, der er skrevet i en meget forældet stil. Der lader til at være en frygt for at pille ved noget, der er ufatteligt svært at læse og forstå. Så sikkerhedshullet har muligvis eksisteret i 20 år, men der er ikke så mange detaljer i historikken for Bash,« siger postdoc Luke Thomas Herbert, ekspert i it-sikkerhed, fra DTU Compute til Version2.

Ingen garanti for mange øjne på open source

Bash er open source, og dermed har alle i princippet kunnet se koden igennem for sikkerhedshuller. Men det forudsætter, at nogen tager sig tid til at sætte sig ned og kigge på noget kode, som umiddelbart virker, og som alle har tillid til.

»Fordi Richard Stallmans navn fra open source-verdenen er knyttet meget tæt til det, har der været den der antagelse om, at det er open source - ergo så har masser af øjne kigget på koden. Men i det her tilfælde viser det sig lige præcis igen, at det ofte ikke har været tilfældet i praksis. Det er mere, at nogen lægger mærke til en underlig effekt og så derefter dykker ned i koden og finder et sikkerhedshul,« siger Luke Thomas Herbert.

Shellshock-sårbarheden er blevet sammenlignet med Heartbleed, som ligeledes var et alvorligt sikkerhedshul i et stykke open source-software, OpenSSL, som ingen havde opdaget i fem år. At sårbarheder eksisterer i mange år, før de bliver opdaget, er dog ikke begrænset til open source-verdenen.

Læs også: Shellshock: Statsligt it-system stod pivåbent efter advarsler

Men mens det for lukket software kun er leverandøren, som kan sørge for sikkerheden, har brugerne af open source i princippet bedre muligheder for at blande sig. Heartbleed udstillede imidlertid, at selvom open source-projekter bliver brugt af multinationale milliardkoncerner som Google og Facebook, kan projekterne mangle økonomiske ressourcer til at foretage grundige sikkerhedskontroller af kode, som allerede er rullet ud.

Når sårbarhederne så dukker op, kan det også give sine helt egne problemer som i dette tilfælde med Bash, hvor der er lavet flere uofficielle patches, samtidig med at nye sårbarheder er blevet fundet, hvilket har bidraget til forvirringen omkring, hvorvidt et system var sikret mod Shellshock-sårbarheden eller ej.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (32)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Christian Bruun

"at selvom open source-projekter bliver brugt af multinationale milliardkoncerner som Google og Facebook," og staten, så vælger de pågældende organisationer at spare penge på at gennemgå koden, og stoler på at den er ufejlbarlig.

  • 4
  • 1
Lars Lundin

For det første så har f.eks. google deres 'Vulnerability Reward Program' (du kan google det).

For det andet så kan jeg love dig at kommercielle software licenser er meget forsigtige med at garantere noget som helst om hvad softwaren kan og ikke kan, og altid indeholder en meget tydelig ansvarsfraskrivelse.

Så valget af open-source er på det punkt ikke så dårligt.

Angående bash, så er dens kildetekst om ganske kort tid meget grundigt analyseret, og en række fejl rettet. Det ville ikke ske med en proprietær kildetekst.

  • 22
  • 2
Troels Henriksen

I følge hvad jeg har hørt i This Week In Tech podcast'en, er Shellshock meget mere alvorlig end Heartbleed. Og kan udnyttes af ganske almindelige "script-kiddies".

Shellshock er nemmere at udnytte, men færre systemer er sårbare, så det er lidt svært at afgøre hvad der er mest alvorligt.

Angående bash, så er dens kildetekst om ganske kort tid meget grundigt analyseret, og en række fejl rettet. Det ville ikke ske med en proprietær kildetekst.

Bash's kildetekst er ikke udpræget velskevet, hvilket besværliggør eller umuliggør en ordentlig analyse. Noget lignende gør sig gældende med OpenSSL, hvor de Kafkaeske absurditeter i koden gør det fuldstændigt i muligt for nogen at at foretage en sikkerhedsrevision - dette var netop årsagen til at OpenBSD skabte LibreSSL.

Der skal simpelthen mere fokus på kodekvalitet og reduktion af angrebsoverfladen. Mange af disse gamle programmer har virkelig rådden kode, og langt flere features end nødvendigt.

  • 9
  • 0
Thomas Andersen

Det virker kun på maskiner der har bash som systemshell, hvilket jeg tror er en mindre kritisk mængde end servere der bruger OpenSSL TLS.


Men de sagde at DHCP brugte Bash (på stort set alle unix baseret maskiner). Hvilket gjorte man kunne eksekvere Bash scripts fra DHCP svaret.

En hurtig søgning giver dette svar:
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-conc...

  • 1
  • 0
David Rechnagel Udsen

En hurtig søgning giver dette svar:
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-conc...

Lidt uprofessionelt at han ikke skriver hvilken installation DHCP-serveren kører på, og hvilken version af både dhcpd og bash han kører.

Desuden så kræver den jo at en DHCP-server kører på maskinen. Er dette tilfældet på alle OS X-installationer?

  • 2
  • 0
Martin Kofoed

Jeg forstod det nu ellers somom at det var meget mere udbredt. Bl.a skulle man kunne kompromitere en ganske almindelig OSX, bare den (OSX maskinen) sendte en DHCP forespørgsel.

Det er ikke helt korrekt. DHCP-serveren kan udføre kommandoer på sårbare klienter vha. option-flag på de DHCP-settings, der sendes tilbage til klienterne. Men det kan for så vidt også være slemt nok ...

Det er det pudsige ved Shellshock: den går begge veje. En klient kan i visse tilfælde overtage en sårbar server via http/cgi, og en server kan i visse tilfælde gøre noget ondt ved klienter.

Nøglevendingen er "i visse tilfælde". Der er en række kriterier, der skal være opfyldt, for at dette exploit kan udnyttes til at "owne" en maskine 100%. Derfor er det også ret svært at give et overslag over sårbare systemer. Det var lidt mere simpelt med Heartbleed.

Men man kan nok med ret stor sandsynlighed gå ud fra, at NSA&Friends har haft denne sårbarhed i deres arsenal i et pænt stykke tid ...

  • 4
  • 0
Jes Andersen

dhclient fra linux udstiller denne sårbarhed (kører et bat script med uverifceret input smidt direkte ind i environment variabler), men denne er mac ikke ramt af da den ikke bruger dhclient.

de fleste andre kendte opsætninger der er sårbare er noget mere eksotiske.

  • 0
  • 0
Jakob Damkjær

at nævne at Apple i går udsendte en patch der lukker hullet for 10.7, 10.8 og 10.9 (så tre versioner tilbage)...

http://appleinsider.com/articles/14/09/29/apple-releases-bash-update-to-...

og med mindre man har været inde og slå remote login specifikt til (noget som kun avancerede unix brugere har haft en årsag til at gøre) så har man ikke været udsat for nogen fare...

Så Version2 kan godt nå at nævne at OS X havde en sårbarhed men de overså lige at Apple på mindst lige så hurtig tid som Open Source miljøet har patchet deres kommercielle software.

Men det stemmer jo ikke helt overens med Version2s redaktionelle linje om at "open wins" selv om det har vist sig ikke at være helt så åbentlys en sammenhæng i denne sag. For fx. var windows aldrig sårbar overfor denne sårbarhed...

  • 1
  • 10
Jesper Lund Stocholm Blogger

For det andet så kan jeg love dig at kommercielle software licenser er meget forsigtige med at garantere noget som helst om hvad softwaren kan og ikke kan, og altid indeholder en meget tydelig ansvarsfraskrivelse.


Altså ligesom OSS-licenser normalt gør?

GNU:

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Apache:

Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

BSD:

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

MIT:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Mozilla:

Covered Software is provided under this License on an “as is” basis, without warranty of any kind, either expressed, implied, or statutory, including, without limitation, warranties that the Covered Software is free of defects, merchantable, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the Covered Software is with You. Should any Covered Software prove defective in any respect, You (not any Contributor) assume the cost of any necessary servicing, repair, or correction. This disclaimer of warranty constitutes an essential part of this License. No use of any Covered Software is authorized under this License except under this disclaimer.

  • 7
  • 11
Niklas Pedersen

Øh ja, hvad havde du ellers forestillet dig?

Skulle et open source community, der giver dig noget gratis, samtidig give dig en garanti for noget som helst? De fleste projekter er non profit, hvor skulle pengene komme fra?

Men du kan jo selvfølgelig lige fortælle hvilke kommercielle virksomheder, der laver gratis software og samtidig giver en garanti for folks data og funktioner i softwaren? :-)

  • 8
  • 2
Jakob Damkjær

"Er det mon den her historie du fisker efter version2 har overset? :)
http://www.cnet.com/news/apples-shellshock-patch-incomplete-say-experts/...;

Bare at de skrev et eller andet... I stil med "Apple har frigivet en patch til bash der fikser de mere alvorlige bugs og opfordre alle brugere til at opdatere snarest muligt"

22 ord der ville gøre at version2 kunne betragtes som et par grader mindre i "APPLE DOOOOOMMMM !!!!" Kategorien af websites... For selv om der er mange der har en voldsom frugt allergi her på sitet, så er det ikke en helt objektiv beskrivelse af virkeligheden.

Men selvfølgelig får de jo massere af pageviews ved at trolde Pro Apple siden af deres læsere som så kan agravere Anti Apple siden til at degenerere til et børnehave niveau (nej du lugter af fisk... Nej det er dig der har marmelade i håret.. Osv)... (Ikke tilfældet i den aktuelle kommentar da den indeholdt et faktisk argument eller faktuel statement)... Men nok meta kommentar for nu...

Men hvorfor demonstrere de exploitet på en gammel version af OS X (10.8) ? (Som alle Mac'er der kan køre gratis kan opdatere til 10.9)

Og det virker som om den sidste sårbarhed ikke er så alvorlig som dem der er blevet patchet i OS X...

"That vulnerability, CVE-2014-7186, is a bug that could allow for Denial of Service"

Ikke helt den sikkerheds risiko som de første bash bugs var...

Så slemme Apple de fikser de mere alvorlige huller først og det ikke helt så alvorlige lidt efter.

  • 0
  • 4
Jakob Damkjær

Bashtest...

hmm det virker som om det er alt alt for lang tid siden der har været kode review på bash.
Så lige nu er den en loot pinjata for hackere.

Selv ikke BASH 4.3 patchlevel 028, 4.2 patchleven 051 er sikret mod den seneste nye bug der er fundet...

fra github

https://github.com/hannob/bashcheck

"Latest upstream patches (4.3 patchlevel 028, 4.2 patchleven 051) now include all fixes except for the latest lcamtuf issue."

Testing /bin/bash ...
GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13)

Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Vulnerable to CVE-2014-6277 (lcamtuf bug #1) [no patch]
Not vulnerable to CVE-2014-6278 (lcamtuf bug #2)
Variable function parser inactive, likely safe from unknown parser bugs

Hvordan ser resultatet for den test ud fra en linux boks der er opdateret til BASH 4.3 patchlevel 028 ?

NB! hvis jeg husker rigtigt så var det der Sotchi hacking skandalen kun noget der var virkeligt hvis man lige klikkede på et link i en mail der så ud som om det var et link der aldrig skulle trykkes på.

Så hvis man bare lod være med at gøre horribelt dumme ting så var der ingen problemer... (dvs. klicke på suspekte links på et offentligt netværk).

Så så længe det ikke faktisk er noget der er nyheder på de lidt større websites, så er der nok ikke noget at komme efter med Apple DOOOOM vinkelen. Slå remote login fra (default setting som almindelige mennesker aldrig har noget formål at pille ved) så er der ikke en angrebs vinkel.

Desuden så er der ikke en DHCP server der køre på OS X automatisk i baggrunden, så det er heller ikke en angrebsvinkel på OS X mm der er en avanceret unix bruger der har fumlet rundt på systemet på måder de
ikke skal.

Så ja det her er mest et problem for linux servere og NAS drev med linux OS på, der ikke bliver opdaterede.

Men selv om det er muligt at gøre en OS X boks sårbar overfor et shellshock angreb ved at åbne for remote login (shell) Så kræver det at man fumler rundt med ting man ikke ved hvad er.

  • 0
  • 2
John Hansen

»Fordi Richard Stallmans navn fra open source-verdenen er knyttet meget tæt til det, har der været den der antagelse om, at det er open source - ergo så har masser af øjne kigget på koden. Men i det her tilfælde viser det sig lige præcis igen, at det ofte ikke har været tilfældet i praksis. Det er mere, at nogen lægger mærke til en underlig effekt og så derefter dykker ned i koden og finder et sikkerhedshul,« siger Luke Thomas Herbert.

Jeg ved ikke lige hvorfor Richard Stallman bliver nævnt her, da han på ingen måde vil associeres med "open source" begrebet og heller aldrig har påstået det der beskrives i citatet. Richard Stallmans er kendt for "free software" bevægelsen. I begge tilfælde er kildekoden tilgængelig, men "free software" dækker også etiske og politiske aspekter. Man kan læse mere her: http://www.gnu.org/philosophy/open-source-misses-the-point.html

Luke Thomas Herbert tænker nok på Eric S. Raymond som i sin bog "The Cathedral and the Bazaar" fra 1999 beskriver "Linus's Laws" som lyder "given enough eyeballs, all bugs are shallow".

Problemet med Shellshock og Heartbleed er at der ikke har været nok øjne. Det positive er når der kommer fokus omkring et sikkerhedshul i en applikation med åben kildekode, så er der pludselig mange øjne og der bliver fundet flere fejl.

Det er dog besynderligt med alt den dramatik omkring sikkerhedshullerne i Bash og OpenSSL, med sjove navne osv. Prøv at tænke på de utallige gange der har været alvorlige sikkerhedshuller i f.eks Adobe Flash, som er installeret på hundredvis af millioner enheder, men som overhovedet ingen opmærksomhed har fået. Det sker åbenbart så ofte at folk ikke længere gider læse om det.

  • 3
  • 0
Lars Lundin

Igår nævnte jeg i en anden tråd her at der faktisk ikke skal CGI til, en anden mulighed er en HTML side der kalder PHP's system() (på et system hvor /bin/sh er lænket til en upatchet bash).

Det ser dog heldigvis ud til at jeg tog fejl.

Hvis CGI ikke er slået til, så arver server-processen der fortolker PHP-koden ikke udefrakommende environment variable, og dermed er det ikke uden videre muligt at en shell, der er startet af system() kommer til at evaluere udefrakommende kode. (Værdien af f.eks. den udefra kommende HTTP_USER_AGENT er i PHP tilgængelig via en særlig PHP-variabel, som ikke arves af en proces, som startes med system()).

  • 0
  • 0
Lars Lundin

Hvor er det tyndt folk down-voter et 100% faktuelt indlæg.

J.L.Stockholm udelod i sit citat den væsentlige sidste linje af:

For det andet så kan jeg love dig at kommercielle software licenser er meget forsigtige med at garantere noget som helst om hvad softwaren kan og ikke kan, og altid indeholder en meget tydelig ansvarsfraskrivelse.

Så valget af open-source er på det punkt ikke så dårligt.

Den vigtige konklusion at open-source angående ansvarsfraskrivelse ikke er dårlig i forhold til kommerciel software udelod Jesper altså, selvom han netop gav sig til at skrive om ansvarsfraskrivelse i open-source.

Derfor gav jeg hans indlæg en negativ stemme.

  • 6
  • 0
Log ind eller Opret konto for at kommentere
Jobfinder Logo
Job fra Jobfinder

Call to action

Det har været en travl uge for systemadministratorer med systemer, som benytter open source-kommandofortolkeren Bash, efter at en kritisk sårbarhed blev afsløret for godt en uge siden. Adskillige opdateringer er blevet udsendt, hvorefter der er opstået tvivl om, hvorvidt de overhovedet har lukket sikkerhedshullet. »Det
har været et kæmpe kaos. Da den første sårbarhed slap ud, mente man, at patchen ikke lukkede hullet fuldstændigt,« forklarer researchchef Kasper Lindgaard fra sikkerhedsfirmaet Secunia til Version2. Læs også: Shellshock: Linux- og Mac-systemer ramt af omfattende og alvorlig sårbarhed Sikkerhedshullet, som har fået tilnavnet Shellshock, findes som sagt i Bash og har eksis...