Ontwikkelaar vindt kwetsbaarheid in sudo-commando voor Linux

Er is een kwetsbaarheid ontdekt in de sudo-utility van Linux-besturingssystemen. Door de vulnerability kunnen gebruikers in bepaalde gevallen sudo-commando's uitvoeren, zelfs als ze daarvoor geen rechten hebben. De meeste installaties zijn niet door de fout aangetast.

De vulnerability, die de aanduiding CVE-2019-14287 meekrijgt, werd bekendgemaakt op de website van de sudo-utility en is gevonden door Joe Vennix van Apple Information Security. Bij dagelijks gebruik wordt sudo bijvoorbeeld gebruikt voor het uitvoeren van updates, en het installeren en verwijderen van programma's. De mogelijkheden van dit commando gaan echter veel verder.

Met sudo kunnen Linux-gebruikers bepaalde commando's in de terminal uitvoeren met de rechten van een superuser. Hierdoor krijgen gebruikers toegang tot het root-niveau van een Linux-installatie, waardoor ze toegang krijgen tot alle bestanden en commando's van het besturingssysteem. Gebruikers met root-access hebben hiermee de absolute controle over het systeem.

De sudo-commando's die gebruikt kunnen worden, staan in een bestand genaamd 'sudoers'. Ook wordt in dit bestand aangegeven welke gebruikers sudo-rechten hebben. Door de fout kunnen gebruikers in bepaalde gevallen deze beperkingen omzeilen door hun user id in de terminal aan te duiden als '-1' of '4294967295'. Sudo zet deze gebruikersnamen automatisch om in '0', wat de standaard-user id van de root user is. Zo krijgen gebruikers met onvoldoende rechten alsnog toegang tot de root van een systeem.

Deze fout werkt overigens alleen als gebruikers toestemming hebben om commando's namens andere users uit te voeren. Dit moet specifiek in een sudoers-bestand gezet worden. De kwetsbaarheid kan eigenlijk alleen misbruikt worden als een systeemeigenaar specifiek een sudoers-instructie heeft ingesteld voor een commando dat andere commando's kan uitvoeren, bijvoorbeeld 'vim'.

In de sudoer kan bijvoorbeeld 'myhost Bob = (ALL, !root) /usr/bin/vim' staan. In dit geval mag gebruiker Bob vim gebruiken als alle gebruikers, met uitzondering van de rootuser. Door gebruik van de kwetsbaarheid kan Bob vim wel gebruiken als de rootgebruiker. Hierdoor kan hij een root shell uitvoeren, waarna hij op het getroffen systeem alle mogelijke commando's kan gebruiken met roottoegang. Hij heeft nu de complete controle over het systeem. De gebruiker moet voordat de vulnerability te misbruiken is dus eerst toestemming hebben om het vim-commando te gebruiken namens andere users. Dit moet specifiek door de root user in een sudoers-bestand gezet worden. Op een standaardinstallatie is het exploiteren van deze kwetsbaarheid dus in bijna geen geval mogelijk, aangezien dit soort toestemmingen in de meeste Linux-distributies niet standaard worden ingesteld.

De beveiligingsfout is gedicht in sudo-versie 1.8.28, die deze week is uitgekomen en op korte termijn in vele Linux-distributies zal worden toegepast. Het team achter Ubuntu heeft de update al aan gebruikers verstrekt. In een security note laat Canonical weten hoe Ubuntu-gebruikers de sudo-versie kunnen updaten. De update verscheen onlangs ook al voor gebruikers van Arch Linux.

Reacties (69)

[GertMenkel]

De impact van zoiets lijkt me zeer beperkt. Geen enkele Linux-installer heeft de benodigde configuratieregel als default en ik kan me niet voorstellen dat je een regel als myhost Bob = (ALL, !root) /usr/bin/vim instelt.
Als je een commando als willekeurige user mag uitvoeren, kun je ook een keylogger in de .bashrc van de administrator stoppen en het password op die manier achterhalen.

Desondanks een interessante bug.

[DataGhost]

Ik kan de post op de sudo-site nog niet lezen (die zal wel platliggen onder het nieuws), maar voor zover ik het begrijp heeft het niet specifiek van doen met 'ALL' maar moet er gewoon uberhaupt een regel in staan om iets als een andere user te mogen uitvoeren. Ik heb bijvoorbeeld zo'n regel voor m'n monitoring-user, die mag een bepaald script uitvoeren als m'n signal-user. Er zullen meer scenario's zijn waarin je bepaalde semi-admins of services rechten wilt geven op een beperkte set accounts maar niet root. Voor thuisgebruikers zal dit inderdaad geen probleem zijn, maar juist op grotere bedrijfsservers verwacht ik dit.

Edit: ja, precies na het posten laadt de pagina wel, en staat er dat het alleen maar werkt als ALL als eerste genoemd is dus het verhaal gaat niet op, en ik ben kennelijk niet vulnerable

