Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Linux-distributies patchen sudo-lek dat roottoegang geeft

Door , 93 reacties, submitter: Reinder83

Onderzoekers van beveiligingsbedrijf Qualys hebben een kwetsbaarheid in sudo ontdekt waarmee een lokale aanvaller op de lijst van sudoers rootrechten kan verkrijgen op een kwetsbaar systeem. Er zijn inmiddels patches beschikbaar.

rootQualys beschrijft de kwetsbaarheid met kenmerk CVE-2017-1000367 op de Openwall-mailinglijst. De methode werkt op een systeem waar de beveiligingsmodule SELinux is ingeschakeld. Daar kan een aanvaller via een commando dat hem geen rootrechten geeft, bestanden op het systeem overschrijven, inclusief bestanden die zijn toegewezen aan root. Daarbij is te denken aan bestanden als /etc/shadow of /etc/sudoers.

Sudo is een onderdeel dat is bedoeld om bepaalde gebruikers rechten toe te wijzen om programma's met rootrechten uit te voeren. Deze kwetsbaarheid stelt elke gebruiker met sudo-rechten in staat om zijn rechten te verhogen naar root. Verschillende distributies hebben patches uitgebracht, waaronder Debian, Ubuntu 17.04, 16.10, 16.04 lts en 14.04 lts, en Red Hat. Een overzicht van getroffen systemen is eveneens beschikbaar. Kwetsbare versies van sudo zijn 1.8.6p7 tot en met 1.8.20. In de verschillende advisories wordt aangeraden een update uit te voeren.

Sander van Voorst

Nieuwsredacteur

31 mei 2017 14:27

93 reacties

Submitter: Reinder83

Linkedin Google+

Reacties (93)

Wijzig sortering
To exploit this vulnerability, we:
• create a directory "/dev/shm/_tmp" (to work around /proc/sys/fs/protected_symlinks), and a symlink "/dev/shm/_tmp/_tty" to a non-existent pty "/dev/pts/57", whose device number is 34873;
• run Sudo through a symlink "/dev/shm/_tmp/ 34873 " that spoofs the device number of this non-existent pty;
• set the flag CD_RBAC_ENABLED through the command-line option "-r role" (where "role" can be our current role, for example "unconfined_r");
• monitor our directory "/dev/shm/_tmp" (for an IN_OPEN inotify event) and wait until Sudo opendir()s it (because sudo_ttyname_dev() cannot find our non-existent pty in "/dev/pts/");
• SIGSTOP Sudo, call openpty() until it creates our non-existent pty, and SIGCONT Sudo;
• monitor our directory "/dev/shm/_tmp" (for an IN_CLOSE_NOWRITE inotify event) and wait until Sudo closedir()s it;
• SIGSTOP Sudo, replace the symlink "/dev/shm/_tmp/_tty" to our now-existent pty with a symlink to the file that we want to overwrite (for example "/etc/passwd"), and SIGCONT Sudo;
• control the output of the command executed by Sudo (the output that overwrites "/etc/passwd"):
- either through a command-specific method;
- or through a general method such as "--\nHELLO\nWORLD\n" (by default, getopt() prints an error message to stderr if it does not recognize an option character).

http://www.openwall.com/lists/oss-security/2017/05/30/16

simpel(er) scriptje om te testen volgt

Op diezelfde mailing list: :Y) :+
Hanno Böck > Did Mitre really just add multiple new digits to CVEs or is this a typo? AFAIR they introduced 5-digit-CVEs relatively recently, going to > 7-digit without any public announcement seems unlikely.
kseifried Redhat> We did this 3 years ago

https://cve.mitre.org/cve/identifiers/syntaxchange.html

[Reactie gewijzigd door himlims_ op 31 mei 2017 14:54]

