Bug in sudo-commando kon rootrechten toekennen aan iedere gebruiker

Een bug in Unix-commando sudo maakte het mogelijk roottoegang te krijgen tot een besturingssysteem zonder authenticatie. Beveiligingsonderzoekers vonden een buffer-overflow-kwetsbaarheid in het protocol, waar inmiddels een patch voor uit is.

Het gaat om bug CVE-2021-3156. Daarmee kan een aanvaller in een terminal het sudo-commando uitbuiten om rootrechten te krijgen tot een Unix-machine zonder het wachtwoord te weten. De kwetsbaarheid zit in legacy sudo-versies van 1.8.2 tot aan 1.8.31p2 en alle stabiele versies van 1.9.0 tot 1.9.5p1 van grote Linux-distro's zoals Ubuntu, Debian en Fedora. Het sudo-commando staat voor 'superuser do' en wordt gebruikt om tijdelijke rootrechten te geven aan een gebruiker als die een commando wil uitvoeren en in daarvoor bedoelde lijst staat.

De bug werd ontdekt door securityonderzoekers van Qualys. Zij wisten rootrechten te krijgen op Ubuntu 20.04, Debian 10 en Fedora 33. De onderzoekers zeggen dat ook andere distro's waarschijnlijk gebruik maken van de kwetsbare sudo-versie.

De kwetsbaarheid is een heap-based buffer overflow. Die kan worden uitgevoerd als het sudo-commando in shell-modus wordt uitgevoerd met zowel de -s als de -i-optie. Als die commando's worden ingevoerd, worden speciale tekens niet meegenomen door een \ toe te voegen. Die worden dan automatisch uit het commando gehaald voordat sudo de sudo-policy verifieert. Er zit een kwetsbaarheid in de code die dat \-teken toevoegt, waardoor het mogelijk is commando's in shell-modus uit te voeren met de -s- of -i-optie, schrijft het sudo-team.

De bug bestaat al lang. Die werd in commit 8255ed69 toegevoegd, in juli 2011. Er is geen workaround beschikbaar; distributeurs moeten de patch voor sudo zelf doorvoeren in hun besturingssystemen. De bug is gerepareerd in sudo 1.9.5p2. Er zijn in het verleden al vaker kwetsbaarheden in sudo ontdekt, maar die waren in de praktijk lastig uit te voeren.

Reacties (163)

[sanscorp]

Maar worden dergelijke patches meegenomen met de standaard apt-get update of moet dit echt met de hand geïnstalleerd worden?

[HoD85]

Voor de distros die nog supported zijn kan je deze fix met de gewone "apt update && apt upgrade" of "yum update" binnenhalen.

Je kan natuurlijk ook specifiek sudo patchen "apt install sudo"

Als je kwetsbaar bent zie je dit:

root@testvm:~# sudoedit -s /
sudoedit: /: not a regular file
Hangup

Heb je de fix al zie je:

root@testvm:~# sudoedit -s /
usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-u user] file ...

Heb je een erg oude distro weet je hopelijk hoe je het zelf moet compilen.

[deacs]

Voor degene met legacy meuk moeten werken, installeer de nieuwe versie van sudo vanaf de source

$ wget https://www.sudo.ws/dist/sudo-1.9.5p2.tar.gz
$ tar -xzf sudo-1.9.5p2.tar.gz
$ cd sudo-1.9.5p2
$ ./configure
$ make
$ sudo make install
$ sudo reboot

[airell]

reboot ? Zijn er sudo libs normaal gesproken in gebruik? Het euvel zit toch in `sudoedit` ?

[SirQuack]

Gezien dit een exploit is die toepasbaar is op iedereen die lokaal is ingelogd, is een reboot de simpelste manier om iedereen even uit te loggen.

Niet nodig, maar levert vaak niet al te veel overlast op en garandeert dat je patch toepast op alle draaiende `sudo` commando's.

[DXaroth]

Normaal gesproken wel, maar ze adviseren mensen om direct te updaten, omdat niet iedereen elke dag `apt-get update && apt-get upgrade` draait.

[bytemaster460]

Zag in Linux Mint de patch gisteren (automatisch) binnenkomen.

[berchtold]

Deze memory exploits zullen blijven bestaan zolang C/C++ gebruikt worden. Misschien toch tijd om meer met Rust te gaan doen.

[rvt1]

Rust of andere talen zullen dit probleem niet echt oplossen voor je. Geen buffer overlows in Rust zeg je??
https://rustsec.org/advisories/CVE-2018-1000810.html
Let op ik ben geen rust expert, dus lees het zelf en laat het me weten als ik het fout heb.

Dit soort argumenten worden wel vaker aangehaald zowel c als c++ kunnen volledige veilig zijn mits je gebruik maakt van de juiste API's. Wat je zeker ook niet wilt is alles op nieuw schrijven in een andere taal op het argument 'want dat is veiliger', dat gaat je veel te veel tijd kosten en je zult nooit weten wat het resultaat zal zijn.

Als je bijvoorbeeld kijkt naar std::string vanuit c++ is die als string manipulatie prima te gebruiken en veilig.

Als ik kijk naar de code waar het om ging https://blog.qualys.com/v...low-in-sudo-baron-samedit

dan kan ik ook niet andere concluderen dat dit lastig te volgen is, maar dan moet je die routine herschrijven + testen en niet je hele applicatie. Zeker een tool als sudo is te complex om in een andere taal opnieuw te schrijven binnen redelijke tijd.

[84hannes]

Dit soort argumenten worden wel vaker aangehaald zowel c als c++ kunnen volledige veilig zijn mits je gebruik maakt van de juiste API's.

100% waar. Als je alles veilig doet is er niets onveilig; geen speld tussen te krijgen.
Helaas is in C/C++ het onderscheid tussen veilig en onveilig alleen door experts te herkennen, terwijl iedere amateur de aan- of afwezigheid van het woordje ‘unsafe’ in Rust kan herkennen.

[berchtold]

100% goed C++ schrijven lukt experts vaak ook niet. Mensen zullen altijd fouten maken. In Rust is het erg moeilijk om dingen echt fout te laten gaan, tenzij je er echt naar gaat zoeken, bij c++ is dat andersom.

[84hannes]

Zoals ik elders al stel: C++ heeft nog steeds de scherpe randjes van C. Het is fantastisch om te zien hoeveel beter C++ is geworden in pakweg 20 jaar. Je hebt vast wel eens gehoord van:

"Within C++, there is a much smaller and cleaner language struggling to get out"

Ik zou graag gezien hebben dat C++ features uit zou faseren, maar als ze raw pointers verwijderen tekenen ze waarschijnlijk voor hun eigen dood. Dan zou je een subset van C++ uit kunnen brengen, of je begint van scratch en leert van de fouten van C++, zoals:

• Geen multiple inhertitance. Weet je wat geen inheritance. Ik worstel hier nog steeds mee maar zie de redenatie.
• Functienotatie die ook leesbaar blijft als je functies teruggeeft of accepteert.

Dat gezegd hebbende, Rust is complex. Als ik ergens een artikel lees kom ik altijd weer syntax tegen die ik niet kende. Dat gebeurt met C niet zo snel.

[berchtold]

Ik weet niet waar je het over hebt. Bij C++ heb je juist vage syntax af en toe.

[84hannes]

