Uiteraard is er nog geen patch voorhanden, die komt pas op zijn vroegst op dinsdag 11 september.

11 september is net te laat voor een patch ;)

Mijn PC wordt door niemand anders gebruikt dus voor mij geen probleem.
Ik vind het toch niet prettig om mijn PC met iemand anders te delen. Maar dat heb ik al met mijn fiets uitlenen :-)

Ik heb de PoC in handen gekregen.
De detectiegraad bij virusscanners is erg laag: 1/57 op dit moment.

In de repo op https://github.com/SandboxEscaper/randomrepo zit in PoC-LPE.rar ook een demo.mp4 waarin de kwetsbaarheid gedemonstreerd wordt en een Write-up.docx waarin het uitgebreid wordt uitgelegd, ik vond ze beiden de moeite waard om te bekijken en te lezen.

Dit is een exploit om UAC te omzeilen en hogere rechten te krijgen. Heeft niets met andere gebruikers te maken.

Wel heel belangrijk voor iedereen die en Citrix omgeving beheert. Geen idee wat de Windows Taakplanner is. Maar als je het uit kunt zetten in je Citrix omgeving dan lijkt me dat te adviseren.

Is dit remote bruikbaar of alleen lokaal?

De windows taakplanner is zoiets als cron/crontab. Het cron proces draait onder root.... Bedoeld voor systeembeheerstaken.
Ik heb me altijd verbaasd dat er zoveel services en werkzaamheden onder hoogste privileges draaien. Ongeacht het OS.
Ja het werkt. Ja het zet de deur open voor verkeerde handelingen.
Hoe wil je een volledige backup in je taakplanner/scheduler hebben zonder hoogste privileges.

Ik kan de frustratie van SandboxEscaper in zijn tweet wel begrijpen. Hopelijk heeft het niet te veel gevolgen voor hem/haar.
APLC/LPC stond nog op mijn studeer todo lijstje dus bedankt voor het materiaal :-)

Dat klopt niet hoor (zoals het meeste wat jij zegt).
Als je als user een taak maakt met cron of de taakplanner dan draait die default onder je eigen user ID en dus credentials.
Wil je dat anders dan zul je dat moeten regelen in een speciale optie en daarvoor moet je het wachtwoord weten van
de user die je wilt gebruiken, of je moet iets regelen met sudo oid. En dat kan alleen als je al admin bent.
Wil je een backup kunnen schedulen dan moet je dus admin zijn dan wel het wachtwoord weten van admin of een andere
user met voldoende privileges.
Uiteraard kunnen er bugs in zitten maar het is echt niet zo dat alles als root of admin draait.

Het meeste wat ik zeg klopt al heb je het niet zo snel door.
De master taak cron draait wel degelijk onder root. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-automating_system_tasks
Je kan het zo inregelen (configuratie settings) dat normale gebruikers ook dat ding kunnen gebruiken.

Voor gewone gebruikers is het niet echt zinvol. Je wilt vaak een bepaalde taak als high-privilege gebruiker laten lopen.
Dat high privileged is niet zo maar root. Een goed opgezet systeem (functies niet de doos) kent beheerders voor bepaalde taken/werkzaamheden in een soort container (nee niet docker).


Als root niet de Admin is en de gewone gebruiker ook niet, wie is dat dan wel? Ken je de iso27002 en bir-tnk, die aanwijzingen dat je dat moet regelen staan er. Wat er niet staat is hoe het voor elke techniek in detail opgelost moet worden.

Al in november 2017 over gepubliceerd misbruik van ShellExecuteA API in aplc. Project zero exploitatie.

je hebt dus geen idee wat de "Windows Taakplanner" is, maar het is wel heel belangrijk voor een Citrix omgeving.

Hoe trek je deze conclusie precies?

Deze bug staat al langer open en is ook toen niet gefixed:
https://forum.rehips.com/index.php?topic=9515.0

Dit gelezen in de draad erover op Tweakers aangaande het tegenhouden van het lek:

Info credits gaan naar Karsten88 (dank, dank voor de temp. fix ;))

luntrus

P.S. Ik snap toch niet waarom iedereen niet standaard met gewone user rechten werkt, als het niet strik anders hoeft.
Maar dat is een open deur intrappen bij elke admin.

Dank je wel voor de aanvulling / verbetering.
Ik dacht dat het ging dat andere gebruikers de systeemrechten van mijn PC konden krijgen.

