Det kan ikke udnyttes eksternt uden en anden sårbarhed. Du skal allerede være i stand til at udføre kommandoer på systemet.

Et klassisk eksempel ville være en web-shell. Sig, at serveren kører en webapplikation, der har en sårbarhed, der giver dig mulighed for at uploade en web-shell eller på anden måde udføre systemkommandoer. Disse kommandoer udføres typisk som en bruger med lav privilegium, undertiden kaldet www-data eller lignende.

Med denne udnyttelse kan du overskrive filen / etc / passwd for at give www-data UID 0. Nu har www-data root-rettigheder.

Jeg prøvede dog et par ting, og ændring af / etc / passwd fungerede ikke på mit system. Du kan indstille en brugers UID til 0, men så bliver du nødt til at logge på igen, hvilket ikke rigtig er en mulighed, hvis du kun har en webshell. Den bedste våbenudnyttelse, jeg hidtil har set, overskriver / usr / bin / passwd , den binære, der bruges til at ændre en brugers adgangskode og har SUID-bit indstillet med shellcode, der udfører / bin / bash . Nogle begrænsninger ved udnyttelsen ser ud til at være: Du kan kun overskrive eksisterende byte og ikke tilføje noget til en fil. Jeg kunne heller ikke skrive mere end nøjagtigt 4KB til en fil.

Hvad angår Android, søgte jeg i Android 4.4 git repo for den pågældende funktion ( follow_page_pte ) og fik ingen hits, så jeg vil sige "nej", men citer ikke mig om det.

Rediger: Android påvirkes - se dette bevis på konceptet.

Den beskidte ko-sårbarhed er en sårbarhed med hensyn til eskalering af privilegier i Linux-kerneversioner 2.6.22 og højere; det har eksisteret siden 2007 og blev rettet den 18. oktober 2016.

Hvad er den mulige indvirkning af dirtyc0w bug?

En uprivilegeret lokal brugeren kunne bruge denne fejl til at få skriveadgang til ellers skrivebeskyttet hukommelseskortlægning og dermed øge deres privilegier på systemet.

Denne fejl tillader en hacker med en lokal systemkonto at ændre binære binære filer på disken ved at omgå standard tilladelsesmekanismer, der ville forhindre modifikation uden et passende tilladelsessæt.

Er det muligt at udnytte det eksternt?

det kan ikke fjernudnyttes direkte; du har først brug for en anden fejl for at give dig fjernadgang til systemet som bevæget @IMSoP i sin kommentar,

det er klassificeret som en vigtig fejl:

Vigtig indflydelse

Denne vurdering gives til fejl, der let kan kompromittere fortroligheden , integritet eller tilgængelighed af ressourcer. Dette er de typer sårbarheder, der gør det muligt for lokale brugere at få privilegier, tillade uautoriserede fjernbrugere at se ressourcer, der ellers burde være beskyttet af godkendelse, tillade godkendte fjernbrugere at udføre vilkårlig kode eller lade fjernbrugere forårsage en tjenestenekt.

Påvirker det Android?

Ja, fordi Android bruger Linux-kernen.

Er jeg påvirket ?

Hvis du har en enhed, der kører en Linux-kerne højere end 2.6.22, er der en god chance for, at du er sårbar. Det samme gælder for alle versioner af Android, uanset om de kommer fra Samsung, Google, Cyanogen, MIUI eller andre leverandører, fordi de endnu ikke har udstedt sikkerhedsopdateringer.

For at udnytte denne sårbarhed skal angriberen køre kode på den berørte enhed, hvilket i Android-tilfælde kan ske via Android Debug Bridge (ADB) via USB eller ved at installere en app, der gør brug af udnyttelsen.

Opdatering

En sikkerhedssøger beskriver på denne blog hvordan man udnytter fejlen eksternt