Is in Linux /dev dan world writable? Dat lijkt me sowieso een issue.
/dev is niet schrijfbaar voor gewone gebruikers, maar /dev/shm is dat wel: Gewone gebruikers mogen geheugen delen tussen programma's. Daar is niets mis mee. Een mogelijkheid daar geen symlinks te kunnen plaatsen zou in dit geval wel geholpen hebben, maar omdat /dev/shm in principe een gewoon bestandssysteem is, kan je daar ook symlinks plaatsen, daar zou nog eens over nagedacht kunnen worden. Het is verder gewoon een bug in sudo, zo simpel als dat.
Gelukkig gebruik ik nooit sudo, al is dat tegenwoordig mode onder Linux. Eerste wat ik op een nieuwe VM doe is /etc/passwd en /etc/shadow editen om gewoon su te kunnen gebruiken.
Want root login toestaan via shadow passwords is natuurlijk zooo veel veiliger... |:(
Nou, vaak wordt sudo zo ingesteld dat je met een "sudo su -" direct root bent, zonder dat nog een wachtwoord gevraagd wordt. Een su - waarbij je een wachtwoord invoert, of dat nu via shadow is of een ander mechanisme, is dan inderdaad heel veel veiliger.

De veiligste methode is een SSH-sleutel met passphrase.
Ja, en met "sudo -i" krijg je ook een root shell. Soms is een root shell gewoon nodig. Het grote verschil is dat als je gewone root login toestaat, je dit gelijk via alles kunt doen. Directe root login via ssh, terminal, X11, etc. Dat wil je helemaal niet. Zeker X11 niet. Beter om dan gewoon als normale gebruiker te werken en alleen die ene root shell te starten wanneer nodig.
Dat lijkt me niet juist, wil je root via ssh toestaan dan moet je bijvoorbeeld eerst permitrootlogin in de ssh-configuratie aanzetten. De /etc/securetty is een andere beperking die regelt waar root kan inloggen. X11 wordt in de meeste distributies standaard toegestaan, wat me logisch lijkt, want als je via X11 kan inloggen, dan kan je ook ctrl+alt+f1 doen om op tty1 in te loggen. Zo je wilt kan dat ook geblokkeerd worden.

[Reactie gewijzigd door dmantione op 1 juni 2017 09:00]

En zo moet je dus ieder systeem apart gaan blokkeren. Degenen die je opnoemt zijn er maar een paar. Er zijn nog veel meer systemen waar je op in kunt loggen en hun eigen methodes er op na houden. Wat als je bv een FTP server nodig hebt? Misschien redelijk antiek maar bij ons hebben we die nog steeds nodig omdat er derde partijen zijn waar we mee samenwerken die ons bestanden aanleveren en nog in 1998 leven en niets anders ondersteunen (ook geen SFTP). Zo'n FTP server kan dan ook ineens inloggen als root, want die doet niets met sshd_config of securetty, en heeft ook nog eens geen bescherming tegen bruteforce.

Overigens heeft PermitRootLogin nog lang standaard enabled gestaan. Tegenwoordig is de default gelukkig om alleen login via ssh-key toe te staan, maar dat is dus alleen als je een moderne distributie hebt. Als je om een of andere reden nog CentOS 6 draait, is dit de default:
PermitRootLogin
Specifies whether root can log in using ssh(1). The argument must be “yes”, “without-password”, “forced-commands-only”, or “no”. The default is “yes”.
[edit:] Mijn punt was dus niet dat je meteen via ssh in kunt loggen ofzo (dus mogelijkheden in de sshd config om het te blokkeren doen er eigenlijk niet toe voor mijn punt), maar dat je een onbekend aantal login mogelijkheden open zet (vooral op desktopsystemen met meer services) en de kans erg groot is dat je zelf onveiligheden aan het introduceren bent. Moderne distro's gebruiken niet voor niets sudo. Niet omdat ze zo graag extra componenten onderhouden maar omdat directe root login gewoon niet veilig is.

[Reactie gewijzigd door kozue op 1 juni 2017 09:22]

Ook dat is dan weer niet waar, als je centraal wilt blokkeren dan kan dat via /etc/pam.d, alleen kiezen de meeste distributies ervoor het in de configuratie van de service te doen. Die zullen een ftp-server dan ook standaard zo configureren dat root niet toegestaan is, hoef je je niet druk over maken, dubbelchecken kan natuurlijk nooit kwaad. En ftp blijft natuurlijk onveilig om andere redenen.
En su werkt ook via pam, dus als je het daar globaal blokkeert kun je root net zo goed helemaal uitzetten :+

En je hebt het nog steeds niet begrepen. De FTP server was een voorbeeld (niet een reden op zichzelf), er zijn nog honderden services die iets via netwerk doen met useraccounts. Wil je er nog een? Samba wordt ook op iedere desktop-distributie standaard geïnstalleerd om het handig te maken voor Windows gebruikers of in een Windows-netwerk. Wil je dat andere computers bestanden kunnen uploaden als root naar die van jou als jij je configuratie niet in orde hebt?

En ja, je zal root login in de meeste FTP server configuraties kunnen blokkeren, maar dat is dus precies wat ik bedoelde: je moet het voor iedere service los doen. En dan vergeet je er altijd wel een. Beter om helemaal geen root login toe te staan.
Ik neem aan dat je weet hoe je PAM goed moet configureren, zo niet:

lentebloem:/etc/pam.d # cat /etc/pam.d/su
#%PAM-1.0
auth sufficient pam_rootok.so
auth include common-auth
account sufficient pam_rootok.so
account include common-account
password include common-password
session include common-session
session optional pam_xauth.so

Kopieer de /etc/common-auth, verwijs in de /etc/pam.d/su naar het gekopieerde bestand en zorg dat je in de originele /etc/pam.d/common-auth root blokkeert.
passwordless login SSH is veiliger (public key)
SSH-sleutel passphrase is dus een wachtwoordloze login, maar met een wachtwoord om de public-key te ontcijferen, zodat als iemand toegang weet te krijgen tot een account waarvan de sleutel toegang tot root geeft, niet direct ook de sleutel kan gebruiken om als root in te loggen.
[sarcasme]
waarom nog su - gebruiken.
Ik zou gewoon direct root inloggen als je toch lekker bezig bent.
en het beste password voor root is natuurlijk 123456 of r00t.
Mooie is wel dat als hij direct aan internet hangt je een mooi onderdeel wordt van een botnet met alle voordelen van dien.

btw firewalls zijn voor mensen die iets te verbergen hebben 8)7
En als we dan toch lekker aan het pielen zijn ... gebruik gewoon telnet want als dat onveilig was hadden ze het er allang uit gehaald. 8)7
[/sarcasme]
De VM die ik ooit downloade voor gebruik in de clud had als root password "toor". Heb ik toch maar aangepast.
Dat je het nooit gebruikt wil natuurlijk niet zeggen dan anderen het niet kunnen gebruiken of misbruiken. In jouw geval kun je sudo het beste verwijderen als je het toch niet nodig hebt.
Op zich niet. /dev is de plaats waar linux drivers hun "virtuele" bestanden plaatst. Een bekend bestand is bijvoorbeeld /dev/sda1, wat letterlijk de hele binary output is de eerste parties in /dev/sda. Zou wel een beetje vervelend zijn als we daar niet zouden kunnen schrijven ;).