[Reactie gewijzigd door DataGhost op 23 juli 2024 14:21]

[CAPSLOCK2000]

Zoals ik het lees doet de positie van die regel er niet toe.
Volgens mij zijn de voorwaarden dat je een sudo-regel hebt met groep gebruikers waar 'root ook in zit (zoals ALL) er in én een beperking die de 'root' gebruiker uitzondert. Zonder die beperking heb je al alle rechten en heb je helemaal geen exploit nodig.

[DataGhost]

This can be used by a user with sufficient sudo privileges to run commands as root even if the Runas specification explicitly disallows root access as long as the ALL keyword is listed first in the Runas specification.

Zoals ik het verder lees gaat het erom dat je een "arbitrary UID" moet mogen meegeven, het lijkt me dat dat wordt gecheckt door "ALL". Andere groepen hebben namelijk nooit het UID -1 of 2^32-1 dus daarop zal de check falen en wordt het UID direct al gereject. Omdat root niet -1 of 2^32-1 is, wordt dat UID ook niet gereject door !root, en het gaat vervolgens mis doordat een library-functie het impliciet verandert in UID 0, na alle checks. Dus je hebt ALL wel nodig, maar niet omdat root daar toevallig ook in zit.

[CAPSLOCK2000]

De impact van zoiets lijkt me zeer beperkt. Geen enkele Linux-installer heeft de benodigde configuratieregel als default en ik kan me niet voorstellen dat je een regel als myhost Bob = (ALL, !root) /usr/bin/vim instelt.

Consumenten hebben er inderdaad weinig van te vrezen, die doen meestal niks met sudo, maar professioneel wordt het ontzettend veel gebruikt. Weliswaar zie ik het vooral gebruikt worden om toegang tot de root-account te geven en dan voegt dit gat niks toe, maar dat zijn zeker niet alle gevallen.
In een goed dichtgetimmerd systeeem wordt sudo juist gebruikt om zeer selectief toegang te geven tot een bepaalde account en/of een bepaald commando. Juist die systemen gaan last krijgen van deze bug. Die raakt dus waar het het meeste pijn doet.

Misschien is het tijd dat we sudo achter ons laten. Het was heel lang een ontzettend belangrijk middel maar inmiddels zijn er betere mogelijkheden zoals "capabilities". Dan hoeven we niet langer te vertrouwen op één enkel stuk software om de poort naar de hemel te "firewallen", maar vertrouwen we op "checkpoints" die bij iedere stap kijken of de gebruiker z'n boekje niet te buiten gaat.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 14:21]

[RJG-223]

Misschien is het tijd dat we sudo achter ons laten. Het was heel lang een ontzettend belangrijk middel maar inmiddels zijn er betere mogelijkheden zoals "capabilities".

Leuk idee. Behalve dan dat 'capabilities' niet een betere mogelijkheid is. Het is een andere mogelijkheid, met z'n eigen voordelen en, net zo belangrijk, z'n eigen nadelen.

Dan hoeven we niet langer te vertrouwen op één enkel stuk software om de poort naar de hemel te "firewallen", maar vertrouwen we op "checkpoints" die bij iedere stap kijken of de gebruiker z'n boekje niet te buiten gaat.

Dus in plaats van de simpele regel: iemand is volledig te vertrouwen, of iemand is dat niet (makkelijk te controleren), moet je een heel complex van regels opstellen over wie wanneer wel en niet te vertrouwen is. En die regels moet je begrijpen. En dan heb je nog steeds een stuk software dat de verschillende poorten naar verschillende delen van de hemel bewaakt, en de poorten tussen die verschillende delen van de hemel.

En dan zul je zien dat dat wat sommigen willen, of zelfs moeten doen, niet precies in de regeltjes gevat kan worden, zodat ze dus niet kunnen doen wat ze moeten doen, of dat ze, wellicht via een omweg, méér kunnen dan zou moeten.

Stel dat jij een eenvoudige regel hebt: sommige mensen mogen in jouw huis komen, sommige mensen mogen alleen in jouw tuin komen, en sommigen mogen helemaal niets. Dan blijkt ineens dat je ook een regel moet maken over wie al dan niet een raam open mag zetten. Maar ja, soms moeten de ramen open kunnen terwijl er ongeautoriseerde mensen in de tuin zijn. Dus komt er een regel hoe vér iedereen een raam open mag zetten. Maar de brandweer eist dat er vluchtwegen zijn (en dat vind je zelf ook wel zo veilig). Dus komt er een regel dat iedereen bij brand een raam mag openen. Maar ja, dan kan iemand in huis een lucifer aansteken. Dus komt er een regel wie al dan niet lucifers, aanstekers etc. mag meenemen naar binnen. En er komen regels over wie welke la of kast mag openen (want er kunnen lucifers in zitten). En er komen regels wat in welke kast opgeslagen moet worden (zodat niet iemand per ongeluk lucifers in de verkeerde kast legt). En er komen regels over gebruik van de keuken (kookplaat), en van electrische apparaten (kunnen brand veroorzaken). Etc. etc. etc. En ondertussen moet iedereen steeds zorgen dat ze de correcte permissies hebben, en dat ze zich aan de regels houden (o, dit mag wel in die kast, maar niet in die). Resultaat niemand wil meer in het huis wonen.

