image

Lek in macOS Finder laat inetloc-bestanden willekeurige commando's uitvoeren

woensdag 22 september 2021, 14:00 door Redactie, 8 reacties

Een kwetsbaarheid in macOS Finder maakt het mogelijk voor aanvallers om via inetloc-bestanden willekeurige commando's op systemen uit te voeren zonder dat gebruikers een melding of waarschuwing te zien krijgen. Dat stelt beveiligingsonderzoeker Park Minchan die het probleem ontdekte.

Inetloc-bestanden zijn te gebruiken om online locaties of lokale bestanden te openen. Een aanvaller zou een link aan een inetloc-bestand kunnen toevoegen die geen https:// gebruikt, maar file://. Wanneer een gebruiker een dergelijk bestand in een e-mail opent wordt het opgegeven lokale bestand aangeroepen zonder dat er een waarschuwing verschijnt.

Apple heeft het probleem deels verholpen, aangezien alleen het gebruik van file:// wordt geblokkeerd. Bij het gebruik van File:// of fIle:// werkt de aanval nog steeds, aldus SSD Secure Disclosure. De kwetsbaarheid is aanwezig in macOS Big Sur en eerdere versies.

Image

Reacties (8)
22-09-2021, 14:19 door Anoniem
Ik heb bezwaar op het zomaar op straat gooien van kwetsbaarheden.
Graag een verzoek aan de auteurs zich aan responsible disclosure te houden, maar dan wel voor de 100%.
22-09-2021, 15:36 door Anoniem
Eh lek? en Mac was zo veilig ?
22-09-2021, 15:54 door Briolet
Dit is één van de redenen waarom je altijd onder een user-account moet werken. Zulk soort kwetsbaarheden kunnen dan minder schade aanrichten.
22-09-2021, 16:07 door Anoniem
Door Anoniem: Ik heb bezwaar op het zomaar op straat gooien van kwetsbaarheden.
Graag een verzoek aan de auteurs zich aan responsible disclosure te houden, maar dan wel voor de 100%.
Volgens het verhaal van SSD Disclosure zijn ze begonnen met responsible disclosure, heeft Apple gemeld het te hebben verholpen en de update te hebben verspreid, constateerden ze dat het op een knullige manier onvolledig was verholpen, hebben ze dat gemeld, heeft Apple daar in het geheel niet op gereageerd en hebben ze toen pas gepubliceerd.

Ooit waren er nogal wat softwareleveranciers die geen donder deden met beveiliigingslekken die aan ze gemeld werden. Ze zagen het pas als een probleem als een lek slechte publiciteit opleverde, en beseften niet dat als een beveiligingsonderzoeker het kan vinden dat een boef die het vervolgens misbruikt dat kunstje ook kan vertonen.

Daar hebben sommige beveiligingsonderzoekers op gereageerd door dan maar met publicatie van de kwetsbaarheid een reactie af te dwingen. Dat werkte, maar dat betekent wel meteen dat in de periode tussen publicatie en reparatie de kans op misbruik juist extra groot is. Ook niet ideaal dus, maar de industrie was wel wakker geschud en had wel geleerd dat niets doen geen optie is.

Resposible disclosure is als een middenweg eruit gekomen: meld een gevonden lek, houd het (bijvoorbeeld) drie maanden onder de pet en publiceer het dan. Niet alleen als het is opgelost en de oplossing is uitgerold, het publiceren ervan heeft ook een belangrijke functie: het houdt de industrie scherp en voorkomt dat softwareleveranciers weer laks worden met het repareren van beveiligingslekken omdat er geen haan naar kraait als niemand het weet.

100% responsible disclosure eindigt dus wel degelijk in het publiceren van een ongepatcht lek als de leverancier zich niet aan zijn verantwoordelijkheid houdt om het op tijd te dichten. Dat kan hier heel goed het geval zijn, het lijkt erop dat Apple op de melding met broddelwerk heeft gereageerd en op de melding dat het broddelwerk was niet heeft gereageerd. Als dat over de drie maanden (of wat het is dat bij Apple gangbaar is) heen gaat, gerekend vanaf de originele melding, dan is publicatie wel degelijk te rechtvaardigen.

SSD Disclosure noemt in zijn beschrijving niet wat de tijdlijn geweest is, en dat maakt het onmogelijk te beoordelen of zij niet te haastig zijn geweest, maar je kan op basis daarvan zeker ook niet concluderen dat ze het fout hebben gedaan.