Ik weet niet waar je het over hebt. Bij C++ heb je juist vage syntax af en toe.

Ik heb het over C, C++ en Rust.
C++ heeft zeker vage syntax, omdat vrijwel iedere toevoeging niet mag botsen met bestaande C/C++ syntax. Bij Rust zou ik de syntax consistenter willen noemen, maar dan heb ik het vooral over bijvoorbeeld functiedeclaraties. Ik denk dat niemand fan is van de Turbofish, maar hij is wel consistent. Het nadeel van Rust is dat de syntax heel uitgebreid is. Een groot deel van de problemen van C/C++ worden opgelost door syntax toe te voegen.

C heeft hele simpele syntax, dus als je wel zin hebt om duizenden regels code door te nemen, maar geen zin hebt om nieuwe syntax te leren, dan kun je beter bij C zijn.

Persoonlijk denk ik dat het leren van de syntax van Rust het voordeel heeft dat je uiteindelijk veel minder regels code door hoeft te lezen.

[elmuerte]

The rest of the implementation of str::repeat contains unsafe code that relies on a preallocated vector having the capacity calculated earlier.

Daar was dus het probleem. In Rust moet je expliciet unsafe zijn.
De change was een performance improvement voor een grotere N, onder andere door safety features van Rust uit te zetten. Ondanks de comment is er blijkbaar niet goed genoeg naar de code gekeken.

[Bensjero]

Uit oprechte interesse (ik ben ontwikkelaar maar heb geen ervaring met Rust);
Wat zorgt er voor dat memory exploits verkomen kunnen worden in Rust t.o.v. C/C++?
Beide talen moeten gecompileerd worden en rekenen niet direct met geheugen lijkt me.

[Jander]

Rust introduceert het concept 'ownership', wat betekent dat de compiler altijd weet welke scope eigenaar is van een stukje geheugen. Wanneer een stukje geheugen niet meer wordt gebruikt (wanneer de 'owner out of scope' raakt, zoals aan het eind van een functie die niets terug geeft), wordt het vrij gemaakt. In tegenstelling tot C ben je dus niet zelf adressen aan het bevrijden, maar moet je wel goed nadenken over waar `ownership` ligt. Ik vind het zelf erg prettig werken.

Het is overigens nog steeds mogelijk om memory leaks te krijgen in Rust, maar dat gebeurt praktisch alleen als je `unsafe` code schrijft (in een expliciet `unsafe` blok, waarmee je in essentie de compiler checks gaat negeren).

[diondokter]

Een memory leak is ook niet unsafe. In theorie kan dat voor eeuwig doorgaan. Het is alleen dat de OS het programma een keer gaat terminaten

Daarbij kan het ook wel in safe Rust. Als je twee RC's (gelijk aan shared_ptr) naar elkaar laat wijzen, dan kun je een memory leak krijgen.

[SpiceWorm]

Maar als het unsafe keyword de compiler checks niet laat uitvoeren, hangt dan de veiligheid van de "safe" code dus af van de compilerchecks?

[bwerg]

Ja. Dat is toch zo bij alle talen? Je legt de programmeur bepaalde regels op, vanwege veiligheid, maintainablility, wat dan ook, en je laat de compiler die checken.

Dat betekent natuurlijk dat als de compiler een bug bevat, die checking alsnog fout kan gaan, maar dat een foute compiler foute code genereert, daar hou je hoe dan ook met elke taal en elke compiler. Dat geldt niet alleen voor checking van ownership. Als een compiler per ongeluk meerdere variabelen in hetzelfde adres gaat opslaan ben net zo hard de Sjaak.

[SpiceWorm]

Dan is een nieuwe programmeertaal toch geen oplossing?

[bwerg]

Waarom niet?

Een taal kan helpen door onveilige constructies gewoon te verbieden, of door het lastiger te maken voor de programmeur om het fout te doen. C en C++ zijn typisch geen talen die hier hun best voor doen: je kan alles, dus ook gemakkelijk het foute. Een simpele out-of-bounds of een pointer naar gedealloceerd geheugen en je zit met een beetje pech in je stack te schrijven, terwijl de compiler maar een minimaal stukje generieke administratie hoeft te doen om door te hebben dat dat helemaal fout gaat.

De kans dat een compiler zélf fouten bevat is bij populaire talen véél kleiner dan de kans dat de vele miljoenen programma's geschreven in die taal fouten bevatten. En de kans dat een compilerfout leidt tot een veiligheidslek in een gecompileerd programma is nog veel kleiner.

Als je vaak knoeit bij het eten van soep, dan helpt het ook om de vork die je daarvoor te gebruiken te vervangen door een lepel. Het biedt nog steeds geen garanties maar bepaalde soorten fouten komen gewoon inherent niet voor als je gereedschap er bescherming tegen biedt.

[Reactie gewijzigd door bwerg op 24 juli 2024 07:22]

[diondokter]

Nee, het is een beetje een mythe dat unsafe de checks uit zet.

To switch to unsafe Rust, use the unsafe keyword and then start a new block that holds the unsafe code. You can take five actions in unsafe Rust, called unsafe superpowers, that you can’t in safe Rust. Those superpowers include the ability to:

- Dereference a raw pointer
- Call an unsafe function or method
- Access or modify a mutable static variable
- Implement an unsafe trait
- Access fields of unions

It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block.

https://doc.rust-lang.org...afe-rust.html#unsafe-rust

[mark8264]

Dit is overigens min of meer hetzelfde als unique_ptr in C++. Deze zijn al sinds C++11 in de standard library, en bestonden daarvoor ook al als deel van Boost als scoped_ptr. Veel van Rust's veilige features zijn iteraties op dezelfde features in C++. Het belangrijkste verschil is dat C++ vanwege backwards compatibility met C (en oudere versies van C++) ook onveilig gedrag makkelijk toestaat, terwijl dat in Rust allemaal niet kan tenzij je het unsafe keyword gebruikt.

[diondokter]

Klopt, maar Rust heeft een aantal regels waar code zich aan moet houden om te kunnen compilen.

Ownership:
Elke waarde heeft 1 owner. Ownership kan worden gemoved naar een andere variabele, maar alleen als die niet al geborrowed is.

Borrowing:
Vaak wil niet ownership transferren, maar wil je een reference geven.
Dit kan! Maar er zijn maar twee mogelijkheiden:
1. Een of meer immutable references
2. Eén mutable reference

Voldoet de code hier niet aan, dan is dat een compile error.

Voor de buffer overflow helpt dit niet heel veel. Daarvoor heeft Rust weer andere features.
Overal waar de compiler niet kan bewijzen dat een index binnen de buffer bounds blijft, insert Rust een bounds check. Dit lijkt slecht voor performance, maar als je gebruik maakt van iterators, dan zijn die checks er eigenlijk al nooit.

[Korben]

Het probleem is dat die checks er niet zijn als je 'unsafe'-blokken gebruikt. En dat doen stiekem best wel veel packages (of 'crates' in Rust-jargon).

[diondokter]

Dat is niet geheel waar.
1. Unsafe zet de checks niet uit. Je kan wel pointers dereferencen waardoor je, als je echt wil, er omheen kan.
2. Als je dit doet, dan heb je het echt wel goed door. Je moet je in veel bochten wringen, namelijk:
- Je moet de array/slice casten naar een pointer.
- Die pointer moet je offsetten met je index. (unsafe!)
- De pointer moet je dan dereferencen. (unsafe!)
Al met al zal een beetje Rust programmeur dit niet snel doen omdat de design van de taal je ook tegenwerkt.
3. Het grootste deel van de crates gebruikt geen unsafe. Vaak zijn het alleen de meest low-level crates die dat doen. Een beetje zoals C# ook unsafe heeft.