Als je die pagina leest zie je hoe een andere user dan root opgegeven kan worden. Jobs hoeven niet als root te draaien. In de man page van crontab(5) staat het ook gewoon. En dat gaat niet alleen over gewone users, ook systeem-users kunnen gebruikt worden.

In de manual page van het commando crontab(1) staat een andere mogelijkheid:
Hiermee edit user root de per-user crontab van systeemuser www-data. Die wordt opgeslagen in /var/spool/cron/crontabs.

De hoofdtaak van cron moet in staat zijn jobs als root op te starten en als elke andere user. Dat onder iets anders dan root laten draaien is zinloos, als rechten van elke user bereikbaar zijn en moeten zijn dan kan dat proces effectief alles voor elkaar krijgen. Het niet onder root draaien ervan zou een schijnbeveiliging zijn, een minimaal hobbeltje dat makkelijk te nemen is.

Jij hebt het van jouw kant weer niet zo snel door wanneer jij in incompleet of verkeerd beeld ergens van hebt, of als er andere manieren zijn om het te benaderen dan wat jij voorstaat die ook werken. Zelfs niet als je erop gewezen wordt.
Je stelt de vraag, maar geef ook eens antwoord? Een backupproces moet alle data kunnen benaderen waar een backup van gemaakt moet worden en op het backup-medium kunnen schrijven. Als je dat programma niet vertrouwen kan dan is de vertrouwelijkheid van al je data hoe dan ook aan gort en kan je je backups niet vertrouwen. Dus moet je dat programma wel kunnen vertrouwen. Wat blijft er dan voor bezwaar over om het als root te draaien?

"Het meeste wat ik zeg klopt al heb je het niet zo snel door."

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

btw

system_u:system_r:crond_t:s0-s0:c0.c1023 1 S root 7996 1 0 80 0 - 28748 hrtime Aug21 ? 00:00:07 crond

dus, iemand laat weer duidelijk zijn leeftijd en niet zijn wijsheid zien.

on topic:

het is verdraaid k*t dat er een PoC vrij is en dat dit pas over een tijd een patch zal hebben. net zo een leuke als deze was:

https://apple.slashdot.org/story/15/07/23/1543241/a-tweet-sized-exploit-can-get-root-on-os-x-1010

Ik heb het over de crond demon die draait onder root. Juist die doet een switch user context als om het niet om root gaat.
Met windows draait de overeenkomstige service onder localsystem als een van de aparte systeem admins.

Als je aan functiescheiding zou denken (iso27002 bir-tnk) kan je een database backup uitstekend scheiden van een machine backup en als je code business logica hebt kun je dat gekoppeld aan change management uitstekend scheiden van die andere logische functies. Waarom zou je alles onder root / local system account doen met alle risico's van dien als iemand onterecht toegang krijgt of gewoon een foutje maakt.

Met de vraag stellen waarom er een bezwaar zou zijn om het als root te draaien heb je tevens het antwoord gegeven waarom er zoveel mis gaat met informatieveiligheid. De risico analyse over welke informatie het gaat sla je over en je gaat voor het gemak omdat het wel werkt.

Niet elke admin want in elk geval niet bij mij ;-)

Maar het is, toegegeven, een wijd verbreid misverstand onder systeembeheerders dat je op elk systeem voortdurend maximale privileges zou moeten hebben om je werk te kunnen doen.

Aan de andere kant vermoed ik dat het hier om het zoveelste privilege escalation lek in taakplanner gaat dat ook gewoon werkt vanuit unprivileged accounts. Het fundamentele probleem is dat als jij niet interactief bent ingelogd, een dienst met system level privileges taken namens jou moet uitvoeren, en dus op dat moment de geldende privileges moet verlagen naar jouw niveau - terwijl de interactieve context ontbreekt. Dat vereist van begin af aan een goed doordachte aanpak, en die is er bij taakplanner nooit geweest; het is één grote lappendeken om maar compatibel te blijven met legacy meuk. En omdat Microsoft de balans tussen meer helpdeskcalls (o.a. als gevolg van functionaliteitswijzigingen) en onveiligheid altijd naar die laatste laat doorslaan, is de toekomst niet moeilijk te voorspellen.