Zoals jij 100% responsible disclosure kennelijk ziet, pas publiceren als het lek gerepareerd is, geeft leveranciers alle ruimte om weer laks te worden en dingen gewoon niet te repareren. Dat is geen responsible disclosure, dat is de wantoestand waar responsible disclosure een oplossing voor is.
22-09-2021, 18:08 door Anoniem
Door Briolet: Dit is één van de redenen waarom je altijd onder een user-account moet werken. Zulk soort kwetsbaarheden kunnen dan minder schade aanrichten.
Daar valt wel wat voor te zeggen. Vraag is of dit ook praktisch is.
22-09-2021, 18:11 door Anoniem
Volgens het verhaal van SSD Disclosure zijn ze begonnen met responsible disclosure, heeft Apple gemeld het te hebben verholpen en de update te hebben verspreid, constateerden ze dat het op een knullige manier onvolledig was verholpen, hebben ze dat gemeld, heeft Apple daar in het geheel niet op gereageerd en hebben ze toen pas gepubliceerd.
Dan nog gooi je een kwetsbaarheid niet zomaar naar buiten. Ik heb zelf ook eens een ernstige kwetsbaarheid gemeld - volgens de richtlijnen - maar heb nooit de gegevens van dit lek en de organisatie genoemd op een website.

Je eerst houden aan de voorschriften, en dan ervan afwijken, noem ik geen responsible disclosure.
22-09-2021, 21:07 door Briolet
Door Anoniem:
Door Briolet: Dit is één van de redenen waarom je altijd onder een user-account moet werken. Zulk soort kwetsbaarheden kunnen dan minder schade aanrichten.
Daar valt wel wat voor te zeggen. Vraag is of dit ook praktisch is.
Waarom zou dat niet praktisch zijn. Ik doe dat al zeker 15 jaar. Het komt misschien 2 à 3 keer per jaar voor dat ik iets wil doen waarvoor het hoofdaccount nodig is. (Zoals het gebruik van een sudo commando).

Ook onder een useraccount kun je de meeste beheerderstaken uitvoeren. Alleen vraagt het OS dan steeds om het beheerders wachtwoord. Ik werk met MacOS, maar volgens mij werkt dat met Windows net zo.
23-09-2021, 12:09 door Anoniem
Door Anoniem: Dan nog gooi je een kwetsbaarheid niet zomaar naar buiten. Ik heb zelf ook eens een ernstige kwetsbaarheid gemeld - volgens de richtlijnen - maar heb nooit de gegevens van dit lek en de organisatie genoemd op een website.

Je eerst houden aan de voorschriften, en dan ervan afwijken, noem ik geen responsible disclosure.
Je hebt kennelijk mijn uitleg niet gelezen.

De afspraak bij responsible disclosure is dat de vinder van een lek dat meldt bij de leverancier, dat vervolgens een periode onder de pet houdt die de leverancier tijd geeft om het lek te repareren en de reparatie uit te rollen, en dat het na die afgesproken periode wél openbaar gemaakt mag worden.

Als de melder dat netjes doet, maar de leverancier er met de pet naar gooit, wie is er dan verantwoordelijk voor de schade? Dan is het de leverancier die zich niet aan zijn kant van de afspraak heeft gehouden, die had het lek moeten repareren.

Moet de melder het dan maar langer laten duren? Daar is echt wel wat voor te zeggen als de leverancier meldt er meer tijd voor nodig te hebben, maar dat is niet wat hier gebeurd is. Een niet gerepareerd lek op straat gooien is zeker schadelijk, maar de wetenschap dat dat gebeurt is precies wat maakt dat leveranciers niet opnieuw laks worden.

En dat weten ze.

Als de melder van een lek die dreiging van openbaarmaking uitvoert is er op dat moment een zeroday-lek. Maar als de melder dat niet doet geeft hij de softwareleverancier een vrijbrief om lekken te negeren. Dat wil je ook niet. Wil die druk in stand gehouden worden dan moeten lekken ook echt geopenbaard worden.

Ik kan in dit geval niet alles beoordelen omdat in het verhaal van SSD niets wordt gezegd over welke termijnen er zijn verstreken. Maar als ze dat wel goed hebben gedaan dan ligt de verantwoordelijkheid voor dit zeroday-lek bij Apple. Dat hadden ze direct moeten repareren en dat had ook makkelijk gekund. Hoe je het precies noteert verschilt per taal, maar dit is zoiets als het verschil tussen:
if protocol == 'file' then ...
en:
if lcase(protocol) == 'file' then ...

Zo klein is dit als je het mij vraagt, het stelt qua programmacode echt geen ruk voor. Het is al bijzonder slordig dat ze dat niet meteen goed hebben gedaan, en nog eens ronduit nalatig dat ze de melding daarover helemaal genegeerd hebben.

Dus zelfs als SSD zich niet aan termijnen voor responsible disclosure gehouden heeft (wat we niet weten en wat ze ook goed kunnen hebben gedaan) is er alle reden om hier je verontwaardiging ook op Apple te richten.

De schuld van een schadelijke situatie ligt niet uitsluitend bij iemand die iets heeft gedaan heeft. Iets belangriks nalaten is ook ernstig, en dat kan zelfs de grootste van de twee verantwoordelijkheden zijn.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.