[latka]

Als ik het zo lees dan denk ik: gebruik gewoon een managed language (Java, Scala, Kotlin, C# ) en vergeet dit soort complexiteit. Uiteindelijke doel is hetzelfde, maar met die managed languages is unsafe (vrijwel) niet mogelijk tenzijn je native code gaat aanroepen.

[diondokter]

Managed talen zijn ook zeker prima!
De redenen om voor unmanaged te gaan zijn onder andere:
- Je kan niet afhankelijk van een runtime zijn.
- Je moet met hardware praten.
- Je hebt de performance nodig.
- Je hebt de kleine binary size nodig.

Dus dit is vooral: Databases, OS'ses, browsers, embedded firmware, high perf servers, etc

[84hannes]

Met managed talen heb je overhead van de garbage collector. Dat wil je in een besturingssysteem zoals/of een browser niet hebben vanwege performance. Ten tweede lossen manage talen maar een deel van de problemen op; thread safety is bijvoorbeeld nog steeds een probleem. Daarbij lossen managed talen eigenlijk maar 1 resource probleem op; die van geheugen. Maar variabelen kunnen naar geheugen verwijzen, maar ook naar netwerkverbindingen, bestanden en andere resources. Ook daar vertaalt ownership heel goed; je kunt een geopend bestand uitlenen (maar niet aanpassen terwijl je het uitgeleend hebt), teruggeven en je kunt hem sluiten (drop;).

[Reactie gewijzigd door 84hannes op 24 juli 2024 07:22]

[latka]

Mwoah, het is voornamelijk een legacy ding (en browser doen zelf GC voor het JS deel). Ben vooral thuis in JVM performance tuning, en dan is de GC vaak maar een klein probleem van het totale performance probleem (N+1 queries als favoriet en dan naar de GC wijzen). Performance van de kernel is wellicht wel een ding, alhoewel de kernels veel statisch sizen dus is er veel minder noodzaak tot GC. En je voorbeeld met bestanden is wellicht (ik leef voornamelijk in Unix) niet heel sterk omdat je memory mapped files wel gedeeld kunnen worden tussen threads (en dat wil je dan ook). Ik zeg niet dat Rust geen goede ideeen heeft, alleen lever je volgens mij een berg aan bestaande oplossingen in om borrowing ervoor terug te krijgen. Ik lees dan in de threads hier van string functies toch maar unsafe geschreven worden ivm. performance. Dan vraag ik me wel af waar we mee bezig zijn.

[84hannes]

Soms wil je inderdaad dat meerdere threads tegelijkertijd naar hetzelfde bestand kunnen schrijven. Meestal niet. Het is fijn als je compiler je garanties kan bieden zodat je niet zelf als je code uit hoeft te pluizen of je dit wegens fout doet. Maar dat is slechts een voorbeeld.

System programming languages zijn ook niet de oplossing voor al uw problemen; voor de meeste applicaties volstaat een managed taal inderdaad prima. Veel verlies zit inderdaad in inefficiënte algoritmes. Maar als performance de hoogste prioriteit heeft, dan wil je een lagere taal; waar denk je dat jouw vm mee is geprogrammeerd?

Als je performance en toch memory safety wilt vasthouden, dan is Rust een overweging waard.

[latka]

Wellicht. Ik ben echter vrij old school en grijp naar C voor snelheid en naar high-level/managed voor de overall werking van het systeem. C is niet fraai, maar inmiddels wel redelijk uitgekristaliseerd en je weet wat het doet en hoe het werkt. Dat is dan wel fijn als het echt snel moet.

[84hannes]

Het begrijpen van wat de Rust compiler doet is inderdaad wat lastiger. Voor velen niet relevant wellicht, maar voor jou waarschijnlijk wel. Daar staat tegenover dat de taal veel expressiever is, net als bijvoorbeeld Java en C#, maar veel meer zaken tijdens compilatie afhandeld. Het zal altijd een compromis zijn en ik zie Rust niet zo snel C vervangen maar wellicht C++ op termijn. C bevat veel scherpe randjes, C++ voegt daar alleen maar dingen aan toe; soms mooie abstracties, soms meer scherpe randjes.

[latka]

Ik denk dat inertie van de installed base van C++ code dit effectief blokkeert: je gaat c++ niet herbouwen in Rust. Het levert te weinig extra omzet om. Dus blijft er veel c++ code over. Rust met c++ laten babbelen gaat vast (geen ervaring mee), maar dat is per definitie unsafe, waardoor je weer terug bent bij af.

[84hannes]

Rust met c++ laten babbelen gaat vast

Lijkt me sterk. C++ heeft geen gestandaardiseerde ABI, je kunt er niet veilig tegen aan linken. Of, zoals ik het liever zeg: C is compatible met alles, C++ is niet eens compatible met zichzelf. In de praktijk kom je meestal Microsoft Visual Studio tegen, en iets dat compatible is met GCC (GCC zelf, CLang), maar zelfs dat biedt voor zover ik weet geen garanties; nieuwe versies van GCC hoeven niet compatible te zijn met oude versies.

Overigens schijnt C ook geen gestandaardiseerde ABI te hebben, maar is deze zo simpel dat hij wel heel stabiel is, tussen versies en leveranciers.

De oplossing is een C wrapper maken voor C++ en dat dan aanroepen met Rust. Kan wel, weet niet of het vele gebeurt. Het kan nodig zijn in een transitiefase; als je besluit alle nieuwe code in Rust te doen, maar niet op dag 1 alles oude code herschreven denkt te kunnen hebben. Het is inderdaad per definitie unsafe, maar laat perfectie niet de vijand van het goede zijn.

[bwerg]

met die managed languages is unsafe (vrijwel) niet mogelijk tenzijn je native code gaat aanroepen.

Met rust is unsafe toch ook niet mogelijk tenzij je unsafe gaat aanroepen? Zolang de taal het sterk ontmoedigt zie ik het verschil niet zo.

Voor rust-achtige talen was managed of unmanaged het verschil tussen inherent veilig of inherent onveilig, maar unmanaged veilig is toch helemaal prima?

[latka]

In Java/Scala etc. moet je je code in C schrijven. Een dll/.so van maken en dan in runtime linken met JNI. Dat doe je niet zo maar even dus dat verschil is heel groot tov. Rust/C# unsafe keywords. En ik heb niets tegen unmanaged veilig en ik denk dat borrow checkers ook kunnen leiden tot beter gestructureerde code. Maar ik zie het voordeel van native code nauwelijks meer: als je morgen een Arm based machine koopt mag je weer alles hercompileren. Ik dacht dat die tijd inmiddels wel een beetje ontgroeid waren.

[84hannes]

als je morgen een Arm based machine koopt mag je weer alles hercompileren.

Als dat alles zou zijn...

[.oisyn]

Meestal wel

[84hannes]

Vraag Microsoft eens waarom Visual Studio nog steeds geen 64-bit support heeft. Volgens mij komt het er op neer dat ze niet meer dezelfde bestanden in kunnen lezen omdat offsets anders zijn, ofzo.

[.oisyn]

Definieer "support". Je kunt in VS gewoon 64-bits apps compilen, debuggen en profilen. Dat is al de support die je nodig hebt, me dunkt. Waarom wil je per se dat devenv.exe zelf 64-bits is? Ik heb dat ding nooit meer dan 1GB geheugen zien gebruiken, en dan heb ik het over een project met ongeveer 40,000 files. De overstap naar 64-bits voor zoiets stuit gewoon op weerstand, omdat er ook allemaal plugins zijn die in moeten worden geladen, en die moeten dan ook allemaal 64 bits zijn, want een 64-bits proces kan geen 32-bits DLL uitvoeren, en vice versa.

Maar als jij de overstap maakt naar een fysiek andere CPU, dan is het idd een vereiste dat de libraries die je gebruikt ook voor dat platform zijn gecompileerd, of dat je zelf de sourcecode hebt. Maar op sourcecode-niveau is het niet veel meer dan gewoon een recompile. Als de endianness anders is, zul je rekening moeten houden met endian swaps als je binaire bestandsformaten ondersteunt. Als bitgrootte van verschillende types verschillen, is dat hooguit iets om rekening mee te houden als je je eigenlijk niet netjes aan de regels hebt gehouden (een pointer reinterpret_casten naar een int bijvoorbeeld).

Maar zoiets als 64-bits x86 naar 64-bits ARM terwijl de API geheel hetzelfde is (zoals op Windows), dat is dus echt een no-brainer.

[Reactie gewijzigd door .oisyn op 24 juli 2024 07:22]

[beerse]

In Java/Scala etc. moet je je code in C schrijven. Een dll/.so van maken en dan in runtime linken met JNI.

Mooi, dan zijn we rond. Het begon allemaal dat iemand voorstelde om geen C te gebruiken.

[scholtnp]

Er is zelf een project om een geheel nieuw unix OS in Rust te schrijven: RedoxOS.
En de bestaande Linux kernel wordt ook 'Rustieker' gemaakt.

[beerse]

De hele gnu-toolset herschrijven? linux herschrijven? Succes!

Maar waarom Rust? Waarom geen Modula-2?

[Henk Poley]

Dan wel de opvolger Oberon-2, die heeft tenminste buffer overflow checks 😅

[sparcle]

Of ADA/Spark?

[84hannes]

De hele gnu-toolset herschrijven?

Ik zie wel een trend.

https://zaiste.net/posts/shell-commands-rust/

[Mars Warrior]

Dus Linux is stiekum 10 jaar lang het meest onveilig OS geweest

[the_stickie]

bwa.. om sudo te doen moet je natuurlijk wel eerst aangemeld zijn als normale gebruiker. 't is dus 'maar' privilege escalation. Zoiets komt bij elke os wel 'ns voor.
Een bug kan pas gefixed worden als die gevonden wordt, dus ja daar gaat soms veel tijd over.

Het unieke is eigenlijk dat deze na zoveel jaar naar boven komt en schijnbaar niet supercomplex is. De kans is mijns inziens dus groot dat er al partijen waren dat dit eerder kenden/misbruikten.
Het werpt ook een ander licht op het geclaimde 'opensource software wordt voortdurend publiek geaudit en is dus veiliger'

[Zer0]

Een bug kan pas gefixed worden als die gevonden wordt, dus ja daar gaat soms veel tijd over.

Één van de argumenten die vaak voor Open Source Software gebruikt wordt is dat door de vele ogen bugs veel sneller gevonden worden. Toch zie je met regelmaat dat er bugs gevonden worden die al jarenlang aanwezig zijn.

[StefanJanssen]

Sneller gevonden heb ik zelf niet vaak gehoord. Sneller opgelost wel.

[Zonnekeer]

Als je de source code tot je beschikking hebt kun je beter begrijpen hoe de software intern met input omgaat.
Als men dan vervolgens gaat bedenken "wat kan ik doen om dit mis te laten gaan" met de volledige voorkennis hoe de applicatie intern te werk gaat, dan vind je sneller een manier om dit te exploiteren.

Bijv. algoritmes vinden die mogelijk onveilig met input werken, en deze op zo'n manier crashen dat je direct naar het geheugen kunt schrijven.

[Sito]

Maar wie gaat er voor zijn plezier exploits zoeken in open-source repositories? Niemand, behalve kwaadwillenden. In het zeldzame geval een security auditor, maar dat zie je niet vaak.

[slowdive]

Er wordt aan universiteiten veel onderzoek gedaan op dit gebied. Dat onderzoek vind plaats aan binaries, maar ook aan broncode.
Open source repositories kunnen bijvoorbeeld een beeld geven van hoevaak een bepaalde kwetsbaarheid voorkomt.
Dat onderzoek helpt om de technieken te verbeteren die kwetsbaarheden-scanners gebruiken te verbeteren.
Denk daarbij aan kunstmatige intelligentie, datamining (in repo's) of (Dynamic) Symbolic Execution.
Er zijn allerlei onderzoeksgebieden 'hot', onderzoek naar kwetsbaarheden in software is m.i. een van die moderne onderzoeksgebieden (eigenlijk al een lange tijd).

[Zonnekeer]

Wat denk je dat het voor je cybersecurity/development carriëre doet als je zo'n bug vind en rapporteert?
Er is een hoop meer te verdienen als white hat dan als black hat, als je goed bent in je werk.

Verder heb je ook nog bedrijven als Red Hat (IBM) en SUSE, die wel degelijk bug bounties uitzetten en teams hebben om dit te onderzoeken.

[Tux4life]

In dit geval dus Qualys

[hiostu]

Sneller gevonden is hier anders door erg veel mensen op tweakers.net in de comments geroepen. Zeker in de periode van 10 jaar geleden toen het Microsoft vs Open Source debat nog veel heftiger was. Het argument is altijd geweest dat er meerdere verschillende mensen naar de code kijken, meer dan nog bij closed source.

[K-aroq]

Als je closed source software levert zijn er (in een zakelijke omgeving) SLA's over het oplossen van bugs. Als je eigen IT team iets heeft gemaakt op basis van open source heb je dat niet en ben je overgeleverd aan de community.

[beerse]

Met closed source ben je dus afhankelijk van de afspraken. Meestal is dat iets van een koop contract met de oplossing: Koop de volgende versie want jou versie is ondertussen niet meer actueel. Of erger: De licentie was geen life-time-license maar een jaarlijkse licentie. Wilt u even schikken?

Als de eigen IT afdeling iets heeft gemaakt op basis van open source zouden ze het in theorie zelf kunnen oplossen of daar een professional voor in te huren. In de praktijk blijkt de community beslist niet trager of slechter bugs op te lossen dan commerciële closed source. Met de vrije mogelijkheid om zelf te bepalen of de nieuwste versie gebruikt gaat worden of dat juist budget neutraal word overgestapt naar oude of andere libraries/tools.

[svennd]

Een van de eerste lessen security is ook : security by obscurity is geen security.

[MN-Power]

En een andere les zegt dat het(o.a. bij foutmeldingen) niet verstandig is informatie over hardware, software, of nog erger versie informatie prijs te geven. Je weet dan namelijk meteen welke aanvallen niet of juist wel zouden kunnen werken.

Of om dit voorbeeld te nemen. Aangezien het open source is, wie zegt mij dat iemand hier niet al tien jaar van op de hoogte is? De code was tenslotte voor letterlijk iedereen in te zen.

[Douweegbertje]

Ik kan je dat wel vertellen.
Er zijn duizenden systemen bewust zo ingeregeld om gedrag van hackers en exploits te monitoren. Honeypots.

Dus een 0day kan zo worden ontdekt. Je kan daar niet alle conclusies op los laten. Echter is het wel veilig om de aanname te doen dat dit niet in het wild voor jaren werd gebruikt.

[Eelco de V]

Doet me denken aan een artikel van een aantal jaar terug over 'armchair auditors'. Waar open data zou moeten zorgen dat er met meer ogen naar gekeken werd. Blijkt dat in de praktijk er niet zo heel veel mensen met die tijd en kennis rondlopen die dat voor hun hobby doen.

BBC News - Government online data ignored by 'armchair auditors'
https://www.bbc.co.uk/news/uk-politics-20221398

[Katsunami]

Dat dus. Er zijn zat opensourceprojecten die onderhouden worden door 1 of 2 personen, maar die door miljoenen worden gebruikt. Denk bijvoorbeeld aan Calibre. De hoofdontwikkelaar is Kovid Goyal, en soms komt er hier en daar een patch binnen van iemand anders. Er zijn wel een paar ontwikkelaars die elk hun eigen setje aan plugins onderhouden. Echter, mocht Kovid Goyal ermee stoppen, dan zie ik niet iemand even "zomaar" dat project overnemen.

Die gast heeft er zijn werk van kunnen maken aan de hand van de donaties. (Wat ik persoonlijk nooit gedaan zou hebben, als ik net zoals hem gepromoveerd was; in de richting van quantum computing, als ik het me goed herinner.) Dat neem je niet zomaar over.

De opensourceprojecten waar echt honderden of duizenden ontwikkelaars aan werken, zijn eigenlijk zeldzaam; en vaak zijn het projecten die door een (zeer) groot bedrijf zelf gebruik worden, die het project dan met verdere ontwikkeling sponsoren.

[beerse]

Het is maar net wat je als opensource project ziet. Kijk je naar Gnu, dan zijn dat heel veel ontwikkelaars. Maar kijk je naar 1 onderdeel daar uit dan is het per tool veel minder.

Calibre is een aardig voorbeeld: Die gebruikt best wel veel libraries en onderliggende tools. Die worden allemaal door anderen onderhouden. Mee eens, je neemt het niet zomaar over. Maar er zijn genoeg voorbeelden van tools die op hun manier wel zijn overgenomen/aangepast of een andere creative route op zijn gegaan. De linux kernel bijvoorbeeld, maar ook alle tools die 'open' in de naam hebben/hadden en nu een variant daar op hebben.

En van kleinere tools met 1 of een paar ontwikkelaars: Die worden soms ook ingehaald door andere tools. Kijk naar de compressie/archive tools. Onder unix heb ik tar en zip leren gebruiken en al snel gtar en gzip (de gnu versies/varianten). Toen onder de microsoft os-varianten in creative volgorde: pkzip, rar, winrar, peazip, 7zip en er zijn er nog wel een paar in diverse gradaties van closed-license tot open-source. De meeste door een klein team gebouwd.

Of kijk naar de crypto-tool: TrueCrypt was het helemaal en zou na de audit de perfectie zijn. Maar ergens ging iets mis. Nu gebruikt een groot deel van de wereld VeraCrypt.

Om maar voorbeelden te geven dat de tools soms door andere worden ingehaald maar soms ook pas worden overgenomen na het stoppen. In de regel kan je bij opensource zeggen: Zolang het goed gaat gaan we door. Als er iets mis is dan grijpen we in en als het fout gaat dan pakken we het op. Maar niet eerder dan dat.

En nu ik er aan denk: Er zijn ook (opensource) tools die gewoon af zijn. Daar hoeft niets bij, daar hoeft niets af, die kunnen we gewoon blijven gebruiken.

[Byron010]

Probleem van dit soort argumenten is dat je het niet kan vergelijken en dus niet daadwerkelijk kan bewijzen.
Het "kan" best dat dezelfde bug in closed-source software over 50 jaar nog steeds niet gevonden is, terwijl het in dit geval dus in 10 jaar gevonden is.

Je zou een identieke software zowel open als closed source moeten hebben en dan vergelijken welke eerst gevonden wordt. En hoe bepaal je vervolgens hoeveel mensen naar de open source software kijken, en hoeveel expertise ze hebben etc...

[the_stickie]

eens, het blijft appelen en peren vergelijken en we kunnen niet wetenschappelijk dubbel blind testen.
Maar dat maakt het niet onmogelijk te discussiëren en argumenteren. Bovendien is dat noodzakelijk opdat we elk onze mening kunnen vormen - en dat hoeft niet dezelfde te zijn.

[wica]

Tja, als alle bedrijven 0.5% van hun omzet zouden spenderen aan het auditteen van opensource code... Dan had het idd sneller gevonden kunnen worden.
Meeste ontwikkelaars hebben niet de tijd om elke stukje code door te lezen.

[beerse]

Dat valt tegen: De meeste bedrijven die dat doen, kijken met een zelfde blik en een zelfde belang naar de zelfde code. De meeste testen zijn gericht op de goede werking.

Kijk bijvoorbeeld naar nieuws: Spelende kinderen ontdekken bug waarmee Linux Mint kon worden ontgren.... Een bug gevonden door zomaar wat te doen. Ik kan mij voorstellen dat er bij de meeste wachtwoord toegang testen geen test zit op dit soort details.

[thomas_n]

Bij closed source software blijft het meestal geheim hoe lang "nieuwe" bugs al in de software zaten. Logisch dus dat dit verschijnsel vooral bij open source software te zien is.

[YopY]

Da's waar, maar dan nog zijn er nog regelmatig issues. Een ander voordeel van open source is dat er snel een fix is natuurlijk.

iig, deze issue hadden ze waarschijnlijk kunnen vinden dmv fuzzing - semi-random data naar het `sudo -i` commando sturen.

[YoMarK]

Een normale gebruiker staat in de meeste distro's niet als sudouser bekend (moet b.v. in de groep sudo of wheel zitten). users die daarin zitten zijn doorgaans natuurlijk admins, want ze willen sudo gebruiken.
Of fietst dit daar omheen? Heb me niet ingelezen in de issue, maar gezien de commando's hierboven lijkt me dit niet het geval.
Dit maakt het probleem natuurlijk een stuk minder groot.

[Reactie gewijzigd door YoMarK op 24 juli 2024 07:22]

[wilfredk]

in dit geval maakt de lijst dus niks uit en kan de gebruiker alsnog root rechten krijgen zonder in 1 van deze 2 groepen te zitten.

en ik heb net op mijn "server" (intel nuc) gekeken en ubuntu geeft als nieuwste versie vrolijk 1.9.1 maar tenzij ik mijn server ga hacken kan er niemand bij want je moet wel eerst shell acces hebben:)

[R4gnax]

in dit geval maakt de lijst dus niks uit en kan de gebruiker alsnog root rechten krijgen zonder in 1 van deze 2 groepen te zitten.

en ik heb net op mijn "server" (intel nuc) gekeken en ubuntu geeft als nieuwste versie vrolijk 1.9.1 maar tenzij ik mijn server ga hacken kan er niemand bij want je moet wel eerst shell acces hebben:)