Daar komt bij dat in de laatste major Windows versies steeds meer functionaliteit onder die (nog steeds brakke) taakplanner is geschoven. Waar deze onder NT4 er wellicht alleen voor zorgde dat antivirusdefinities werden gedownload en geïnstalleerd, kun je deze dienst nu zeker niet meer uitschakelen. Als ik me niet vergis lopen inlog- en uitlog scripts tegenwoordig ook vanuit dat ding. Noodzakelijke wijzigingen vanwege het zoveelste lek, zijn door het toenemende aantal afhankelijkheden steeds lastiger door te voeren. Geen wonder dat beveiligingsupdates steeds meer kapot maken dan je lief is...

Hoe vaak er karma4 ook naast zit, deze keer heeft hij wel gelijk. De cron deamon draait als root en heeft daarmee alle rechten.

@ Bitwiper,

Ben dat wel met je eens. Microsoft heeft steeds meer beheer functionaliteit uit handen van de eindgebruiker genomen.
De gehele volledige dos functionaliteit is al lang niet meer via command prompt te benaderen.

Dit dicht timmeren van de lagere regionen van propriety software samen met een flink stuk "security through obscurity" brengt ons bij de huidige situatie. Google doet op android iets gelijkaardigs en loopt voortdurend tegen gelijkaardige problemen aan. Mono-cultuur problemen natuurlijk.

Dat deert natuurlijk de met "1 click en 't moet werken" gebruikers geenszins en daarom besluit men tot een dergelijke uitruil
van functionaliteit ten koste van noodzakelijke beveiliging. Men bouwt het steeds weer van de grond toe op, hoor je dan bij elke nieuwe Microsoft versie, maar je zit dan nog steeds met dezelfde problemen, waardoor MS Windows nooit in de vorige eeuw zo aan het Internet had moeten worden gehangen. Zelfde verhaal als met JavaScript en de html problematiek. JavaScript was er ook nog niet klaar voor, Later blijft dit je bij alle verdere ontwikkelingen achtervolgen. De start was niet goed "period" oftwel klaar-punt-uit.

Neen, veiliger kunnen we het nu eenmaal niet maken. Andere zaken spelen zijdelings ook mee, het inpassen van Microsoft software binnen de USA Surveillance usance, maar dat is een geheel ander zijpad en valt een beetje buiten het kader wat we hier bespreken.

Wat we hier zien is gewoon inherent aan de aard van het beestje, het betreffend OS platform, en dit zal ons nog wel enige tijd parten blijven spelen. Ik wist al van deze opposities, toen ik destijds bij een officieel MS opleidingsbureau NT4 en de kernel deed te midden van linux mannetjes, die mij bitwijs moesten maken voor een goede uitrol en configuratie. Er is wat dat betreft nog niet veel nieuws onder de zon.

luntrus

Sarcasme of naïviteit?