Nu is dit een fictief voorbeeld, maar het illustreert de nadelen van 'capabilities'

[CAPSLOCK2000]

Dus in plaats van de simpele regel: iemand is volledig te vertrouwen, of iemand is dat niet (makkelijk te controleren), moet je een heel complex van regels opstellen over wie wanneer wel en niet te vertrouwen is. En die regels moet je begrijpen. En dan heb je nog steeds een stuk software dat de verschillende poorten naar verschillende delen van de hemel bewaakt, en de poorten tussen die verschillende delen van de hemel.

Het hele bestaansrecht van sudo is juist dat mensen (of programma's) niet helemaal te vertrouwen zijn. Het is ook precies waar het hier fout is gegaan, bij regels voor mensen die géén root mogen worden. Je hebt dus op zich gelijk dat ingewikkelde regels niet bijdragen aan de veiligheid, maar sudo heeft daar ook al last van.

Deel van het probleem is dat we nog steeds veel werken van uit het idee dat het nodig is om van gebruiker te wisselen om bepaalde rechten te krijgen, in plaats van dat die rechten direct aan de juiste gebruiker worden gegeven. sudo probeert het een beetje te verbergen, maar uiteindelijk werk je als een andere gebruiker. Vaak, zeker in het geval van root, heb je dan meer rechten dan je echt nodig hebt.

Een ander deel van het probleem is dat sudo beschrijft hoe je iets mag doen, niet wat je mag doen. Een typisch voorbeeld is 'someuser ALL=(root) NOPASSWD: /usr/bin/vim /etc/bla.txt'.
Met deze regel krijgt de gebruiker 'someuser' toestemming om het bestand /etc/bla.txt te laten editten met de teksteditor vim. Als de gebruiker echter liever de editor 'nano' zou willen gebruiken dan mag dat niet. Daarnaast zit er een beveilingsprobleem in deze regel. Als vim eenmaal gestart is kun je gewoon een ander bestand openen en dat dan ook met root-rechten editten.
Een betere oplossing is om de gebruiker 'someuser' direct schrijfrechten te geven op het bestand /etc/bla.txt . Dan kan de gebruiker iedere denkbare editor gebruiken om het bestand te bewerken en is er geen beveiligingsprobleem.

Maar het is hier toch fout gegaan in precies dat geval: iemand die niet helemaal te vertrouwen is (anders had die persoon wel root gekregen).

[RJG-223]

Deel van het probleem is dat we nog steeds veel werken van uit het idee dat het nodig is om van gebruiker te wisselen om bepaalde rechten te krijgen, in plaats van dat die rechten direct aan de juiste gebruiker worden gegeven. sudo probeert het een beetje te verbergen, maar uiteindelijk werk je als een andere gebruiker.

Verwar 'makkelijker in het gebruik' en/of 'intuïtiever' niet met 'beter'.

Het wisselen van gebruiker, of nauwkeuriger: het (met een expliciete handeling) wisselen tussen verschillende rollen die een gebruiker kan hebben, is niet een probleem. Integendeel: het is juist een (security)probleem als een gebruiker continu, zonder drempel, over alle speciale rechten die hij meestal niet nodig heeft kan beschikken. Het is alsof je als politieman continu met getrokken pistool rondloopt, vinger op de trekker. Héél onverstandig.

Zie ook bijv. dit artikel over het principe van 'least privilege'

Op Linux/Unix zijn die verschillende rollen van een gebruiker geïmplementeerd als verschillende accounts. Dat had ook anders gekund, maar ja, het is nu niet anders. En een andere manier was wellicht complexer geweest, en dat heeft ook weer nadelen.

Vaak, zeker in het geval van root, heb je dan meer rechten dan je echt nodig hebt.

In de praktijk heb je direct (omdat je met het permissiesysteem de gewenste permissies niet exact kunt toekennen, en je dus meer permissies toekent) of indirect (omdat de benodigde permissies in combinatie met elkaar meer mogelijk maken dan zou moeten) vaak meer rechten dan je zou moeten hebben. In dat geval kun je dat beter expliciet maken (door de root-rechten die de gebruiker toch al kan krijgen ook expliciet toe te kennen), dan dat je een permissiesysteem optuigt wat de illusie geeft dat sommige gebruikers slechts beperkte rechten hebben, terwijl ze in feite (via een omweg) toch root-rechten hebben. Natuurlijk is het niet altijd zo, maar je moet héél goed weten wat je doet, om iemand niet onbedoeld meer rechten te geven dan gewenst.

[CAPSLOCK2000]

Verwar 'makkelijker in het gebruik' en/of 'intuïtiever' niet met 'beter'.

Het wisselen van gebruiker, of nauwkeuriger: het (met een expliciete handeling) wisselen tussen verschillende rollen die een gebruiker kan hebben, is niet een probleem. Integendeel: het is juist een (security)probleem als een gebruiker continu, zonder drempel, over alle speciale rechten die hij meestal niet nodig heeft kan beschikken.

Daar zijn we het zeker over eens, maar user accounts zijn niet de juiste manier om het te doen. Ik heb geen bezwaar tegen het wisselen van rollen. Ik maak bezwaar tegen het wisselen van identiteit. Een ander aspect van veiligheid is namelijk "accountability", de mogelijkheid om te zien wie er wat heeft gedaan. Dat raak je snel kwijt als meerdere gebruikers dezelfde account delen.

Op Linux/Unix zijn die verschillende rollen van een gebruiker geïmplementeerd als verschillende accounts.

Mijn bezwaar is nu net dat we met user-accounts blijven rommelen in plaats van echte rollen te gebruiken. Het zou al beter zijn als we per gebruiker meerdere accounts aanmaken, eentje voor iedere rol, maar dat loopt al snel uit de hand als je meerdere rollen wil combineren.

Dat had ook anders gekund, maar ja, het is nu niet anders.

Maar het is wél anders.
Linux (de kernel) heeft een flexibel security-model dat verschillende vormen van beveiliging kan implementeren. Alles wat we nodig hebben voor RBAC (of een ander modern beveiligingssysteem) is al lang en breed aanwezig, we gebruiken het alleen nauwelijks. 20 jaar geleden was men er al mee bezig en we zijn eigenlijk geen stap verder gekomen sindsdien.
Er zijn verschillende RBAC-systemen voor Linux (zoals grsecurity en RSBAC) maar vrijwel niemand gebruikt ze.

En een andere manier was wellicht complexer geweest, en dat heeft ook weer nadelen.

Daar hoeven we niet over te speculeren want die systemen zijn er. En ze zijn inderdaad comlexer dan de traditionele Unix-rechten + sudo maar ze kunnen ook veel nauwkeuriger. Als de tools te complex zijn moeten we misschien werken aan een betere interface of front-end.

Ik vind het traditionele systeem overigens helemaal niet makkelijk, zeker niet voor niet-technische gebruikers. Als je niet met octale getallen en bitmasks kan rekenen dan houdt het eigenlijk al op. Ik ken niemand die uit z'n hoofd kan uitleggen wat alle implicaties van de SETGID-, SETUID- en STICKY-bits zijn. En wat het betekent als een directory de EXECUTE-bit heeft is volkomen onlogisch.
Om het maar niet te hebben over de notatie-hacks die chmod toevoegd, zoals 'dubbele nul'-notatie.

In de praktijk heb je direct (omdat je met het permissiesysteem de gewenste permissies niet exact kunt toekennen, en je dus meer permissies toekent) of indirect (omdat de benodigde permissies in combinatie met elkaar meer mogelijk maken dan zou moeten) vaak meer rechten dan je zou moeten hebben.

Ten eerste zijn direct gevolgen van het verouderde model dat we nu gebruiken. Die problemen verdwijnen grotendeels als je een moderner model gebruikt waarbij je de gewenste permissies wel exact kan toekennen.

Sterker nog, de meeste van die problemen zijn nu al niet nodig, maar ontstaan omdat mensen het huidige security-model te complex vinden. In vrijwel alle gevallen is er ook met de traditionele tools een oplossing nodig waarbij het niet nodig is om root te worden. Overigens had ik het in mijn eerste post over dit onderwerp niet zo zeer over RBAC als wel over het gebruik van 'capabilities'. Die capabilities zijn de oplossing voor de meeste problemen waar je voorheen root voor moest hebben.

Kun jij een praktisch voorbeeld bedenken waarin het noodzakelijk is om root te worden omdat je het niet kan oplossen met unix-rechten, capabilities en misschien ACL's (nog zo'n feature die al 20 jaar genegeerd wordt door de Linux-community maar gewoon aanwezig is)?