Maar betekent dit dan bijv. dat op smaakjes van *nix draaiende IoT devices en network-devices zoals routers eerst een andere exploit gebruikt zou kunnen worden om shell access te pakken, en daarna deze exploit om volledig root te pakken, zolang zo'n apparaat maar met sudo en sudoedit uitgerust zijn?

Want dan heb je hier eigenlijk best wel een flink probleem aan.

[Reactie gewijzigd door R4gnax op 24 juli 2024 07:22]

[wilfredk]

dit betekend inderdaad dat alle IoT devices die een *nix draaien met sudo geinstaleerd eerst een andere exploit nodig hebben om hier misbruik van te maken.
helaas hebben veel (meschien zelfs de meeste) de standaard gebruikersnaam en wachtwoord niet veranderd waardoor een exploit zoals deze niet eens nodig is om voledig toegang te krijgen.

[afterburn]

Umm. Nee. De meeste moderne distros hebben standaard geen PW meer staan op het root account (kun je dus niet mee inloggen) en dus hebben de meesten dus iig het eerste gewone account met sudo rechten.

Zakelijk is het een ander geval maar dan heb je het (als het goed is) over een custom, hardened deployment en geen normale distro installatie.

[YoMarK]

Dat weet ik, maar Linux wordt toch nog altijd het meeste gebruikt NIET op desktops.
Alle userland servers of systemd / init.d gebruiken doorgaans een aparte gebruiker, en dat zijn geen sudoers.
Wat me nog steeds niet duidelijk is(ik ga de reacties er even op naspitten) is of een user als b.v. httpd/apache via b.v. een hypothetische andere apache exploit ook root rechten kan vergaren.