Udnyttelserne kan bruges mod webhostingudbydere, der giver shelladgang, så en kunde kan angribe andre kunder eller endda serviceadministratorer. Privilege-eskalering udnyttelser kan også kombineres med angreb, der er rettet mod andre sårbarheder. En SQL-injektionssvaghed på et websted giver f.eks. Ofte angribere mulighed for kun at køre ondsindet kode som en ikke-betroet bruger. Kombineret med en eskaleringsudnyttelse kan sådanne angreb imidlertid ofte opnå en meget eftertragtet rodstatus.

Nyttige oplysninger kan findes her:

1. Hvordan finder jeg ud af, om dit system er sårbart?
2. Hvad er listen over berørte Linux-distroer?
3. Hvordan løser jeg det?

CVE-2016-5195 er en såkaldt privilegium eskalering udnytte. Det giver dig mulighed for at hæve privilegieniveauet fra en normal Linux-bruger til root. Men privilegier eskalering udnyttelser er normalt lokale bedrifter (hvilket betyder, at de kører lokalt på en boks), hvilket betyder, at du allerede har brug for at være logget på operativsystemet.

Den offentlige udnyttelse, jeg kontrollerede, giver mulighed for at skrive filer ejes af root, som er skrivebeskyttet eller slet ikke tilgængelige for ikke-root-brugere. Dette giver dig mulighed for at overskrive administrative filer. Du kan udnytte dette til at blive rod. F.eks. du kan tilføje en linje

 hack :: 0: 0: ,,,: / home / kai: / bin / bash 

til / etc / passwd . Dette tilføjer en rodbruger uden adgangskode til feltet.

Det påvirker i det mindste Android 5.0.1 (Kernel Version 3.10.54+). Jeg prøvede lige denne kode på en enhed ved hjælp af Termux, og redigering af en fil, der ejes af root, fungerer problemfrit. Det kan jeg godt lide, fordi der ikke er nogen root tilgængelig for den enhed.

På den anden side overrasker det mig, fordi Android bruger SELinux, og jeg troede, at SELinux ville forhindre skrivning til / proc / self / mem .

Faktisk prøvede jeg bare at skrive til en fil, der ejes af en bruger kaldet sdcard , der ejer alle filer på SD kort. Termux selv har (normalt) ikke tilladelse til at skrive til SD-kortet. Når jeg prøver dirtyc0w på en sådan fil, hænger enheden bare og genstarter automatisk efter et par sekunder. Selv adb logcat udsender ikke noget under denne hang. Ikke sikker på, hvad der foregår der.

Hvor skræmmende er det?

I princippet er en eskalering af privilegier ret skræmmende, da det mere eller mindre gør al adgangskontrol meningsløs. I praksis betyder det forhåbentlig lidt. Du skal først have begrænset brugeradgang.

For servere vil det betyde, at ikke-så velholdte serversystemer, der nu kan udnyttes noget, vil være trivielt rodfæstede. Det er dog ikke sådan, at dette er den første udnyttelse af privilegier i historien.
For velholdte systemer skal virkningen være tæt på nul (de skulle ikke have været udnyttet indtil videre og skulle opdateres nu).

For alle Android-telefoner før 7.0 betyder det uheldigvis, at der er en udnyttelse, der muligvis tillader, at en ondsindet app overtager telefonen. Det er en ekstremt skræmmende tanke, men det ser ikke ud til at være sket hidtil, ellers ville der være panik, kaos og mord over hele planeten. Automatiske opdateringer vil hurtigt fjerne dette problem, og i mellemtiden skal du ikke installere nye apps (de apps, der allerede findes på din telefon i mange måneder din telefon, så de er sandsynligvis harmløs) ... problem løst.
Der er nu endnu en måde at jailbreak på din telefon (i det mindste indtil næste systemopdatering).

Det betyder naturligvis også, at nogen med fysisk adgang til din computer, og en brugerkonto kan rodfæste dit system ... men de kan lige så godt bare gribe din computer og bære den væk eller stjæle harddisken eller bruge Firewire / Thunderbolt, som dybest set er direkte hukommelsesadgang via kabel, start fra en CDROM eller ... 200 andre ting, så jeg tror ikke, det er et stort problem generelt. Det er bare endnu en ting, nogen kan gøre.

