Finurlig sårbarhed i Sudo: -u#-1 omgår tjek og giver root

Nu har jeg prøvet følgende på en bruger der ikke er i suders group:

mc@pracedru:~$ sudo -u#-1 nano test.txt  
sudo: unknown user: #-1  
sudo: unable to initialize policy plugin

Men som man kan se kommer følgende fejl.
Er dette fordi at denne "ikke-standardkonfiguration" ikke er installeret?

Det er kun hvis du har ændret væk fra en standart opsærning, hvor du har givet sudo tilladelse til at køre som en anden bruger, at der er et sikkerhedshul. Som jeg har forstået det.

Og har du ændret i det, så du kan bruge sudo til at gøre som en anden ikke root bruger ?

Desuden er dit system sansynligvis allerede patcet ?

Men det er da første gang i meget langt tid, jeg har set et potentielt rigtigt farligt sikkerheds i Linux.

Men sjovt at se, hvordan meget i Linux håndteres som filer.

https://www.youtube.com/watch?v=roES8iAaJEM

Desuden er dit system sansynligvis allerede patcet ?

Ja, det er meget muligt, da jeg har automatisk update af security patches.
Jeg er bare ikke helt sikker på at jeg forstår det.
For mig lyder det som om at en bruger der ikke er i suders group kan køre sudo. Men det burde jo egentlig slet ikke være muligt. Men det er jo klart at jeg ikke kan teste det på en normal distro hvis denne feature normalt ikke er slået til.

Men det er da første gang i meget langt tid, jeg har set et potentielt rigtigt farligt sikkerheds i Linux.

Denne fejl er jo rimeligt perifær, som jeg forstår det.
Der har jo været et par stykker bare i 2018. Det imponerende er hvor hurtigt de bliver patchet og rullet ud.

Men sjovt at se, hvordan meget i Linux håndteres som filer.

https://www.youtube.com/watch?v=roES8iAaJEM

"Everything is a file" er vel en af de grundlæggende features i Unix og Unix-lignende systemer: https://en.wikipedia.org/wiki/Everything_is_a_file

Er dette fordi at denne "ikke-standardkonfiguration" ikke er installeret?

Utvivlsomt. Jeg har svært ved at forestille mig at nogen har den konfiguration som er sårbar.

For at være sårbar skal man enten have tilladt en bruger at sudo'e til ALLE andre bruger-ID'er, men IKKE root, eller også skal man specifikt tillade brugeren a sudo'e til en bruger som har bruger-ID'en -1.

Det er nok ca. den sårbarhed i år som har den højeste hype/fare ratio.

Perifær???

Fejlen gør, at lige netop på systemer hvor root har forsøgt at begrænse hvad andre brugere har lov at "sudo'e" - der får alle brugere frit løb mod et tomt mål!

Hvordan er det perifært? Vi taler totalt kompromitteret system fra lokale processer. En kompromitteret browser er en lokal proces, så kombineret med en browser, mail eller anden applikationssårbarhed er det game over.

SUID/setuid og sudo er et (bevidst) hul i sikkerhedsmodellen, fordi Unix/Linux's grundlæggende sikkerhedsmodel er for simplistisk og ikke i stand til at beskrive rettigheder og begrænsninger som vi faktisk har behov for.

En sikkerhedsmodel som har indbygget, at brugeren ikke er begrænset til et fast sæt af resourcer, er en hullet sikkerhedsmodel. En setuid root utility starter en proces under angriberens kontrol, men som afvikles som root. sudo er setuid root.

Hvordan er det perifært?

Antallet af brugere med denne feature can vel tælles på en hånd.

SUID/setuid og sudo er et (bevidst) hul i sikkerhedsmodellen, fordi Unix/Linux's grundlæggende sikkerhedsmodel er for simplistisk og ikke i stand til at beskrive rettigheder og begrænsninger som vi faktisk har behov for.

Kan du ikke komme med et eksempel hvor du har behov for det?

En sikkerhedsmodel som har indbygget, at brugeren ikke er begrænset til et fast sæt af resourcer, er en hullet sikkerhedsmodel.

Men det er jo ikke det sudo gør.

Så vidt jeg husker står su (kommandoen) for Switch User.

Hvis man anvender den uden angivelse af hvilken bruger man skifter til er default at man skifter til root.