[amx]

Laten we eerlijk zijn: hoeveel actieve gebruikers (interactief) zijn niet lid van sudo

[YoMarK]

Alle gebruikers op een gedeeld systeem(shared hosting), en gebruikers behorende bij een userland applicatie als httpd b.v
Servers dus. Voor desktops(interactief zoals je zegt ) heb je gelijk, maar die gebruikersgroep is veel kleiner.

[Reactie gewijzigd door YoMarK op 24 juli 2024 07:22]

[amx]

Hoeveel mensen zullen dit zijn? En nogmaals, ik bedoel interactieve logins geen service of applicatie accounts.

Ik had het graag anders gezien, maar kan maar weinig in het wild voorkomende use cases bedenken waar gebruikers in een ongeving aanmelden wat geen windows is en ook geen applicatie met linux als backend en geen sudo rechten hebben

[Reactie gewijzigd door amx op 24 juli 2024 07:22]

[YoMarK]

Je hebt gelijk, maar mijn punt is dat Linux 99% op servers en andere devices gebruikt wordt, en maar 1% op een desktop met interactieve login, waar de gebruiker daadwerkelijk zit te werken.
Ik was daarom meer benieuwd naar of een user als httpd, of een user in b.v. een shared hosting scenario ook van deze sudo issue gebruik zou kunnen maken.
Los daarvan staat MacOS, want dat is geen Linux(maar daar is het probleem dus ook).