In dat geval kun je dat beter expliciet maken (door de root-rechten die de gebruiker toch al kan krijgen ook expliciet toe te kennen), dan dat je een permissiesysteem optuigt wat de illusie geeft dat sommige gebruikers slechts beperkte rechten hebben, terwijl ze in feite (via een omweg) toch root-rechten hebben.

Waarom is dat beter?
Ik hoor dit wel vaker en meestal is de aanname dat mensen dan rekening houden met de gevaren. De mensen die het systeem niet snappen die zijn ook niet in staat om de gevolgen en gevaren te overzien. Ik heb dan liever een middel dat in 90% van de gevallen prima werkt of foutjes te voorkomen, zelfs als het niet werkt tegen een gericht aanval of grote onhandigheid. Net zoals het slot op mijn voordeur niet helpt tegen een inbreker die echt binnen wil, maar wel voorkomt dat de dronkjen buurman per ongeluk binnen wandelt.

Geen enkel beveiligingssysteem is perfect. Je kan van ieder systeem zeggen dat het een "illusie van veiligheid" geeft, meestal wordt dan met de term "schijnveiligheid" geschermd. Maar dat kun je over alle systemen zeggen. Gordels in de auto? Geen 100% oplossing => schijnveiligheid. Stoplichten? Geen 100% oplossing => schijnveiligheid. Slot op je voordeur? Geen 100% oplossing => schijnveiligheid. Gewapende bewaker voor de deur? Geen 100% oplossing => schijnveiligheid. Pincode? Geen 100% oplossing => schijnveiligheid. Vingerafdruk? Geen 100% oplossing => schijnveiligheid.