Ik ben dit niet zeker, maar de permissions worden ook door de drivers bepaald. Niet dat het veel uitmaakt sinds deze bestanden niet op de schijf staan.
Onzin natuurlijk. Geen enkel weldenkend persoon zou willen dat een normale gebruiker rechtstreeks willekeurige sectoren op de disk kan overschrijven. Daarmee zou je iedere bit aan kunnen passen, inclusief de kernel en de shell. /dev/sda1 is dan ook een goed voorbeeld van een device waar een gebruiker *geen* rechten op heeft.
Het schrijven en lezen van bestanden op de disk gaat immers via de filesystem driver (bv ext4), die een bestandssysteem aanbiedt op een mount point. Deze zit tussen het device en de gebruiker in, en dwingt o.a. permissies en andere access policies af.

Maar behalve je belabberde voorbeeld heb je wel gelijk in dat /dev niet alleen voor root is. Er zijn genoeg devices die wel door de gebruiker volledig benaderbaar zijn. Denk bv aan webcams of audioapparaten. Het zou vervelend zijn als je iedere keer als root in moest loggen om een mp3tje af te spelen.
Maar veel device access is erg distro-afhankelijk. Sommigen zetten voor het gebruiksgemak alles open, en bij anderen heb je speciale groepen waar je in moet zitten om bepaalde acties uit te kunnen voeren (bv een groep 'cdrom' om optische media te kunnen mounten). Ook gaan sommige devices tegenwoordig via daemons, die zelf misschien als root draaien om bij het device te kunnen en een api of service aanbieden aan normale gebruikers (bv cups voor printers).
Een wille gebruiker kan gewoon "touch test" op zijn home folder doen en ie kan al schrijven. Maar natuurlijk gebeurt dit door de driver, ik wou het gewoon eenvoudig houden ;). Maar in essentie als je een file maakt, wordt /dev/sda1 toch beschreven?
Net Linux Mint opgestart en krijg de melding van updatebeheer dat ook deze distro kwetsbaar is voor het sudo-lek, hoewel deze distro niet in de lijst van kwetsbare systemen staat.
Het gaat om Linux Mint 18.1 Cinnamon 64bit
Linux Mint is gebaseerd op Ubuntu
CentOS staat niet op de lijst, terwijl deze wel SElinux heeft. Welk onderdeel van deze distro beschermt men tegen deze exploit dan?
Aangezien CentOS gebaseerd is op RHEL is, en RHEL (en Fedora) wel op de lijst staan denk ik eigenlijk dat het een fout is in de berichtgeving en dat CentOS ook vatbaar is.
Dat lijkt mij ook inderdaad. Gewoon 'vergeten' ertussen te zetten gezin zoals je al zegt CentOs deel uitmaakt van de RedHat familie.
Ik krijg net wel updates voor sudo binnen op CentOS 7;