Nope, deze exploit werkt naar verluidt (https://github.com/GossiTheDog/zeroday/blob/master/ALPC-TaskSched-LPE/ALPC-TaskSched-LPE.cpp) zelfs voor Guest.

Hou nou eens je kop over zaken waar je geen verstand van hebt en ook nog eens jezelf in de voet schiet. Ja, zowel taakplanner als cron draaien met de hoogste privileges. Maar terwijl alleen root de file /etc/crontab kan wijzigen, heeft elke gebruiker (ook Guest) schrijfrechten in C:\Windows\Tasks\ (en/of C:\Windows\System32\Tasks\) en dat is exact waar deze exploit gebruik van maakt.

Voor een gebruiker bestaat een volledige backup uit al haar bestanden. Iets met functiescheiding uit ISO27002, BIR-TNK etc. (jouw typische riedeltje). Maar ook deze opmerkingen van mij zul je wel weer "pareren" met niet ter zake doende flapdrollerij.

Dat heeft hier niets mee te maken (behalve dat ook ALPC genoemd wordt).

Om te beginnen snap ik niet waarom o.a. filesystems en het register ACE's (voor uitleg van afko's zie https://docs.microsoft.com/en-us/windows/desktop/secauthz/access-control-lists) bevatten voor SYSTEM, want in mijn ervaring trekt SYSTEM zich daar niets van aan. Het toevoegen van een deny-ACE voor SYSTEM is dus, vermoed ik, zinloos.

Alle overige gebruikers hebben natuurlijk wel met toegangsrechten -vastgelegd in DACL's- te maken. Wat die eerste regel precies voor effect heeft, hangt af van of bestaande entries in c:\windows\tasks\ een protected DACL krijgen: in dat geval worden geen permissies van het parent object overgenomen, en in dat geval zou de truc van Karsten88 geen effect hebben op reeds bestaande entries - en zou je hooguit geen entries meer toe kunnen voegen. Maar ik weet niet zeker of iets die DACL's protected maakt.

Maar zelfs dan zou ik heel voorzichtig zijn met dit soort wijzigingen, want zoals ik in mijn vorige bijdrage schreef, is er in de laatste Windows versies steeds meer functionaliteit onder task manager geschoven (wellicht om gebruikers het gevoel te geven dat Windows sneller opstart in de hoop dat ze niet merken dat ze nog een halfbakken systeem hebben, vermoedelijk vooral op het punt van beveiliging, als ze er meteen mee aan de gang gaan).

Als je in Windows vanuit de kernel, die alles mag op een systeem, het pad volgt naar het equivalent van een cron job dan kom je onherroepelijk ook ergens een user context switch tegen. De code die dat doet vertrouw je kennelijk. In Windows is die code niet zichtbaar als een service, in Linux/Unix is die zichtbaar als de cron daemon. Je vindt dat ISO27002/BIF-TNK bij Windows geen probleem opleveren en bij Linux/Unix wel enkel omdat bij de laatste de switch in een service is ondergebracht. Waarom maakt dat zo'n groot verschil? Gaat het niet om de betrouwbaarheid van de implementatie zelf?

Je hebt hoe dan ook een basis van code nodig die je kan vertrouwen. Je hebt kennelijk de neiging om door de verschillende manieren waarop Windows en Unix/Linux het OS hebben georganiseerd equivalente functies in het ene OS wel tot die vertrouwde basis te rekenen en in het andere OS niet. Ik zie niet in waarom je op basis daarvan dingen zo verschillend zou beoordelen.
Het hele punt van die user context switch die cron doet is dat je niet alles onder root draait. Die database backup is uitstekend met een daarvoor bestemde user uit te voeren, ook als hij door cron gestart wordt. Dat is geen argument voor je bezwaar dat het cron-proces zelf als root draait.

Kul. Je doet de risicoanalyse zonder je systeem te begrijpen. Ergens op weg van de kernel naar een job die niet als root/admin draait ga je van alle mogelijke rechten naar beperkte rechten. Dat gebeurt hoe dan ook, het verschil is dat het ene OS het op een andere plek heeft ondergebracht dan het andere, met als gevolg dat de zichtbaarheid van waar het gebeurt ook verschilt. Maar het punt is dat het hoe dan ook gebeurt. Als je denkt dat ISO27002 en BIF-TNK toepasbaar zijn afhankelijk van de zichtbaarheid van een functie dan beoordeel je zaken niet vanuit begrip van wat er gebeurt maar pas je regeltjes toe zonder te begrijpen waar je ze op toepast.

Eerst werd het ontkend en nu geef je het aan. "zowel taakplanner als cron draaien met de hoogste privileges."
In een Enterprise omgeving hoort op een desktop geen data te staan en staat de taskmanager uit (groepspolicies onbruikbaar voor de gewone gebruikers). Backup wordt door de verschillende beheerders gedaan.

In een thuissituatie ben je en beheerder en gebruiker. De beheerder kan malware installeren
ja duh als je root hebt dan heb je root. Het is de stroman waarheid waar je niets aan hebt.

Heel eenvoudig als je Enterprises kent weet je dat er functiescheidingen zijn. Een dbms is een applicatie en een sales/marketing systeem is ook een applicatie.
De gebruikers organisatie (is de gebruiker de CEO?) heeft voor elke layer een aparte backup /restore naast een DR strategie nodig. Een systeembackup <> dbms backup <> applicatie backup.
Je onderbouwt in je reactie nu juist prachtig waarom ik het zo vaak over OS-nerds heb. De komen niet verder dan de eigen systeembackup en zien de achterliggende keten niet. Erger ze frustreren die keten.

Als je wat meer ervaring in alle onderliggende zaken in enterprises tegen gekomen bent (complexere systemen integreren)dan zul je ervaren dat localsystem en andere wel degelijk te maken hebben met systeem-rechten her en der. Het is niet zoals met Linux dat als je root bent er geen security meer is. Selunix (NSA) armor etc daargelaten aangezien die een parte laag er tussen proberen op te zetten.

Ja getty en login draaien ook als root en hebben daarmee ook alle rechten.
Maar dat is irrelevant. Je logt in, login checkt je password en verandert daarna je ID en je rechten naar die bij die
ingelogde gebruiker horen. En dat is waar je dan mee kunt werken.
Zo werkt dat ook bij cron: als hij iets gaat doen kijkt hij eerst wie hem daar de opdracht toe gegeven heeft en hij schakelt
de ID om naar DIE gebruiker. Om dat te kunnen doen draait hij als root, maar je job draait NIET als root.

Volledig correct.

Ik antwoord op mezelf:
Dat zou wel eens onzin van mijn kant kunnen zijn, ik weet niet genoeg van hoe het in Windows geregeld is. Sorry dus als dat onzin is.

Wat overeind blijft aan mijn betoog is dat je vanuit de totale rechten op het systeem waarmee de kernel draait via een aantal stappen bij de gereduceerde rechten uitkomt waarmee uiteindelijk een job draait. De code die de rechten reduceert vertrouw je (ik heb het tegen karma4) kennelijk op Windows wel en op Linux niet. Daarbij benadruk je dat het niet deugt dat de cron-service als root draait, maar je erkent tegelijk wel dat cron wel degelijk in staat is om jobs met gereduceerde rechten te draaien.

Mijn punt is dat de reductie van rechten hoe dan ook optreedt, naar welk systeem je ook kijkt, en dat je dus hoe dan ook met code hebt die met meer rechten draait en die je moet vertrouwen om je systeem te kunnen vertrouwen. Op een Linux/Unix-systeem waar cron wordt gebruikt is cron een van de componenten die je moet vertrouwen, net zo goed als je op Windows moet vertrouwen wat daar wordt gebruikt om jobs te starten.

Dat cron als root draait is precies even interessant of oninteressant als de code die in Windows zorgt dat jobs starten draait met de rechten die daar nodig zijn om dat te kunnen doen. Op beide systemen gaat het erom dat die code degelijk in elkaar zit en daadwerkelijk die rechten reduceert en niet van alles doet wat niet tot de functie van die code behoort.

Dat cron als root draait impliceert in het geheel niet dat cron stiekem allerlei andere dingen doet of dat het die rechten niet correct reduceert als het een job start. Het is niet zo dat niemand naar die code kijkt en dat beveiligingslekken daar niet in opgelost worden.

Het is waar dat cron als root draait en dat root alles kan op een systeem. Er draait hoe dan ook code op een systeem die qua rechten alles kan maar niet alles doet. Op Windows draait ook het nodige met SYSTEM-rechten zonder dat dat opeens van alles gaat doen waar het niet voor gemaakt is. Dit geldt voor elk OS. Wat maakt dat je het op het ene OS een probleem vindt en op het andere niet?

Als je tegen mij hebt. Ik vind het voor elk OS Windows Linux ook z/OS en anderen een probleem als de functiescheiding en switchuser context niet op orde is. Wat mij tegen staat is de focus op Windows desktops (thuisgebruik) terwijl de echte problemen wat mij betreft meer in het integratie deel bij enterprises zit. Dan loop je tegen outsourcingsafspraken en tactische machtsblokken aan. Dan is zeer lastig als de vloer uitspraken doet op basis van vinkenlijstjes hoe het moet,

Waar heb ik iets anders geschreven dan?
Zoals gewoonlijk lul je weer uit je nek. Om te beginnen kun jij wel vinden dat we op deze site alleen over "enterprise omgevingen" horen te discussiëren, maar daar ben ik het totaal niet mee eens. Los daarvan staat in enterprise ongevingen de task scheduler gewoon aan want dat is een essentieel onderdeel van Windows. Lees dit artikel van jouw vriendjes over W7/W8 maar eens https://blogs.technet.microsoft.com/askpfeplat/2013/07/14/why-you-shouldnt-disable-the-task-scheduler-service-in-windows-7-and-windows-8/, of deze https://blogs.technet.microsoft.com/askpfeplat/2015/04/26/the-startup-script-is-dead/, daaruit:

Jij moet zonodig bij elke Microsoft fuckup Linux erbij betrekken. Linux heeft ook lekken maar daar gaat dit onderwerp helemaal niet over. Het gaat namelijk over het zoveelste privilege escalation lek in Task Scheduler. Je bent pathetisch.

bij mij als root onder de cron_t SELinux context en dan hangt het van de policy af wat het mag en maakt het root echt niets meer uit. de policy kun je hier bestuderen:

https://github.com/TresysTechnology/refpolicy/wiki