[Reactie gewijzigd door YoMarK op 24 juli 2024 07:22]

[amx]

Nee op zich niet, maar persoonlijk zie ik meer heil in het uitvoeren van dergelijke services in een container omgeving.

Om het oorspronkelijke punt aan te halen: voor een VDI hoef je denk ik echt niet meer vast te zitten aan Windows, maar echt goede implementaties van een VDI met een Linux desktop ken ik niet helaas. In een VDI hoeft een gebruiker ook geen sudo rechten

[Reactie gewijzigd door amx op 24 juli 2024 07:22]

[mocean]

Een verschil is dat je bij vele shared hosting accounts een ftp user krijgt, die ook shell user is. En vrij veel machines voor shared hosting accounts zijn een Linux variant.

[SRI]

Tenzij in windows of macos bijvoorbeeld nog ergere (onontdekte) bugs zitten. Zou zo kunnen.

[Keeper of the Keys]

Spoiler alert macOS gebruikt ook sudo (1.8.31 in de laatste update van Catalina dus met vulnerability).

Verder is zoals in het artikel en hiervoor al genoemd dit een probleem dat alleen kan worden misbruikt door een gebruiker die al is ingelogd (fysiek of via SSH).

Ja sudo is een heel belangrijke tool en nee dit is geen ramp op de meeste systemen (tenzij je de gebruikers van je systeem niet kunt vertrouwen).

Alle code heeft bugs, hoe de bugs te misbruiken zijn en waarvoor stelt de ernst vast, dit is een ernsitge bug maar geen ramp omdat je zoals gezegd eerst toegang moet krijgen tot het systeem.

[The Zep Man]

Spoiler alert: in jouw gebruikte besturingssysteem zitten dit soort kwetsbaarheden!

Verschil met de kwetsbaarheid in dit artikel is dat ze nog niet gevonden zijn. Verder is de kwetsbaarheid in dit artikel gevonden, de werking is uitgelegd, en de oplossing is volledig transparant, inzichtelijk en beschikbaar. What's not to like?

Zolang updates tijdig worden geïnstalleerd is het risico op misbruik minimaal. Een beheerder hoeft zich dan niet eens bewust te zijn van deze kwetsbaarheid, want die wordt vanzelf opgelost.

Als je als aanvaller al lokaal vrij code kan draaien op een systeem, dan is het systeem sowieso al gecompromitteerd. Qua dat is het nu even naar dat er weer een privilege escalation aanval is voor een ingelogde gebruiker, maar het is niets nieuws. Zolang andere beveiligingslagen aanwezig zijn, kunnen de risico's voldoende gemitigeerd worden totdat een update wordt geïnstalleerd.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 07:22]

[Ed Vertijsment]

Nee, dat valt niet zomaar te zeggen. Los van dat sudo in andere OS'en ook te vinden is dit een kwetsbaarheid. Eentje die misbruikt KAN worden mits bekend bij een aanvaller. Het valt niet te zeggen dat een systeem niet kwetsbaar is (we weten niet wat we niet weten) en het is zeer waarschijnlijk dat er in elk OS nog genoeg kwetsbaarheden zitten.

[Eonfge]

Het nieuws van vanochtend niet gelezen?
nieuws: Apple dicht drie zerodays in iOS

Linux heeft veiligheidsvoordelen, maar het is geen magisch systeem dat geen kwetsbaarheden heeft.

[Reactie gewijzigd door Eonfge op 24 juli 2024 07:22]

[PageFault]

Niet helemaal, want enkele jaren geleden kon je op macOS inloggen met 'root' zonder wachtwoord. Dat was nog erger dan dit, want voor sudo moet je uberhaupt eerst ingelogd zijn.

Verschil is wel dat Apple dat lek binnen 2 weken dichtte ipv na 10 jaar.

[Christoxz]

Verschil is wel dat Apple dat lek binnen 2 weken dichtte ipv na 10 jaar.

Ik ben niet bekend met het lek van MacOS, maar grote kans dat die lek er ook langer inzat dan twee weken, of ook gewoon gevonden is binnen twee weken.
Het is niet zo dat Sudo 10 jaar bezig is geweest om het te dichten.

[lappro]