1.8.6p7-22.el7_3
Ik begreep het artikel in eerste instantie niet goed, omdat ik dacht: "Als iemand al sudoer is, heeft hij/zij toch al root-rechten? Dus wat voegt de aanval dan nog toe?"

Voor anderen die wellicht hetzelfde dachten als ik, het antwoord was te vinden in de bron:
On an SELinux-enabled system, if a user is Sudoer for a command that does not grant him full root privileges, he can overwrite any file on the filesystem (including root-owned files)
(emphasis mine)

m.a.w.: als je een subset van sudo-rechten hebt kon je door de kwetsbaarheid volledige sudo-rechten krijgen.

[Reactie gewijzigd door ChillinR op 31 mei 2017 14:51]

Jup. Voor een doorsnee thuis-installatie dus niet zo interessant, dan is er een gebruiker (ikke) die volledige sudo rechten heeft, en de eventuele kinderen hebben dat gewoon niet. Dan valt er niks te promoten.
Natuurlijk wel want ze hebben hardware access. Of is je schijf versleuteld? Indien niet, even booten vanaf CD / USB en de boel direct aanpassen.
Als je je kinderen niet vertrouwt kun je altijd de boot sequence locken naar alleen hdd en een password op de bios zetten. Ja, dan kunnen ze de disk er nog uithalen en in een andere computer steken, maar als je kinderen hebt die dat soort streken uithalen met een computer die niet van hun is heb je denk ik grotere problemen dan ongeauthoriseerde root toegang...
De controledrift van sommige ouders kweekt hackers.
Ik begrijp je reactie wel, maar als je Physical Access hebt dan veranderen de spelregels toch echt wel enorm.
Het is echt wel appelen met peren vergelijken;
Zo'n soort ingrepen vallen echt wel véél meer op als ergens veilig remote een paar commandotjes uit te voeren.
Is de versie in macOS dan ook kwetsbaar? Lijkt me wel.
Dit is bij mij: Sudo version 1.8.17p1
En zou dus in de onveilige range vallen.

[Reactie gewijzigd door air2 op 31 mei 2017 14:30]

SUSE Linux Enterprise Software Development Kit 12 SP1
SUSE Linux Enterprise Software Development Kit 12 SP2
SUSE OpenStack Cloud 7
Canonical Ubuntu Linux 14.04 LTS
Canonical Ubuntu Linux 16.04 LTS
Canonical Ubuntu Linux 16.10
Canonical Ubuntu Linux 17.04
Debian Linux 8.8 Jessie
openSUSE Leap 42.2
SUSE Linux Enterprise Desktop 12 SP1
SUSE Linux Enterprise Desktop 12 SP2
SUSE Linux Enterprise Server 12 LTSS
SUSE Linux Enterprise Server for SAP 12
SUSE Linux Enterprise Server 12 SP1
SUSE Linux Enterprise Server 12 SP2
SUSE Linux Enterprise Server 12 SP2 for Raspberry Pi
Oracle Linux 6
Oracle Linux 7
Oracle VM Server 3.3
Oracle VM Server 3.4
Red Hat Enterprise Linux 5 Extended Lifecycle Support
Red Hat Enterprise Linux Desktop 6
Red Hat Enterprise Linux Desktop 7
Red Hat Enterprise Linux HPC Node 6
Red Hat Enterprise Linux HPC Node 7
Red Hat Enterprise Linux Server 6
Red Hat Enterprise Linux Server 7
Red Hat Enterprise Linux Server 7.3 TUS
Red Hat Enterprise Linux Workstation 6
Red Hat Enterprise Linux Workstation 7
Red Hat Fedora 24
Red Hat Fedora 25
Red Hat Fedora 26