Veiligheid krijg je door beveilingssystemen te combineren tot je het gewenste niveau hebt bereikt.

Natuurlijk is het niet altijd zo, maar je moet héél goed weten wat je doet, om iemand niet onbedoeld meer rechten te geven dan gewenst.

Dat zie ik als falen van het systeem. We houden een systeem uit de jaren 70 in stand toen iedere bit duur was en iedere gebruiker hoog opgeleid. In de jaren 90 vonden we het al ouderwets en onhandig, maar sindsdien heeft het een soort cult-status gekregen waardoor we nu doen alsof het zo'n ontzettend slim en geavanceerd systeem is, terwijl het in mijn ogen een pijnlijk compromis is tussen beperkingen van een halve eeuw geleden.

sudo en unix-rechten zijn simpel voor simpele problemen maar een drama voor complexere problemen.

[zenlord]

Akkoord, maar sudo is nu eenmaal niet zo eenvoudig om correct te configureren - ik zou verwachten dat een sysadmin/devop die een sudo-regel instelt ook wel even een kleine test uitvoert ($ sudo -k -u root /usr/bin/vim)...

ik ben al twee keer beginnen studeren op dit topic, en als ik mij niet vergis, vermeldde het handboek wel al dat je door sudo-rechten te geven aan een gebruiker om een teksteditor uit te voeren als een andere gebruiker, je het systeem compromitteerde... (ik kan het ook verkeerd hebben - er is een reden waarom ik er de eerste keer niet in slaagde om het boek uit te lezen )

[goarilla]

Inderdaad veel editors laten shell escapes toe (! in vim). Als we even de manuel van sudoers
erbij halen zien we dat er een hele paragraaf gewijd is aan "Preventing shell escapes" gevolgd door "Secure Editing".

Ik zou graag weleens horen van een use case waar een user commando's mag uitvoeren als eender welke user behalve root ?

[Tozz]

Niet zo moeilijk toch? Een backup proces dat draait als user 'backup' kunnen starten.
Of bijvoorbeeld 'barman' voor PostgreSQL backups.

Of meer applicatie specifiek.. Een webserver die draait als www-data en je wil dat de webmaster bij die bestanden kan (nou komt dit specifieke voorbeeld niet zo veel meer voor, maargoed).

Een printer beheerder die je misschien rechten wilgeven tot lpd/lpr/cups.

[goarilla]

Ja maar je zou toch eerder dit doen:
%printeradmin (printservers) = (lpr,cupsd) ALL
dan alles buiten root toe te laten.

[CurlyMo]

Daar hebben we tegenwoordig (net als in Windows) gewoon ACL's voor waarmee je heel precies op gebruikersniveau kan bepalen wie wat wel en niet mag.

[RJG-223]

Ik zou graag weleens horen van een use case waar een user commando's mag uitvoeren als eender welke user behalve root ?

Kan ik me ook niet voorstellen. Behalve als je als beheerder vanuit je normale account wel makkelijk véél wil kunnen doen, maar van waaruit je niet zonder een extra drempel (wachtwoord) root rechten wilt kunnen krijgen.

[Tozz]

Dat is toch niet meer dan logisch? Als je een editor kunt openen als root, dan kun je daarmee vervolgens elke file openen. Waaronder bv. /etc/shadow. Of /etc/sudoers

Dan kun je met die editor jezelf dus meer toegang verschaffen dan alleen de editor.

[RJG-223]

Niet alleen dat. Maar een editor kan meestal ook weer externe programma's uitvoeren (bijvoorbeeld om een externe bewerking op de tekstfile te doen). Een krachtige editor stelt je natuurlijk in staat om elke mogelijke externe bewerking uit te voeren. Je kunt dan dus ook een command shell starten, en daarmee kun je alles.

En voor de mensen die denken dat je die specifieke mogelijkheid dan 'gewoon' moet uitschakelen: dat is in de praktijk onmogelijk, tenzij je genoegen wil nemen met een zwaar gekortwiekte editor. En dat wil je nu ook weer niet.

[DaaNMageDDoN]