Eller er der en anden historie?

Men det er jo ikke det sudo gør.

Jo det er præcis hvad sudo gør. Når du ikke har ret til at tilgå bestemte filer, så kan du sudo'e. Når du sudo'er bliver du pludselig (effektivt) root og har adgang til filerne. Det er ikke dig, der har adgang til filerne. Du "låner" en anden brugers (roots) rettigheder og bruger dem.

Problemet er, at root har langt flere rettigheder end du behøver. Så nu er sikkerheden afhængig af, at den proces som du har startet (med dit environment) ikke indeholder fejl som gør at du kan udnytte nogle af de andre rettigheder som root har.

Det her er sådan en fejl. Når root har forsøgt at begrænse hvad andre brugere kan sudo'e (køre som root uden at give roots password), så kan angribere udnytte dette og køre hvadsomhelst som root.

sudo giver dig mulighed for at køre som root uden at kende roots password.

Fejlen optræder kun hvis root har givet Bob tilladelse til eksekvere som en anden bruger undtaget root. Bob kan så benytte det hack og blive root alligevel.

Den opsætning vil være ganske unormal.
Normalvis vil du begrænse Bob til kun at kunne køre nogle særlige programmer, fx dir som Foo og her fejlen ikke?

Enten vil man begrænse brugeren Bob til nogle udvalgte programmer eller også vil Bob have (all:all) i sudoers.

Så det bliver vidst kun en hypotestisk diskussion - og fejlen er løst.... så deee.

Jeg mener ikke at fejlen er "finurlig", det er et helt klassisk integer overflow, som ikke kan eller boer bortforklares med andet end inkompetence og manglende code reviews. Taenk hvis det havde vaeret i Windows, saa ville folk her vaere helt oppe at ringe. Det er ganske enkelt for daarligt, og et eksempel paa at UNIX/Linux's sikkerhedsmodel med en almaegtig root-user er haabloest gammeldags, hvilket sudo blot er et ynkeligt forsoeg paa at camouflere.

Jo det er præcis hvad sudo gør. Når du ikke har ret til at tilgå bestemte filer, så kan du sudo'e. Når du sudo'er bliver du pludselig (effektivt) root og har adgang til filerne. Det er ikke dig, der har adgang til filerne. Du "låner" en anden brugers (roots) rettigheder og bruger dem.

Problemet er, at root har langt flere rettigheder end du behøver. Så nu er sikkerheden afhængig af, at den proces som du har startet (med dit environment) ikke indeholder fejl som gør at du kan udnytte nogle af de andre rettigheder som root har.

Jeg er bange for at du totalt har misforstået noget.
Sudo er et værktøj til system administratoren, der gør at vedkommende ikke behøver at være permanent logget ind som root. Normale brugere er ikke i sudoers group og bør ikke være det. Hvis du har brug for rettigheder i dit virke som bruger på et Unix system bliver du givet de rettigheder som du har brug for, så du ikke har brug for sudo.

Sudo er et værktøj til system administratoren, der gør at vedkommende ikke behøver at være permanent logget ind som root

Det er måske sådan du bruger sudo. På et enkelt-bruger Linux system er der ikke meget behov for at delegere adgang.

Men hvis der er flere brugere, bliver Linuxs simplistiske sikkerhedsmodel et problem. Almindelige (ikke-administratorer) har også behov for fx at kunne udføre visse handlinger på printere.

Unix-like operating systems use a rudimentary access control system: the root account can do anything, while other users are peasants with only minimal access. This worked fine in UNIX’s youth, but today, system administration responsibilities are spread among many people and applications. Each person needs a tiny slice of root’s power.
Sudo lets you divide root’s monolithic power between the people who need it with accountability and auditability.

Taget fra beskrivelsen i bog om at "mestre" sudo: https://mwl.io/nonfiction/tools#sudo2

Til almen information så er fejlen ikke et overflow, bruger id'er kan angives både som signed og unsigned, det tillader koden eksplicit. Fejlen er alene at der ikke bliver tjekket for værdien -1, som et systemkald opfatter som en særlig værdi.

Åh, man bliver sku lidt træt når hele debatten bliver afsporet af folk der ikke fatter et hak af hvordan tingene hænger sammen.