Dit zijn de getroffen systemen.
Ik denk niet dat jij je zorgen hoeft te maken
Mijn ubuntu 16.04 moest ik updaten naar 1.8.16 en daarmee was ik al veilig.(wat al lager is dan jou versie.)
Zet Arch-based distro's er ook maar als verdachte bij, want daar is ineens een update voor verschenen in de core repo's.
Als de focus op Linux lag bij het maken van die lijst zal OS X er niet in staan, maar wel kwetsbaar zijn. Windows draait tenslotte ook sudo tegenwoordig, van bv Ubuntu, Fedora of Suse, maar staat er ook niet bij.

De versie zegt overigens niks. Vaak leveren distro's een custom versie met eigen patches. Dan is het een soort 1.8.16+. Kan best zijn dat ze de fix gebackport hebben naar .16 omdat ze het riskant vonden om te upgraden naar .20.
Hier ook 1.8.17p1 (macOS 10.12.5). Maar mijn Ubuntu laptopje heeft de update nog niet gekregen en staat op 1.8.16 (16.04 LTS, week geleden geïnstalleerd)
De LTS versie werkt niet met de laatste versies van programma's maar voert wel benodigde security updates door. De 1.8.16 versie op Ubuntu heet volledig 1.8.16-0ubuntu1.4. Het gedeelte erachter geeft aan welke versie van Ubuntu patches extra zijn applied op versie 1.8.16. De link hieronder van Canonical geeft ook aan dat 1.8.16 veilig is.

https://people.canonical....017/CVE-2017-1000367.html
Nee, want macOS gebruikt niet SELinux maar SIP.
SELinux en System Integrity Protection hebben alleen wel volledig verschillende doelen. Het eerste is een implementatie van Mandatory Access Control wat programma's toegang geeft (of weigert) tot resources, terwijl het tweede het systeem zelf beschermt tegen ongeautoriseerde wijzigingen.

Dat gezegd hebbende heeft macOS natuurlijk inderdaad geen SELinux.
Nee, natuurlijk is SIP geen MAC, volgens mij wordt MAC met entitlements en sandboxing afgehandeld (i.c.m. codesigning zodat je niet stiekem eigen entitlements kan toevoegen als developer). Maar dan ook weer in combinatie met gatekeeper zodat het daadwerkelijk gebeurt. SIP kan je niet zonder reboot uitzetten of 'omzeilen' tot zo ver, ik bedoelde dus dat stel dat je op macOS root bent, je nog steeds je systeem niet kan aanpassen, of in elk geval niet 'meer' dan een admin.
Maar het is een bug in sudo en niet in SELinux. Ze bedoelen te zeggen dat ook als je SELinux ingeschakeld hebt, de exploit werkt. Tenzij SIP dit, in tegenstelling tot SELinux, wel tegenhoudt, zou het dus wel goed kunnen dat macOS kwetsbaar is.
Nee, want er wordt dus niet gebruik gemaakt van de Linux kernel. Er is geen /dev/shm en geen /proc en alle pty's worden op boot time gemaakt waardoor die 'nonexistent' pty er niet is (en dus ook niet op een random dev node terecht komt).

Daarnaast zijn de sudo versies niet hetzelfde, (op macOS wordt een gepatchte versie gebruikt), is openpty() niet hetzelfde (GNU versie vs. BSD versie) en zelfs dan zou er nog een race condition gewonnen moeten worden zodat je de SIGSTOP op het juiste moment te pakken krijgt.