Ipv de editor als root te draaien is het ook een betere practice on de bestanden die aangepast moeten worden van de juiste security attributes te voorzien. Groep ownership erop, groep mag aanpassen, gebruiker in groep, done. Denk dat het editor voorbeeld juist een hele praktische maar zeer gevaarlijke is.

[RJG-223]

Ipv de editor als root te draaien is het ook een betere practice on de bestanden die aangepast moeten worden van de juiste security attributes te voorzien. Groep ownership erop, groep mag aanpassen, gebruiker in groep, done. Denk dat het editor voorbeeld juist een hele praktische maar zeer gevaarlijke is.

Sommige dingen moeten nu eenmaal wel als root. Niet alles is op te lossen met een groep.

Afgezien daarvan: daar gaat het hier niet om. Het gaat erom dat als je als root een editor op kunt starten (zelfs als zou dat geen goede 'practise' zijn), je ook volledige root rechten kunt krijgen, op de een of andere manier. Tenzij die editor speciaal beperkt is in z'n mogelijkheden. Maar omdat in dit geval het niet de bedoeling was om root te worden, was de beperkte editor ook niet gebruikt. En dus kun je root rechten verkrijgen.

[DaaNMageDDoN]

Ah sorry ik was al in gedachten afgedwaald en was me meer aan het afvragen waarom je iemand toch in staat zou stellen om een editor als root te laten aftrappen. Komt een beetje door de reacties hierboven. Dat deze exploit/bug er voor zorgt dat bij dat voorbeeld juist root expliciet niet zou moeten kunnen, maar toch kan is natuurlijk waar het hier over gaat, niet wat voor een domme constructie iemand zou kunnen bedenken om een "poweruser" in staat te stellen bestanden aan te passen waar die normaal gesproken niet bij kan, ik snap je reactie!
Ben nu wel benieuwd, je hebt er denk ik meer kaas van gegeten, stel we draven door op het scenario: poweruser mag geen root rechten hebben maar moet wel bepaalde bestanden kunnen editen die ownership root hebben, laten we zeggen wat /etc config files, waarom zou een groep dan niet werken? Zelf kan ik bedenken dat sommige applicaties niet accepteren dat als hun config bestanden niet root owned zijn dat ze dan weigeren die in te lezen, maar group ownership ook of waar doel je op? Zijn er betere oplossingen voor een dergelijk scenario?

[Kewne]

Je kunt ook gebruik maken van sudoedit, een standaard onderdeel van sudo. Deze maakt een kopie van het bestand, start een editor als je reguliere user account en vervangt het originele bestand daarna met de kopie. Al deze dingen worden met correcte permissies gedaan zodat het bestand niet kan lekken en je behoud toch alle voordelen van sudo (instelbaarheid + audit trail bv). Omdat de editor onder je gewone account draait heb je dus ook volle mogelijkheden.

[MSalters]

Zoals je terecht zegt: in een dichtgetimemrd systeem wordt sudoers selectief gebruikt. Dus niet met (ALL, !root). Dat is belachelijk breed. Het sudo idee stamt uit de begintijd van Unix, en toen was "ALL, !root" nog niet zo'n heel gekke gedachte. Tegenwoordig weten we beter en specificeren we toestemmingen precies.

[RoestVrijStaal]

[...]
Misschien is het tijd dat we sudo achter ons laten. Het was heel lang een ontzettend belangrijk middel maar inmiddels zijn er betere mogelijkheden zoals "capabilities". Dan hoeven we niet langer te vertrouwen op één enkel stuk software om de poort naar de hemel te "firewallen", maar vertrouwen we op "checkpoints" die bij iedere stap kijken of de gebruiker z'n boekje niet te buiten gaat.

Klinkt als voor ieder "ding" (zoals netwerken, pakketten installeren, logfiles lezen) een groep aanmaken, en een user toekennen aan bepaalde groepen. Helaas ga je one-rules-all-users niet mee voorkomen.

[robvanwijk]

Als je een commando als willekeurige user mag uitvoeren, kun je ook een keylogger in de .bashrc van de administrator stoppen en het password op die manier achterhalen.

Het punt van "(ALL, !root)" is nou juist dat je een commando mag draaien als elke user... behalve root. En ik zou verwachten dat alleen root zelf schrijfrechten heeft op de .bashrc van root, toch?

Desondanks een interessante bug.

Dat zeker

[GertMenkel]

Het punt van "(ALL, !root)" is nou juist dat je een commando mag draaien als elke user... behalve root. En ik zou verwachten dat alleen root zelf schrijfrechten heeft op de .bashrc van root, toch?

Wat ik bedoel is de volgende situatie:
Anne beheert een systeem waarop Joop een account heeft. Joop wordt gehackt en de hacker krijgt shell access zonder dat Anne of Joop het doorhebben. Doordat Anne sudo goed heeft ingesteld, kan de hacker geen root krijgen met het account van Joop.