Endnu vigtigere

Da dette er den anden langvarige, højt profilerede hændelse (efter CVE-2008-0166) hvor et uden tvivl alvorligt sikkerhedsspørgsmål blev oprettet af en vedligeholder på vegne af et "hvad er jeg ligeglad med?" spørgsmål, jeg håber, at den største indvirkning dette vil have, genåbner en diskussion om ingeniørprocessen.

Det største problem med denne sårbarhed er efter min mening, at den blev identificeret og rettet i 2005 (da det kun var et teoretisk problem med lav sandsynlighed for at forekomme), men derefter vendte tilbage, fordi det forårsagede et problem på nogle IBM mainframe-serie fra begyndelsen af ​​1990'erne, som kun få mennesker nogensinde har hørt om. Hvilket ærligt talt kunne 99% af alle Linux-brugere ikke bekymre sig om mindre, og hvilket kunne have været gjort ved en systemafhængig patch / fix til bare s / 390. Men det skete ikke, og problemet forsvandt til glemsel indtil 11 år senere.

Dette svarer meget til introduktionen af ​​2008-0166, hvor nogen redigerede kode (som fungerede korrekt) uden at forstå konsekvenserne , udelukkende fordi Valgrind viste en advarsel.

Måske vil dette hjælpe med at skabe mere bevidsthed om vigtigheden af ​​vedligeholdere, der forstår, hvad de nøjagtige konsekvenser af en kodeændring er for langt størstedelen af ​​brugerne og generelt mere kritisk vurdering (med peer review?) på kodeændringer kan udvikle sig. Forhåbentlig er det.

The Guardian ser ud til at sige, at det er et JA, men det ser ud til, at det afhænger af den pågældende Android-variant:

Det gælder også for Android: mobile operativsystem påvirkes. Mens top-end Android-enheder, såsom Galaxy S7 og Pixel, modtager regelmæssige sikkerhedsopdateringer, modtager langt de fleste af de solgte Android-enheder få, om nogen, opdateringer efter salg.

Google nægtede at kommentere, men bekræftede, at Android er en af ​​de berørte Linux-distributioner. Virksomheden har udgivet en partnersikkerhedsrådgivning for at advare Android-partnere, et af trinene til disse partnere, der derefter udsteder en programrettelse.

Fejlen tillader en hacker, som kan udføre vilkårlig kode, til at skrive til hukommelse, der er "skrivebeskyttet". Linux-caches brugte ofte filer i skrivebeskyttet hukommelse. Som du gætter på, giver dette dig mulighed for at gøre ting som at ændre indholdet af en setuid-rodfil for at udføre vilkårlig kode, som en shell, som root.

Fejlen i sig selv kan ikke fjernudnyttes, da det kræver angriberen at udføre en bestemt eksekverbar oprettet af angriberen. Når vi typisk bruger ordene "fjernudnyttelse", kræver det ikke evne til at udføre vilkårlig kode.

Der er dog situationer, hvor en angriber allerede kan udføre vilkårlig kode ved design, der ikke er så indlysende. som ssh-adgang. Dette kan være årsagen til noget af forvirringen, da det måske ikke altid er indlysende, at en hacker har kodeudførelsesrettigheder. Potentielt kan delte automatiserede byggemiljøer være sårbare over for denne type udnyttelse, da de ofte tillader udvikleren at udføre vilkårlig kode. En angriber i dette scenarie kan potentielt få rodprivilegier.

Jeg føler ikke, at jeg er kvalificeret til at svare, hvis denne fejl kan udnyttes i Android. Hvis det kan udnyttes på Android, vil omfanget højst sandsynligt være begrænset til, at telefonens ejer kan "rodfæste" enheden, snarere end at en fjernangriber får kontrol over telefonen.