Op Linux werkt dat om dat je zonder meer PTY's, devnodes, en signals kan sturen, op macOS kan dat niet tenzij je een admin bent. Maar dan ben je dus al admin en kan je sudo sowieso al uitvoeren.
SE linux zou ook raar zijn want MacOS is een *BSD afgeleide (FreeBSD dacht ik)
De voorloper van MacOS (NextSTEP) is afgeleid van BSD (zelfde variant als waar FreeBSD vanaf geleid is). Echter is MacOS zelf afgeleid van zowel de NextSTEP als FreeBSD. Dus ja, MacOS is afgeleid van FreeBSD.
MacOS userland is gebaseerd op FreeBSD, als je wat dieper gaat kijken is het echter volledig verschillend. De hele hardware abstraction layer (IOKit bij MacOS) is bijvoorbeeld anders. Anders zou je bijvoorbeeld MacOS drivers kunnen gebruiken onder FreeBSD, dan kan helaas niet ;(
Natuurlijk is het verschillend, die fork heeft vele jaren geleden plaatsgevonden.

Dat ze anders werken, anders in elkaar zitten en niet samen compatible zijn met alles, zegt helemaal niets.

Bijvoorbeeld, zowel Edge als Firefox zijn oorsprongkelijk beide gebaseerd op de Mosaic browser. IE5 en Netscape leken al niet op elkaar, hadden totaal verschillende code en ondersteunden elkaars features niet (marquee/blink, jeuj)
De kunst is dat NeXTSTEP/MacOS geen fork is van BSD. Bij een fork begin je met dezelfde basis en groei je later uit elkaar. Bij MacOS begonnen ze juist verschillend en zijn ze later dichter bij elkaar gekomen toen een deel van de BSD userland werd overgenomen door NeXTSTEP en delen van NeXTSTEP's Mach kernel werden overgomen door BSD.

NeXTSTEP, de voorloper van MacOS, gebruikte al de Mach Kernel waar later stukken code van BSD bovenop zijn geplaatst, dat is niet echt een fork. We noemen WindowsNT ook geen fork van BSD omdat de networkstack oorspronkelijk van BSD komt.
Ik tikte fork ook meer in om het kort door de bocht te zeggen naar maurits :)

Die BSD netwerk stack in Windows is overigens met Windows 8 vervangen door MS hun eigen code ;)
Je hebt gelijk, allleen als je verder gaat kom je bij BSD als voorloper voor zowel Next als FBSD. Kwestie van interpretatie denk ik, want je zou ook AT&T UNICS kunnen zeggen.
Mijn keuze voor BSD komt voort uit het back tracken van de lijntjes naar de eeste gemeenschappelijk parent obv de gelinkte tree.
? Is macOS uitgerust met SELinux? Lijkt me juist niet.
Maar als je als gebruiker al op de sudoers-list staat. Hoeveel meer rechten krijg je dan als je root rechten aan jezelf kunt toewijzen?
Je kunt sudo-rechten beperken tot bepaalde executables, of bijv. dat iemand zich als een andere gebruiker mag voordoen. Met deze bug kan zo iemand zichzelf dus méér rechten geven.
Maar wanneer ik een verse Elementary of Ubuntu installatie heb, zijn daar dan ook al beperkingen opgelegd aan de sudo-mogelijkheden? Of staat het dan (min of meer) gelijk aan root-rechten.
Dan staat het voor zover ik weet gelijk aan root-rechten. Je kan bij een standaardinstallatie zonder problemen sudo su doen, waarna je in een root-shell terecht komt, dus kan je alles.

[Reactie gewijzigd door ChillinR op 31 mei 2017 14:54]