Sudo er ikke et værktøj til at blive root, men et generelt værktøj til at køre programmer som var man en anden bruger.
Langt det almindeligste brug er dog at en administrator af et system kan køre programmer som root brugeren, root er derfor default med mindre en anden bruger angives.
/etc/sudoers er en ret kompliceret fil der kan specificere hvilke brugere/grupper der kan gøre hvad som hvem.
F.eks. indeholder sudoers følgende linjer på mit system.

# Allow members of group sudo to execute any command  
%sudo   ALL=(ALL:ALL) ALL

Min bruger er med i sudo gruppen og dermed kan jeg køre alle programmer som alle andre brugere på systemet inklusivt som root.
Det er sjældent at jeg kører ting som andet end root da root har adgang til alt anyway.

Man kan også lave mere specialiserede indstillinger såsom at brugeren Brian kan køre alle programmer som var han Ken eller Dennis.
En sær ting er dog at man kan også lave "blacklists" istedet for "whitelists" og sige at Preben kan køre programmer som enhver bruger bortset fra root.
Og det er her, og kun her at sikkerhedsproblemet ligger.
Lad os antage at følgende findes i /etc/sudoers

Preben    ALL=(ALL, !root) ALL

Hvis Preben kører "sudo ls" siger sudo fyfy det må du ikke, du kan ikke sudo'e som root, ligeledes kan han ikke sige "sudo -u root ls" eller "sudo -u '#0' ls"
Men hvis Preben skriver "sudo -u '#-1' ls" så siger sudos check at -1 ikke er brugerid'et for root og fortsætter. Dette ville normalt ikke være et problem, men setreuid som er den C funktion som sudo bruger, har en speciel feature.
Når den bliver kaldt med -1 så ændrer den IKKE bruger. Og da sudo er lavet sådan at selve programmet internt kører som root og så skifter permission ned til den ønskede bruger, så er resultatet at man forbliver som root og dermed kører Preben ls som var han root.
At 4294967295 også virker er fordi at de er ens som signed 32 bit tal. Ja det er overflow, men det er sådan set et andet problem, som formegentligt er ganske harmølst, det giver "bare" en måde mere at angive -1 på.
(Teknisk set er uid_t et unsigned 32 bit tal og man beror sig blot på det cast som Jacob påpeger)

Det store problem er at uviklerne af sudo ikke har læst 'man' siden som specifikt siger "Supplying a value of -1 for either the real or effective user ID forces the system to leave that ID unchanged." og det er vældigt dumt af dem.
Men selv om det er en meget kritisk fejl berør den formententligt kun ganske få systemer da man skal bruge den her opsætning med !root.
Der er ikke særligt mange systemer hvor det giver mening. Så kan du køre programmer som enhver på systemet inklusiv som diverse systembrugere hvor man kan fucke hele systemet op. Det er dermed en indstilling der giver ret uindskrænket adgang og som man derfor typisk kun vil give til administratorer, men hvis de skal have så omfattende adgang vil man typisk give dem adgang til at sudo'e som root, eller kun som de specifikke brugere det kræves.
Jeg tror derfor det er en feature der bruges ekstremt sjældent, og måske primært af folk der ikke har konfigureret deres system korrekt.

sudo giver dig mulighed for at køre som root uden at kende roots password.

Så du mener helt seriøst, at det er bedre at alle med behov for at lave suid opgaver ligger inde med root pwd?

Sudo er ikke et værktøj til at blive root, men et generelt værktøj til at køre programmer som var man en anden bruger.

Hvis vi skal være helt præcise så startede sudo som et værktøj til at kunne udføre kommandoer som root, og det blev senere udvidet til også at kunne køre kommandoer som andre brugere.

Og hvordan gør sudo det?

Ved først at blive root og derefter - hvis et andet uid er angivet - droppe ned som en anden bruger.

sudo er setuid root. Så snart du starter processen er processen root. Det gælder uanset om du angiver et uid du vil udføre kommandoen som. Processen starter som root - med dine environment variable. Nedgraderingen til en eventuel anden bruger sker inde i sudo, før den kører den eksterne kommando.