Wat de hacker wel kan doen, is een shell starten als user Anne en haar .bashrc aanpassen. Een simpele alias toevoegen voor sudo is genoeg voor de aanvaller om een mail met Anne's wachtwoord te krijgen de volgende keer als Anne sudo gebruikt.

Dit is te voorkomen door je .bashrc iedere keer als je inlogt door te lezen of door iedere keer als sudo op een systeem gebruikt wordt na te gaan wat en waarom. Echter zit in een grotere organisatie een fout in een klein hoekje en zullen dit soort dingen snel fout gaan zodra je niet twee maar twintig mensen met verschillende sudo rechten beheert.

[Verwijderd]

Dat is overigens niet helemaal waar

Quote:
"By default on most Linux distributions, the ALL keyword in RunAs specification in /etc/sudoers file, as shown in the screenshot, allows all users in the admin or sudo groups to run any command as any valid user on the system."

[GertMenkel]

Op zich technisch gezien waar, maar als je al sudo user bent kun je toch al root krijgen. Dan is dit meer een langere command line dan normaal in plaats van een exploit.

[robvanwijk]

als je al sudo user bent kun je toch al root krijgen

Hoe had je dat in gedachte? Als dat zo was dan zou de sudoers file alleen maar een lijstje zijn van usernames. Maar dat is niet zo, die file kan heel nauwkeurig opgeven wie wat mag doen. Het hele idee van sudo is nou juist om veel fijnmaziger te zijn dan su.

[GertMenkel]

Ik heb het over de default die genoemd wordt, namelijk dat een gebruiker in de sudo/admin/wheel groep op een Linux-systeem default de permissies krijgt om als enige gebruiker een commando uit te voeren. Die default bevat onder andere root.

Natuurlijk kun je dat aanpassen en je eigen, strictere policy volgen (dat is tenslotte de bedoeling van de geavanceerde config die sudo toestaat), maar dat is niet waar ik het over had in mijn comment.

[t link]

Problemen met dit soort bugs ontstaan ook vaak in combinatie met andere exploits, op die manier kan je er dan toch gebruik van maken.

[pruxor]

Ok, nou mag ik zowiezo alles op die server maar een simpel testje:

$ sudo --version
Sudo version 1.8.23

$ sudo -u '#-1' bash
bash-4.2# id
uid=0(root) gid=10007(pruxor) groups=10007(pruxor)
bash-4.2#

Edit: formatting (noob)

[Reactie gewijzigd door pruxor op 23 juli 2024 14:21]

[OxWax]

Een beetje duiding aub (voor een beginnende Basher/noob)

[RJG-223]

1e+2e regel: opvragen van versienummer van sudo: versie 1.8.23
3e regel: gebruik sudo om een andere gebruiker te worden, namelijk de gebruiker met nummer '-1'
4e regel: kijk welke gebruiker je bent geworden
5e regel: resultaat: je bent nu gebruiker nr 0 (niet -1). En je bent dus root (=administrator).

[OxWax]

Aha, ik had het dus juist begrepen (basic , I know)
maar user (uid)0 is per definitie root?

@phosporus
@jimshatt
@pruxor

[jimshatt]

Moest ik ook even googlen, maar blijkbaar wel: https://superuser.com/que...unt-always-have-uid-gid-0

(De username van uid 0 hoeft niet per se "root" te zijn, maar dan is het nog steeds de root user )

[RJG-223]

De username van uid 0 hoeft niet per se "root" te zijn, maar dan is het nog steeds de root user

Het zou me niets verbazen als er allerlei dingen niet helemaal goed gingen als de gebruiker met UID 0 ineens niet meer 'root' heette.

En er zouden waarschijnlijk zeker dingen verkeerd gaan als ook nog eens 'root' ineens bijv. UID 1 had (en dus een normale gerbuiker was).

[pruxor]

sudo --version

Huidige sudo versie (kwetsbaar).

sudo -u '#-1' bash

Start een bash shell als user -1 en voer daar het 'id' commando in uit om te tonen dat de huidige user ook echt root is.

Edit: argl..formatting. Is er niks beters dan quote om command line weer te geven in een post?

[Reactie gewijzigd door pruxor op 23 juli 2024 14:21]

[jimshatt]