Dat is alleen een onjuiste vergelijking. Je vergelijkt oplossingstijd met tijd dat een bug aanwezig is.
Gezien de CVE van deze bug 2 weken geleden gemaakt is en de bug nu opgelost is, is de oplossingstijd dus vergelijkbaar.

[cricque]

Ja maar je moet al lokaal op de machine zetten. Als het om een "gehackte machine gaat dan heeft die persoon waarschijnlijk wel al een manier om root rechten te verkrijgen gevonden. En de gemiddelde gebruiker, heeft geen idee wat of hoe je dit zou moeten doen. En linux op een werkplaats valt niet zoveel voor als desktop voor non IT personeel, en als het om IT personeel gaat, dan is de kans groot dat ze het root wachtwoord wel kennen. Het is een bug, en geen kleintje uiteraard, maar het meest onveilige OS lijkt me een sterke uitspraak. Er zullen vast wel personen geweest zijn die dit al lang geleden wisten, maar als je dan toch al je eigen toegang kan verschaffen tot een remote machine dan weet je al net iets meer

[souplost]

Linux is een kernel. Deze bug heeft niets met de Linux kernel te maken.
het is een programma net als TrendMicro ServerProtect ook een programa is waar een Heap-based Buffer Overflow Privilege Escalation Vulnerability 2 maanden geleden in werd gevonden maar daar hoor je niemand over want is closed source.

Daarnaast loggen gebruikers nooit meer in op Linux servers . Gebruikers die dat wel doen (met ssh-keys) hebben toch al sudo rechten. Ook worden home folders, tmp en shared memory gemount met noexe optie zodat gebruiker programma/script (malware) vanaf die plek niet opgestart kunnen worden. Gebruikers kletsen tegen een dienst mbv een api . Deze gebruikers komen uit IPA of AD en home folders weer van een andere plek.
Op de home desktop thuis is het al helemaal niet van belang.

[Josk79]

Daarnaast loggen gebruikers nooit meer in op Linux servers . Gebruikers die dat wel doen (met ssh-keys) hebben toch al sudo rechten. Ook worden home folders, tmp en shared memory gemount met noexe optie zodat gebruiker programma/script (malware) vanaf die plek niet opgestart kunnen worden.

Bij shared hosting kan vaak via ssh ingelogd worden. Is deze exploit in dit geval niet een groot risico?

[souplost]

Dat doen beheerders die toch al sudo rechten hebben. Onbekende gebruikers laat je niet via ssh inloggen. Nergens voor nodig.

[Josk79]

De praktijk is anders. Ik had i.i.g. bij de shared hosting van SiteGround, Vimexx en Versio ssh toegang. Zeer handig... greppen, cli tools, git, etc.

[souplost]

Jij bent de enige die daar ssh toegang heeft tot je eigen omgeving!

[Josk79]

Ik was in de veronderstelling dat een sudo user hierbuiten kan treden.

[tweakorinho]

Zo, je zou zeggen dat zulke dingen al uitgekristalliseerd zijn na zoveel jaren en gehek.

[diondokter]

C bied je hier ook totaal geen bescherming tegen.
Bedenk je nu hoe veel er nog steeds in kunnen zitten (en dan is sudo nog maar een relatief klein programma).
Tijd dat mensen naar memory-safe talen gaan overschakelen.

Zowel chrome als microsoft zeggen dat ongeveer 70% van de security bugs door memory safety issues komen:
https://www.zdnet.com/art...are-memory-safety-issues/
https://www.zdnet.com/art...are-memory-safety-issues/

[rvt1]

Niet alle memory-safe talen zijn dan ook safe...

je kunt prima ook overschakelen naar API's die ook memory safe zijn ipv alles opnieuw schrijven, opnieuw schrijven kost te veel tijd en daar win je ook niets me.

[diondokter]

Dit kan natuurlijk ook beetje bij beetje. Maar dat vereist wel dat er gestopt wordt met het schrijven van nieuwe C code.

[Henk Poley]

Zeker een goed punt, overigens word de logica duplicatie fout in sudo hierdoor niet tegengehouden. Maar deze precieze uitvoer met buffer overflow inderdaad wel ja. Ze hadden bepaalde checks meerdere malen in de code staan, maar hier en daar net even anders. Daardoor kon je via de vreemde manier van binnenkomen (sudoedit) er tussendoor fietsen.

[Raka]

Is Android hier dan ook kwetsbaar voor? En MacOS?

[Wolfos]

Android heeft standaard geen sudo volgens mij.

[cariolive23]

MacOS: Ik vrees van wel, dit krijg ik terug van --version:

Sudo version 1.8.31
Sudoers policy plugin version 1.8.31
Sudoers file grammar version 46
Sudoers I/O plugin version 1.8.31

[jvwou123]

Ik wil niet zeggen dat ik precies begrijp wat er allemaal staat op de site van qualys. Maar als ik het zo lees moet er zowel de flag MODE_SHELL en (MODE_EDIT of MODE_CHECK) aan staan. En dat is alleen mogelijk met het commando `sudoedit`, en een MacOS heeft dit commando niet. Dus het lijkt minder mogelijk dan een Ubuntu die dat commando wel heeft.

[cariolive23]

Ik ga het eens checken, thanks!

[Raventhorn]

In Android zit sudo bij mijn weten niet standaard opgenomen (kan ik mis hebben), maar als je 'm geroot hebt zou het device wel kwetsbaar kunnen zijn ja. In dat geval kan het noodzakelijk zijn dat de sudo binary wordt geüpdatet; waarschijnlijk door de 'root package' opnieuw te flashen met een bijgewerkte variant.
Het is al even geleden dat ik m'n devices zelf geroot heb gehad, mogelijk dat er tegenwoordig ook 'OTA'-updates mogelijk zijn. (bijv. van Magisk)

In macos is sudo wel opgenomen, en kan dus ook kwetsbaar zijn. Zie bijvoorbeeld ook dit artikel van vorig jaar, waarbij een stack-based overflow was gevonden waar macos ook kwetsbaar voor was.
Ook hiervoor is het dus verstandig om te kijken of er updates beschikbaar zijn, als je Apple apparaten gebruikt.

[Henk Poley]

macOS is vatbaar: https://twitter.com/HenkPoley/status/1354289441066651648

Security update komt waarschijnlijk ergens de volgende 24 binnen: https://twitter.com/schlix_gawd/status/1354313106185449474

[Reactie gewijzigd door Henk Poley op 24 juli 2024 07:22]

[himlims_]

https://www.debian.org/security/2021/dsa-4839
vanochtend op de bakkies uitgerold

voor deb bakkie; [apt-cache policy sudo] kun je de build controlleren en of er een vers pakketje/patch beschikbaar is

[carlpls]

Vergeet niet eerst apt-get update te doen.

[Indir]

Tegenwoordig volstaat apt update / apt upgrade.

[himlims_]

als dat toch compleet wilt maken, gestrekt been er in:
sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade && sudo apt-get autoremove

dist-upgrade kan bijv. bij debian buster van 10.6 naar 10.7 gaan; niets majors, maar zit je bijv. op stretch en je doet dan een dist-upgrade ... dan ben je wel even zoet

[Reactie gewijzigd door himlims_ op 24 juli 2024 07:22]

[_Eend_]

Of om het nog spannender te maken:

sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade && sudo apt-get autoremove -y