sudo su -, anders sluit de shell meteen weer. :)
Nee hoor, de "-" op het eind geeft aan dat je ook nieuwe lege Shell variabelen wilt, en niet die van de originele user wilt gebruiken
Ik gebruik altijd `sudo -i` voor een root shell. Wat is het verschil tussen die twee methodes?
Als je 'sudo -l' ingeeft verschijnt een lijst wat de huidige gebruiker als wie op welke machine mag doen. Er verschijnt dan NOPASSWD als hiervoor geen password nodig is. Zelf stel ik (ook op Ubuntu) meestal in dat een root paswoord nodig is voor sudo, zoals in Gentoo en OpenBSD.
Het laatste, het eerste account heeft met ubuntu alle sudo rechten.
Met debian weer niet, daar heb je alleen root en gewone gebruiker zonder sudo rechten.
sudo kan gebruikt worden om gebruikers beperkte toegang te geven (alleen bepaalde commando's uitvoeren als root, bijvoorbeeld). Met deze kwetsbaarheid kunnen zulke gebruikers opeens bestanden overschrijven alsof ze root zijn, wat niet de bedoeling was.
.. en als je daarmee je sudoers file aanpast/overschrijft, kun je dus voortaan als gewone gebruiker een sudo su - doen en ben je automatisch root zonder password. Als je de syntax weet natuurlijk. Iets met NOPASSWD:ALL of zo.

[Reactie gewijzigd door DigitalExcorcist op 31 mei 2017 15:49]

Niet mega spannend imho, aangezien je dus al lokaal toegang moet hebben tot het systeem. Risico lijkt mij redelijk beperkt gelukkig (in onze situatie ieder geval)
Lokaal toegang = fysiek bij het systeem aanwezig zijn. Daar is inderdaad niets tegen opgewassen, tenzij daar juist rekening mee gehouden wordt en zelfs dan nog is het vrij lastig alles goed dicht te timmeren.

Hierbij kan elk account wat een sudo recht of meer heeft, het systeem geheel overnemen.
Nee lokaal toegang is dat je al een account moet hebben op de machine.
Fysieke toegang, ja daar helpt niks tegen.
Lokale of fysieke toegang komen op hetzelfde neer. Lokaal, local, localhost. localhost kan je ook niet vanaf afstand benaderen.


Fysieke toegang gaat wat verder. Je hebt lokaal toegang tot een pin automaat zodat je kan pinnen, maar geen fysieke toegang, tenzij je een roemeense bandiet bent en de bank heeft weer remote toegang.

Fysiek toegang tot een desktop of server houdt eigenlijk in dat je de case open kan trekken.

Lokaal toegang is dat je direct input kan geven op het systeem dmv keyboard/muis/touch of zelfs USB sticks in het ding kan proppen.

[Reactie gewijzigd door batjes op 31 mei 2017 17:34]

'De methode werkt op een systeem waar de beveiligingsmodule SELinux is ingeschakeld': wordt hiermee bedoeld dat ondanks dat SELinux is ingeschakeld het werkt of dat er door deze module dit mogelijk is?
Het stukje over SELinux staat expliciet benoemd omdat het draaien van SELinux bij deze exploit geen verschil maakt.

Het werkt dus, ondanks dat je SELinux hebt ingeschakeld. Anders gezegd, de vulnerability zit puur in sudo. Nog anders gezegd, systemen die geen SELinux draaien zijn net zo kwetsbaar.
Mijn ubuntu 14.04 servers krijgen de update anders niet binnen. Laatste versie is 1.8.9p5, dus lijkt mij ook niet goed.
$ sudo --version
Sudo version 1.8.9p5
Sudoers policy plugin version 1.8.9p5
Sudoers file grammar version 43
Sudoers I/O plugin version 1.8.9p5

[Reactie gewijzigd door Yzord op 31 mei 2017 17:13]

Check even welke versie je exact hebt:
dpkg -l | grep sudo
Staat daar '1.8.9p5-1ubuntu1.4' dan ben je up to date. Zie release notes.

Voor de laatste Ubuntu 17.04 (Zesty) moet dat '1.8.19p1-1ubuntu1.1' zijn.

edit:
punt in versie vergeten

[Reactie gewijzigd door FvdM op 31 mei 2017 23:48]

Ik gebruik Jessie light voor PiHole. Volgens mij valt deze dan ook onder het lijstje (Debian Linux 8.8 Jessie).

Moet ik mij als niet-ICT ook zorgen maken over deze lek? Is het een kwestie van Linux Jessie light updaten en ik ben weer up-to-date qua beveiliging?
Normaal gesproken wel. Echter zit ik op Kubuntu 16.04, en daar heb ik nog 1.8.16. Wat overeen komt met de candidate als ik kijk bij apt-cache policy sudo

edit: oh wacht. Ubuntu heeft de fix zelf doorgevoerd in de laatste versie in hun repro. op 1.8.16-0ubuntu1.4 kom ik dan uit.

[Reactie gewijzigd door pizzafried op 31 mei 2017 23:07]

Doet me ernstig denken aan het probleem dat in in Windows XP bestond, waarbij het technisch mogelijk werd voor een Power User om local Administrator rechten te krijgen, eigenlijk op een vergelijkbare manier. (Overschrijven van essentiële bestanden.)
Dit mechanisme wordt leuk beschreven in deze historische Blog.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*