Met -u kun je een gebruiker opgeven, via de gebruikersnaam of de gebruikers id (#uid). -u '#-1' wordt door sudo hetzelfde geïnterpreteerd als #0 (root).

Edit: Waar vind ik welke bbcode ik mag gebruiken in comments?

[Reactie gewijzigd door jimshatt op 23 juli 2024 14:21]

[phosporus]

Misschien wat meer info:

Stel je voegt een gebruiker toe in visudo die een commando mag uitvoeren als alle andere gebruikers, behalve root. Iets als: OxWax = (ALL, !root) commando
Als je dan sudo -u '#-1' commando uitvoert dan denk hij dat je -1 wil worden om commando uit te voeren. Dit laat hij toe, maar komt er dan achter dan gebruiker -1 niet bestaat, en maakt je dan maar gebruiker 0 (dat is root).

Waar het dus fout gaat is dat het worden van gebruiker -1 gebeurd voordat hij controleert of -1 bestaat, en daarbij je ook nog eens 0 maakt.

[Ed Vertijsment]

De kwetsbaarheid kan eigenlijk alleen misbruikt worden als een systeemeigenaar specifiek een sudoers-instructie heeft ingesteld voor een commando dat andere commando's kan uitvoeren, bijvoorbeeld 'vim'.

"Vim" en sommige andere applicaties zijn sowieso niet handig om als "sudo root" toe te staan, vanuit Vim kun je namelijk gewoon een subshell starten die dezelfde rechten krijgt als Vim zelf. En die is vervolgens niet meer beperkt to alleen Vim maak kan dan gewoon wat root kan.

[desalniettemin]

Moet je wel eerst Vim installeren, want niet iedere distro heeft dit dacht ik?

[Ed Vertijsment]

Als het toestaat met sudo neem ik aan dat het geïnstalleerd is.

[desalniettemin]

Heb het even gecheckt op mijn Peppermint, maar zit er niet in. Kan geinstalleerd worden met sudo apt vim. Heb ik niet gedaan, want ik gebruik het toch niet.

[Ed Vertijsment]

Wat ik hier bedoelde, als je zoals in het voorbeeld zelf vim toestaat als beperkte set om via sudo als root te draaien het beperken geen zin heeft. Ik doelde niet op default configuraties of installaties.

[desalniettemin]

O dan heb ik niet goed gelezen

[P1nGu1n]

Voor wie het zich afvraagt: 4294967295 is geen willekeurig getal, het is 32-bit signed integer -1 gerepresenteerd als een 32-bit unsigned integer. Tevens is het de maximale waarde van een 32-bit unsigned integer, oftewel 2³²-1.

Ter illustratie, zowel 32-bit signed integer -1 als 32-bit unsigned integer 4294967295 hebben dezelfde in-memory (binaire) representatie: 11111111111111111111111111111111 (32 1'tjes)

[Reactie gewijzigd door P1nGu1n op 23 juli 2024 14:21]

[SadisticPanda]

Voor de mensen de moeite te besparen....het zijn effectief 32 1'tjes die er staan

[Loggedinasroot]

Is dit een exploit of een vulnerability?

[kozue]

Zoals de engelse termen al aangeven is een vulnerability een kwetsbaarheid, oftewel een fout (zwakke plek) die misbruikt kan worden. Een exploit is code die zo’n fout daadwerkelijk misbruikt. 1 vulnerability kan dus meerdere exploits hebben, maar als de vulnerability gefixed wordt werken ze allemaal niet meer

[AverageNL]

Het is meer een vulnerability die in zéér specifieke gevallen geëxploiteerd kan worden. Ik heb het naar aanleiding van een topic in Geachte Redactie aangepast in de tekst en titel. Bedankt voor de oplettendheid en het melden

[ACM]

't Is een vulnerability en de voorbeelden zijn gelijk ook een exploit

[joeri1]

Zoals ik het lees zit er een vulnerability in sudo welke je zou kunnen misbruiken met behulp van een exploit.

[Fido]

Een exploit is een manier om een vulnerability uit te buiten, dus beiden

[Ome Ernst]

/Off-topic
Wat een epische naam als on-topic eerste reactie.

[youp.c]

Waarom gaat dit alleen over Linux? Is er een verschil tussen de Linux implementatie van sudo in andere Unix varianten zoals MacOS en BSD?

[Brupje]

Gaat uberhaupt niet over Linux maar over sudo. Dus alles waar dit sudo programma wordt gebruikt en root uid 0 heeft is kwetsbaar.

[Reactie gewijzigd door Brupje op 23 juli 2024 14:21]

[pruxor]

Sudo is op FreeBSD wel beschikbaar, maar standaard niet geinstalleerd.

[veltnet]

The same for Linux

[RoestVrijStaal]

Behalve OpenBSD, want die gebruikt doas

[SqyD]

De ontdekker werkt bij Apple en ook MacOS maakt gebruik van de sudo.ws implementatie dus het lijkt me inderdaad dat dit breder is dan enkel Linux.

[Verwijderd]

Ik kan me vergissen, maar zover ik weet werkt SUDO op alle UNIX gebaseerde omgevingen.
Kan het bijv ook op mijn edgerouter gebruiken, welke weer een "eigen" versie heeft van unix (edgeos).
Of hij daar ook kwetsbaar is is de volgende vraag.

[daemonix]

Je vergist je inderdaad. OpenBSD heeft sudo vervangen door het betere en veiliger doas.

[Verwijderd]

EdgeOS is gewoon een aangepaste versie van Debian hoor...

[desalniettemin]

Kreeg de update vanochtend vroeg al en meteen geinstalleerd.

[Reactie gewijzigd door desalniettemin op 23 juli 2024 14:21]

[poort]

debian heeft standaard geen sudo