[jvwou123]

of:
sudo apt-get update && sudo apt-get -y dist-upgrade && sudo apt-get autoremove -y && reboot

Deze draai ik met enige regelmaat op info schermen. Als die een keer een dagje het niet doe: pech. USB er in, automatisch installatie script, en klaar. Overigens: nog nooit fout gegaan.

(een dist-upgrade doet ook de gewone updates, plus nog een paar extra andere deps nodig hebben dacht ik uit mijn hoofd)..

[Malarky]

1. 'apt-get' is in beginsel legacy en gewoon vervangen door 'apt'
2. 'apt full-upgrade' is daarmee de identieke vervanger voor 'apt-get dist-upgrade'
3. "do-release-upgrade" heb je toch echt nog nodig als je ook vanaf de commandline naar een compleet nieuwe beschikbare release wil upgraden. Dat doen de andere commands zeker niet.
4. Minder commands is uiteraard sneller, "--auto-remove" kan je gewoon direct toevoegen als parameter aan de 'full-upgrade', hoeft je niet opnieuw sudo apt voor af te vuren.

Ik draai regelmatig:
ssh -t <username>@<ip> "sudo apt update; sudo apt --auto-remove full-upgrade -y; sudo do-release-upgrade"

Op mijn virtual linux vanuit externe commandvenster, zijn we weer snel klaar. Volgens mij is dat de meest recente aangeraden en complete commandset.

[Reactie gewijzigd door Malarky op 24 juli 2024 07:22]

[jvwou123]

Weer wat geleerd, die --auto-remove kende ik nog niet, scheelt idd weer commando.
Ik doe meestal wel een && er tussen, mocht er 1 commando een error geven gaat ie iig niet verder.

[mjz2cool]

Al zou ik niet altijd gelijk dist-upgrade gebruiken, en autoremove kan ook nog wel eens verkeerd gaan.

[carlpls]

Ah ja, correct! Voor scripting doeleinden raden ze geloof ik nog wel apt-get aan meen ik, maar voor cli usage is apt inderdaad the way to go tegenwoordig.

[amx]

apt-get download voor als je een package alleen wil downloaden en op een andere host wil uitvoeren

[Fluttershy]

Bug in sudo-commando kon rootrechten toekennen aan iedere gebruiker

Is dat niet de primaire functionaliteit van die tool?

Of zit ik al 20 jaar een tekstverwerker te misbruiken om dingen als root uit te voeren?

[koelpasta]

Is dat niet de primaire functionaliteit van die tool?

Alleen als je iedere gebruiker op je systeem sudo rechten geeft.

[YStec]

Je geeft inderdaad eenmalig superuser rechten aan een user, maar daarvoor moet je dus wel het wachtwoord van de superuser weten.

Het ging het er in dit geval dus om dat je die rechten kunt geven zonder het wachtwoord te weten.

[thijsjek]

Nee, je hoeft het wachtwoord van de superuser niet te weten. Het is nogmaals het wachtwoord van de user. De user moet in de lijst sudoers staan om sudo te mogen uitvoeren.

[HoD85]

Je moet dit natuurlijk zo snel mogelijk patchen.
Als dit voor een goed (of administratieve..) reden niet onmiddelijk kan stel Red Hat een tijdelijke workaround voor:

https://access.redhat.com...erabilities/RHSB-2021-002

Let op, dit schakelt tijdelijk sudoedit uit!

Mitigation

Red Hat Product Security strongly recommends customers to update to fixed sudo packages once they are available. For customers who cannot update immediately, the following interim partial mitigation using systemtap is suggested:


1. Install required systemtap packages and dependencies:

systemtap yum-utils kernel-devel-"$(uname -r)"

Then for RHEL 7 install kernel debuginfo, using: debuginfo-install -y kernel-"$(uname -r)"

Then for RHEL 8 install sudo debuginfo, using: debuginfo-install sudo


2. Create the following systemtap script: (call the file as sudoedit-block.stap)

probe process("/usr/bin/sudo").function("main") {

command = cmdline_args(0,0,"");

if (strpos(command, "edit") >= 0) {

raise(9);

}

}


3. Install the script using the following command: (using root)

# nohup stap -g sudoedit-block.stap &

(This should output the PID number of the systemtap script)

This script will cause the vulnerable sudoedit binary to stop working. The sudo command will still work as usual.

The above change does not persist across reboots and must be applied after each reboot.


4. Once the new fixed packages are installed, the systemtap script can be removed by killing the systemtap process. For example, by using:

# kill -s SIGTERM 7590 (where 7590 is the PID of the systemtap process)

[.oisyn]

Misschien dat iemand met meer in-depth kennis van het Linux OS me kan toelichten, maar ik snap hier dus helemaal niets van. Sudo is gewoon een user-applicatie, right? Ik neem aan dat het toekennen van root-rechten op kernel-niveau is geregeld. Hoe kan een bug in een user-applicatie er dan voor zorgen dat privileges escaleren zonder root wachtwoord? En wat houdt mij tegen om zelf en buggy sudo te compileren en dat te runnen?

Het kan niet anders dan dat ik ernaast zit, maar als ik het artikel of de bron lees dan zie ik het niet .

[wica]

Jouw buggy sudo versie heeft niet de setuid rechten, wat het mogelijk zou maken het te draaien als de user van wie het bestand is. door een andere gebruiker.
https://en.wikipedia.org/wiki/Setuid

`---s--x--x. 1 root root 147336 Apr 1 2020 /usr/bin/sudo`
Heeft dus wel de +s (setuid) en mag door iedereen uitgevoerd worden, de +x.

Het programma sudo (wat als root draait) controleert of jij volgens de config, wel de rechten hebt op het uit te voeren.

[.oisyn]

Aaah op die fiets. Helder, bedankt

[hackerhater]

sudo is een applicatie/commando om andere commando's als root te kunnen uitvoeren.
De Windows-variant zou gok ik "Run As" zijn.

Per gebruiker kan ingesteld worden wat die gebruiker met sudo mag. Het kan alles zijn (en dus effectief een soort root-user) of maar een bepaald ding zoals developers die de test-webserver mogen herstarten.

Het grote voordeel van sudo over het root-account gebruiken is dat sudo het wachtwoord van de betreffende gebruiker wilt en je dus het root-wachtwoord niet hoeft te delen.

[.oisyn]

Nou ia, het is niet vergelijkbaar met Run As, want daarvoor heb je gewoon de credentials nodig van de betreffende user. En daar zit dan ook het essentiele verschil, uiteindelijk komt het neer op een kernel API functie die uiteindelijk het andere proces runt als de credentials kloppen.

Hier betreft het een user-applicatie die op eigen houtje de escalatie doet, en dus zelf ook de controle doet. Het ding wat ik miste, is dat je dus op filesystem-niveau kunt instellen dat een executable altijd onder een specifieke user runt, ongeacht wie het aanroept. En sudo runt dus altijd als root.

[Oliekoets]

Sudo runt inderdaad altijd als root. Je kan echter ook op applicatie niveau instellen welke app als welke user draait. Anders was een commando als Sudo onmogelijk

De Run-As variant van hackerhater zou in linux termen "su" zijn, hierbij heb je wel het wachtwoord van de andere gebruiker nodig , su root -> root's ww.

[Anoniem: 30722]

Vandaar dat er een update was vanmorgen