At lade en almindelig bruger blive root - hvor midlertidigt det end er - er et hul i sikkerhedsbarrierren som udgøres af syscalls som tjekker dinne rettigheder inden de udføres. Nu kan syscalls ikke stoppe noget som helst, for root må alt. Det gælder ikke bare for sudo, men for alle setuid root værktøjer.

Du er nu nede på at måtte stole på, at ikke bare sudo, men alle setuid root værktøjer og alle de kommandoer du lader sudo eksekvere (som ikke selv er setuid root) ikke indeholder fejl eller fx mulighed for at droppe ud til en shell.

En enkelt buffer overflow eller funktionalitet som kan misbruges og du kan nu køre fuldt som den anden bruger - som ofte er root.

Du skal med andre ord nu stole på koden - ikke på sikkerhedssystemet, for det er sat tilside af setuid root.

sudo og setuid root er Unixs helt egen version af ActiveX.

Så du mener helt seriøst, at det er bedre at alle med behov for at lave suid opgaver ligger inde med root pwd?

Nej, selvfølgelig ikke.

Jeg mener, at Linux sikkerhedsmodel skulle have været ekspressiv nok til at tildele rettigheder til de opgaver til de enkelte brugere/grupper.

sudo og setuid er kun nødvendig fordi sikkerhedsmodellen med "me-us-everybody" ikke er ekspressiv nok til almindelige rettighedsbehov.

Det er måske sådan du bruger sudo. På et enkelt-bruger Linux system er der ikke meget behov for at delegere adgang.

Kan du ikke forklare hvorfor det er smart at køre f.eks. chrome som root?
Hvad vinder jeg?

Jo der er GOD grund til ikke at køre som root på et enkelt-bruger Linux system.

Kan du ikke forklare hvorfor det er smart at køre f.eks. chrome som root?
Hvad vinder jeg?Jo der er GOD grund til ikke at køre som root på et enkelt-bruger Linux system.

Jeg har ikke givet udtryk for, at det er en god idé at køre som root - heller ikke på ey enkeltbruger system.

Jeg synes faktisk, at det er en rigtig dårlig idé. Det bryder med Principle of least privilege : https://en.wikipedia.org/wiki/Principle_of_least_privilege

Jeg er faktisk bekymret over, at almindelige brugere via setuid root værktøjer kan køre som root. Det er et netop et brud på dette princip, foruden at det er en hul i sikkerhedsbarierren som udgøres af syscall.

Jeg mener, at Linux sikkerhedsmodel skulle have været ekspressiv nok til at tildele rettigheder til de opgaver til de enkelte brugere/grupper.

sudo og setuid er kun nødvendig fordi sikkerhedsmodellen med "me-us-everybody" ikke er ekspressiv nok til almindelige rettighedsbehov.

Selvfølgelig har du ret til at have den mening, men det er noget vrøvl.

Me-us-everybody fungerer glimrende i Linux - og den tilladder netop at man kan tildeles rettigheder til de opgaver man har brug for.

Der er INTET der kræver root rettigheder som ikke hører under en system administrators domæne. Du kan lave lige hvad du har brug for i din egen 'me' kontekst - og skulle du dele system med andre, så har de heller ikke adgang til dine filer, da de har deres helt egen 'me' kontekst.

Og skulle du have brug for at dele filer med en anden bruger af systemet, så har du 'us'.

Der er ikke brug for en mere ekspressiv model sådan som Linux er opbygget. Det er på ingen måder umuligt at bruge et Linux system uden root rettigheder. Jeg har haft mange kolleger der bruger Windows gennemtiden, og ikke en af dem ville kunne udføre deres arbejde på en Windows PC uden 'admin' rettigheder (i hvert fald hvis du spørger dem selv) - og det er på trods af at Microsoft har nok så mange forskellige rettigheder man kan tildele.

Har ikke haft en eneste disktop som er blevet inficeret.

Heller ikke en bruger. Men det tror jeg mere er på grund af at alle programmer jo normalt installeret og opdateret fra et sikkert sted. Men et enkelt klik, eller hvad man nu har valgt, og de fleste gange også uden genstart.

Især er det dejligt nemt, at alt installation kun foregår ved den enkelte bruger. Så personligt data forbilver personligt og på et sted. Så skal man kun tænke på at gemme /home hvis man tage backup af person data.

Synes ikke det er mangler ved "me-us-everybody". Når us, kan være en gruppe.

Så hvis nogle brokker sig over hvordan det er bygget op, så tror jeg det må bunde i uvidenhed om hvordan et Uni* system er bygget op.

Et gammel skriv fra mig.

"Måske en mere praktisk tilgang :-)
Læste for meget længe siden en god og lang guide og dukumentation til Linux CLI.
Har glemt langt det meste, men filsystem, rettigheder, pipes, / har hængt ved.

Det har samtidigt givet mig en meget god basis for at forstå det underligende, som bruger retigheder, og filsystem. Selv om jeg næsten kun bruger et GUI.

Også på andre systemer, så jeg vil da opfordre andre til ikke kun at læse historien, men også at læse om og lærer systemet. Da det giver en basis for forståelse, som man ikke altid oplever, når man til dagligt bruger et GUI som i windows.

Så til dem som ikke er så gammel så de kender til DOS. Så synes jeg de skal lærer og læse om CLI i
Uni* Linux, det kommer også snart til windows

Igang her - Godt nok lidt gammel, men på Dansk. Andre der har bedre link.

http://www.linuxbog.dk/unix/unix/index.html

http://www.linuxbog.dk

Og video til at komme i gang med Linux.
https://www.youtube.com/watch?v=a2qblT7o4mE

Det kan en almindelig bruger heller ikke, med mindre en administrator aktivt giver mulighed for det.

Endda kan man begrænse hvad brugeren må sudo'e til, helt med på parameter niveau.

Me-us-everybody fungerer glimrende i Linux - og den tilladder netop at man kan tildeles rettigheder til de opgaver man har brug for.

Der er INTET der kræver root rettigheder som ikke hører under en system administrators domæne.

1) Hvis man har en ekstremt kritisk UNIX/Linux serverfarm med en Admingruppe på f.eks 100 personer på treholdsskift, hvordan sikrer du så at de 97 af dem kun har de nødvendige root-rettigheder til at supportere de services/serverprogrammer de er godkendt til, men ikke til alt andet? Det kunne f.eks. være ubegrænset administration af httpd, men ikke sletning af filsystem og sletning af systemlogs og backup...

2)
Kan man opbygge et hierarki af grupper, altså grupper der er med i grupper som man kan på Windows?

Der er mange forsvar for sikkerhedsmodellen i traditionel Unix/Linux her i tråden. Den er ikke uproblematisk. Sikkerhedsmodellen er et produkt af sin tid, og den er et svar på Multics som var kompliceret og ikke virkede... I mellemtiden er der løbet meget vand i åen.

1) Hvis man har en ekstremt kritisk UNIX/Linux serverfarm med en Admingruppe på f.eks 100 personer på treholdsskift, hvordan sikrer du så at de 97 af dem kun har de nødvendige root-rettigheder til at supportere de services/serverprogrammer de er godkendt til

Det kan man ikke med standard-Unix-permissions. Man kan nå noget af vejen med filsystem-acl'er, men det er svært at vedligeholde (bl.a. fordi automatisk nedarvning af rettigheder fra katalog til underkatalog til fil så vidt jeg ved ikke findes.)

For at nå hele vejen skal man bruge en udvidelse som f.eks. SELinux. Med den kan du lave en politik som ikke kan fraviges der forhindrer de 97 i at pille i andet end præcist det som de har fået rettigheder til. Det er ikke specielt sjovt at administrere, men det er i det hele taget ikke sjovt at bøvle med rettigheder.

Fordelen ved Unix-permissions i den traditionelle udgave er at de er lette at forstå og dermed har en god chance for at blive sat korrekt. At de kommer til kort på multi-service-maskiner er ikke så stort et problem i dag, for på klientsiden er ca. alle maskiner i dag enkeltbruger, og på serversiden laver man en virtuel server per service.

Det kan en almindelig bruger heller ikke, med mindre en administrator aktivt giver mulighed for det.

Nu er sudo, jo som standart, måden man afvikler root opgaver fra en normal konto i Linux.

Der findes forhåbenligt ikke en "normalt" administrator konto ud over root, på et normalt sysmtem.

Gerne supperbruger, som hvert har adgang til de service som de bruger, men ingen med genneralt root acces til hele OS.

Har jeg misforstået noget ?