Beveiligingsbedrijf claimt lek in sandbox Mac OS X

Het Argentijnse Core Security claimt dat de sandbox-functionaliteit in Mac OS X valt te omzeilen. Het beveiligingsbedrijf heeft onlangs een proof-of-concept vrijgegeven. Apple kwalificeert de kwetsbaarheid echter niet als gevaarlijk.

Core Security toont in een proof-of-concept aan dat de sandbox kan worden omzeild door een nieuw Apple-event via osascript naar launchd te sturen. "Een malafide applicatie die niet op het internet kan, krijgt door het gebruik van Apple-events in theorie toegang tot het netwerk en kan daardoor andere applicaties aanroepen die niet door een sandbox worden beperkt", aldus de onderzoekers.

De sandbox zit in nieuwere versies van Mac OS X, waaronder Snow Leopard en Lion. Apple wil daarnaast dat apps in de Mac App Store vanaf maart in een sandbox draaien. Sandboxes moeten een betere beveiliging opleveren. Zo moeten ontwikkelaars van een applicatie aangeven welke rechten deze moet hebben, zoals het accepteren of opzetten van een internetverbinding en het gebruik van de webcam. Concreet betekent sandboxing op Mac OS X voor hen dat ze in hun programma's rekening moeten houden met het nieuwe systeem van bevoegdheden, als ze de apps in de Mac App Store willen houden.

De bekende hacker Charlie Miller, die vorige week nog malware de App Store binnensmokkelde, gaf in 2008 al aan dat de sandbox-functionaliteit kwetsbaar was. Voor zijn hack moest echter een extern script worden geladen, dat al op de pc van een gebruiker moest staan. Apple dichtte het lek toen, zodat de aanval niet meer werkte.

Core Security ontdekte eind september een soortgelijk lek en stelde Apple daarvan op de hoogte. Aanvankelijk reageerde het Amerikaanse bedrijf volgens Core laconiek. Na de proof-of-concept geeft Apple toe dat de sandboxes alleen goed functioneren in het proces waarin ze worden opgeroepen. Het bedrijf overweegt naar verluidt de documentatie aan te passen.

Reacties (35)

[shytah]

Ok, als ik het goed lees werkt dit lek alleen met applicaties die niet in een sandbox draaien. Misschien heel kortzichtig, maar is dat nu juist niet een van de redenen om over te gaan op sandboxed applicaties?

Edit; Om even te verduidelijk, mijn vraag slaat op het volgende stuk; "krijgt door het gebruik van Apple-events in theorie toegang tot het netwerk en kan daardoor andere applicaties aanroepen die niet door een sandbox worden beperkt", aldus de onderzoekers."

Het lijkt me logisch dat sandboxen geen zin heeft wanneer de helft van je applicaties dit wel is en de andere helft niet. Daarnaast kan ik uit dit stuk nou niet opmaken of deze applicaties zich nou op de eigen computer bevinden of op een andere computer.

[Reactie gewijzigd door shytah op 23 juli 2024 09:09]

[Wraldpyk]

nee dit lek is juist voor Apps die in een Sandbox staan. Buiten een sandbox heb je in principe recht op alles, dus dan is dit peanuts. Je kunt zelfs de hardeschijf wissen buiten de sandbox als je dat wilt. Binnen sandbox zou de app alleen dingen moeten kunnen waarvoor jij toestemming hebt gegeven

[Wolfos]

Alleen als de gebruiker ook het wachtwoord op geeft, hoor.

[tijs14tijs]

Je zult ervan versteld staan hoeveel gebruikers zomaar hun wachtwoord aan een applicatie geven zonder erbij na te denken waarom het wachtwoord nodig is.

[daft_dutch]

Nee, applicaties die in een sandbox draaien waarvan de gebruiker aan neemt dat de app niet de buiten wereld kan benaderen kan dat dus WEL van uit de sandbox naar buiten. (het netwerk op applicaties aanroepen.)
Hierdoor wordt de gebruiker compleet op het verkeerde been gezet en daardoor Zeer aantrekkelijk is om te exploiteren! soort van dubbele realiteit "men ziet het niet".
Een zandbak de grenzen zijn eindeloos.

[Reactie gewijzigd door daft_dutch op 23 juli 2024 09:09]

[Anoniem: 282252]

Het punt is met de aangetoonde exploit is dat je al een Apple script op je computer moet hebben die deze 'sandboxed applicatie' kan aanroepen.

Ik snap Apple's reden om de documentatie aan te passen.

De vraag is dan natuurlijk, waarom kan deze Applescript functie ook niet in de sandbox geplaatst worden.

Onder:
O Alle Apple Script

In de Apps sectie bijvoorbeeld.

Alhoewel uit het tweeakters stukje nog niet kan opmaken hoe de nieuwe exploit precies werkt. Punt is wel dat All applicatie in de appstore via sandboxing moeten gaan werken, dus omzeilt een applicatie dit kan Apple deze wel uit de Appstore verwijderen.

Ter verduidelijking voor niet Apple kenners, elke applicatie die niet in de appstore staat, zoals alle open source software en software die 'op straat' gekocht worden, die hoeven niet in de sandbox. Je bent dus nog steeds vrij om alles wat je maar wilt te installeren.

[humbug]

Het punt is dat Apple events de sandbox negeren en je dus commando's kan geven aan applicaties buiten de sandbox. Een applicatie als launchd staat standaard op een Mac en kan dus "bestuurd" worden vanuit de sandbox.

[LOTG]

Nee, als ik het goed begrijp kan een gesandboxte applicatie via applescript de sandbox omzeilen en applicaties downloaden en starten die niet in de sandbox draaien.

"Een malafide applicatie die niet op het internet kan, krijgt door het gebruik van Apple-events in theorie toegang tot het netwerk en kan daardoor andere applicaties aanroepen die niet door een sandbox worden beperkt"

Ik vind de reactie van Apple hierop heel vreemd:

Na de proof-of-concept geeft Apple toe dat de sandboxes alleen goed functioneren in het proces waarin ze worden opgeroepen. Het bedrijf overweegt naar verluidt de documentatie aan te passen.

Bug to feature conversion?

[Anoniem: 156876]

Lijkt mij dat apps die de sandbox omzeilen niet door de checks van Apple heen komen?

[Fly-guy]

Die veronderstelling kan gevaarlijk zijn, er is inmiddels ook al malware in de appstore gebracht. Dus die check zou ik niet als 100% veilig beschouwen...

[rob12424]

uhm in feite kun je zeggen, een chroot jail wordt ook vaak gezien als veilig terwijl je daar met een beetje kennis ook uit kan breken (wel met veel moeie en gezeur maar het kan!)hoe dat met de huidige lxc containers zit weet ik niet maar in feite zijn dat de alternatieven voor deze sandbox app voor mac osx.

LXC = linux container (ja dat is er sinds versie 2.8 van de linux kernel)
chroot jail = unix (solaris enz. hebben apparte naam ervoor)

[MacWolf]

Mac ontwikkelaar Wil Shipley geeft in een artikel aan dat beveiliging middels een sandbox veel nadelen heeft en dat het wenselijker zou zijn als Apple in plaats daarvan met certificaten zou gaan werken.

Interessant leesvoer: http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html

There are three primary ways Apple increases security of applications running on the Mac and the iPhone: Sandboxing, Code Auditing, and Certification. While all these are incrementally valuable, none is perfect on its own.

The problem Mac developers are facing is that the two that Apple is enforcing on the Mac App Store (Sandboxing and Code Auditing) are implemented currently to be actively bad for developers and not particularly good for users. And the method that would provide the most benefit for developers and users (Certification) isn’t enforced broadly enough to be useful.

...

[SoloH]

Nee. De applicatie is gesandboxed. Het kan toegang krijgen tot het netwerk door andere applicaties aan te sturen die wel toegang tot het net hebben.
Het probleem zit er vooral in dat de default instelling van de sandbox dit toelaat.
Om te zorgen dat het niet mogelijk is om toegang te krijgen tot het internet, zou de developer dus ook de toegang tot applescript of andere apps moeten ontzeggen. Iets waar dus niet zomaar rekening mee wordt gehouden.

[ro8in]

Ik vind dat hele sandbox gedoe maar niks. Begrijp dat ze de consumer markt nu wat meer proberen te targetten want daar hebben ze nu het grote geld geroken, maar voor ons pro's hoeft dat allemaal niet zo. Je app kan maar zoveel als dat de sandbox toe laat.

[ZpAz]

Mits goed uitgevoerd merk je als pro zijnde niet of iets binnen een sandbox draait of niet. Daarnaast gaat het er om dat applicaties uit de market binnen een sandbox moeten draaien, heb je echt iets nodig wat niet in een sandbox draait dan kan je dat ergens anders weghalen.

[Reactie gewijzigd door ZpAz op 23 juli 2024 09:09]

[SunnieNL]

Je wordt nu gedwongen om van te voren te bedenken waar en of je applicatie daar eigenlijk wel rechten nodig heeft en netjes tegen de api's aan te praten.

Merk jij er iets aan bij bv. Adobe Reader X in windows (welke in een sandbox draait) of msie 7/8/9 (welke in sandboxes draaien zolang je de uac aan houdt)
(en ja.. ik heb het even over Windows, maar die gebruikt ook al sinds Windows Vista een sandbox voor verschillende processen en dat zullen er met Win8 alleen nog maar meer worden)

[Reactie gewijzigd door SunnieNL op 23 juli 2024 09:09]

[humbug]

Voor mij is een Sandbox gewoon een goed idee. Maar dan wel 1 die ontwikkelaars niet hindert (wat met de beperkingen voor de App store dus wel gaat gebeuren) en 1 die waarmaakt wat hij beloofd namelijk geen communicatie naar buiten zonder toestemming. (En dus ook geen Apple Events)

Een sandbox die niet aan die twee voorwaarden kan voldoen is in mijn ogen niet af en meer een obstakel dan een oplossing. Netjes tegen de Api aanpraten is een goed idee, maar wat als Apple geen zin heeft om de API te openbaren of de API er gewoon niet is?

Mijn grote angst is dat Apple de Sandbox onder de noemer "security" gaat gebruiken om te bepalen wat je als gebruiker wel of niet mag net zoals men ook bij de iOS apparaten probeert. De laconieke houding rondom de veiligheid van een Sandbox (wat toch echt de kernfunctie zou moeten zijn) doet het ergste vrezen. Computers zijn traditioneel gezien hele open systemen waar je, als je de kennis hebt veel mee kan. Maar bij Apple zie ik nu een neiging om het "Child Proof" te maken, iedereen kan het gebruiken maar iedereen mag enkel doen wat Apple vooraf heeft goedgekeurd.

Het verschil met de windows Sandbox is dan ook voornamelijk dat Microsoft het gebruik van de sandbox niet oplegt. Het wordt geadviseerd maar als je het advies in de wind slaat worden je geen opties ontnomen. En dat wil Apple dus wel

[ppl]

De Mac App Store is geen verplichting. Applicaties kun je nog altijd buiten die app store om aanbieden, iets waar velen gebruik van maken! Ze zullen daar bij Apple echter wel goed moeten gaan nadenken over de regels van de Mac App Store. Die store is vrij cruciaal om te zorgen dat iedereen van sandboxing gebruik gaat maken en dat ook op de juiste manier gaat doen. Dan heb je er dus niets aan als iedereen buiten de app store om gaat omdat ze anders hun product niet kunnen slijten vanwege de regels van de store. Een ander heikel punt is het verschil in sandboxing tussen Snow Leopard en Lion (Lion kent profielen waardoor je heel specifiek rechten kunt toewijzen; Snow Leopard kent dit totaal niet). Het lijkt er overigens wel op dat de sandboxing op dit moment meer een service is vanuit Apple ("willen jullie sandboxen? nou wij hebben wel wat hoor!").

[ppl]

Het gaat erom dat applicaties niet meer kunnen doen dan dat wat nodig is. Dat voorkomt dat er via allerlei bugs in de applicatie er bepaalde zaken wel gedaan kunnen worden. Dit is namelijk 1 van de meest gebruikte manieren om een machine te hacken. Gaten in software uitbuiten om root/administrator rechten te verkrijgen zodat je de machine in een botnet kunt hangen (om maar eens iets te noemen). Je kunt het ook gebruiken voor bedrijfsspionage (iets waar Nederlandse bedrijven heel erg vatbaar voor zijn aldus de AIVD).

Dit soort systemen zijn in de unix/linux wereld dan ook niet ongewoon. Denk bijvoorbeeld aan iets als AppArmor, jails in FreeBSD, chroot en wat al dies meer zij. Allemaal bedoeld om te zorgen dat je niet via een exploit in BIND een hele machine kunt rooten zodat je de MySQL database kunt uitlezen waar de betaalgegevens van mensen in staan. De PSN hack heeft laten zien wat voor gevolgen dat kan hebben.

Kortom, het is fijn dat iets wat tot voor kort vooral voor de pro's was nu eindelijk ook eens beschikbaar wordt voor de consumers. Broodnodig ook helaas gezien de enorme hoeveelheid computers die onderdeel zijn van een botnet. Heeft allemaal te maken met het feit dat de gemiddelde gebruiker geen kaas heeft gegeten van z'n computer. Ze weten ongeveer hoe ze het ding moeten bedienen maar daarmee houdt het ook echt wel op.

[Wraldpyk]

Ik moet zeggen, ik had nog niet gehoord van Sandbox plannen van Apple, maar lijkt mij een uitstekende manier om rechten te beperken van applicaties, en door het af te dwingen in de App Store weet je (bijna) zeker dat de apps die daar in staan (relatief) veilig zijn.

Natuurlijk moet het dan wel goed dicht zitten, wat in dit geval dus iets minder het geval is, maar zoals Apple zelf al zegt, deze is niet kwalijk.

Lijkt me een goede ontwikkeling, zolang het maar mogelijk blijft om buiten de App store apps te installeren, want een openheid/vrijheid is nooit weg natuurlijk, dat moet blijven!

[RobbieB]

Er zitten ook grote beperkingen aan.

Veel goede apps in de Mac AppStore maken gebruik van wat diepere systeem-integratie die met de nieuwe regels niet meer mogelijk is (bv. Fantastical).

Het gevolg is dat een groot deel van de huidige (vooral tweak/customize apps) niet meer via de AppStore aangeboden worden.

En hoe je het ook wendt of keert, juist voor deze Apps is de Mac AppStore een perfect uithangbord omdat veel 'gewone' gebruikers deze Apps anders waarschijnlijk nooit zouden vinden. Ik heb dan ook het idee dat Apple zichzelf hier heel erg mee in de vingers snijdt.

Hoewel het dus voor de 'normale' gebruikers misschien beter is, en vooral veiliger, is het voor veel developers een doodsteek.

Daarnaast is het maar de vraag hoeveel Apple in de toekomst toe laat staan via OSX. Het lijkt er steeds meer op dat ze naar een iOS-achtig gesloten systeem toe willen. Ik zie dit zelf als zeer onwaarschijnlijk, maar goed, Apple heeft wel vaker abrupte beslissingen genomen die door de community niet als waarschijnlijk werden opgevangen (Intel switch, non-Flash support iOS, Final Cut X).

[shytah]

Ik hoop voor Apple dat het niet zo ver gaat komen, want dan hebben ze aan mij een verkeerde. Ik kan me voorstellen dat het voor de doorsnee gebruiker alleen maar beter is wanneer zij alleen applicaties kunnen installeren via de Mac App Store. Ik vind dat power-users(de gebruiker die weet wat hij doet en de risico's kent en accepteert) de keuze hierin moeten krijgen.

Wij tweakers vinden het maar een vervelend idee dat je vastzit aan iets en geen vrije keuze hebt. Ik denk echter dat de ontwikkelingen voor de gemiddelde consument alleen maar positief is.

Vergelijk het met een auto. Deze moet veilig zijn en goed zijn in wat het doet. Je eigen auto aanpassen brengt risico's met zich mee. Ditzelfde geldt voor een computer. Virussen, malafide software, etc brengen de maatschappij veel economische schade toe. Het kan zelfs mensenlevens kosten. Nou zal dit laatste natuurlijk niet opgaan voor de gemiddelde OS X gebruiker, maar het idee blijft hetzelfde.

Ik kan de ontwikkelingen van de Mac App Store dan ook alleen maar toejuichen. Dit wordt natuurlijk anders wanneer Apple besluit OS X helemaal dicht de gooien, ook voor de power-user.

[ZpAz]

Wat zou Fantastical nodig hebben wat niet binnen een sandbox kan?

[RobbieB]

Eerlijk gezegd geen idee, maar MacRumors zegt:

"Mac Apps that may be affected: TextExpander, CoverSutra, Transmit, Fantastical"

(bron)

[Anoniem: 145867]

Stuur dan gelijk OSX naar de prullenbak en gooi iOS op een MAC... dan zeg ik doei tegen apple.

[johnbetonschaar]

Want? Onder de toevoeging 'zolang het maar mogelijk blijft om buiten de App store apps te installeren' snap ik eigenlijk niet helemaal waar je nu een probleem mee hebt.

Wat kan jou het nou schelen of een applicatie in een sandbox draait of niet als het verder precies doet wat je er van verwacht? Het is gewoon een beveiligingsfeature die bedoeld is om het moeilijker te maken om malware op de computers van nietsvermoedende gebruikers te krijgen. Lijkt me niks mis mee...

[Fly-guy]

Probleem met sandboxing is wel dat als er malware in de store staat, je dan ook meteen alle poorten open hebt staan. En je zegt zelf al, je bent er bijna zeker van dat dat soort malware niet in de store staat, maar wat te denken van het appje van de heer Miller in de ios store?

De checks van apple zijn niet 100% perfect...

[zwippie]

Na de proof-of-concept geeft Apple toe dat de sandboxes alleen goed functioneren in het proces waarin ze worden opgeroepen. Het bedrijf overweegt naar verluidt de documentatie aan te passen.

Dus de oplossing voor het probleem is: pas de documentatie aan... Is het dan niet verstandiger om de code die de events afhandelt aan te passen? Of het gebruiken van events gewoon niet toe te staan? Of levert dat dan weer problemen op voor de integratie van een sandboxed applicatie met het OS?

[Niemand_Anders]

Struikvogel tacktiek begint een beetje de nieuwe werkwijze van Apple te worden. 'Hacker' toont aan dat je malware zo in de app store krijgt. 'Hacker' verliest zijn account.

Security bedrijf toont aan dat sandbox niet waterdicht is. Apple past documentatie aan.
Alles onder het motto 'doorlopen mensen, er is niets te zien'.

De meeste issues onder zowel OSX als Windows ontstaan inderdaad in het gebied waar een native applicatie van Apple of Microsoft net even wat meer kan dan de rest (undocumented features). Omdat deze onderdelen amper of slecht bekend zijn worden deze dus ook niet volledig getest en later blijkt dat iemand de moeite heeft genomen om alle instructies te monitoren en ziet ineens een onbekende instructie voorbij komen..
En vervolgens gaat men dan die instructie onderzoeken en zal men ook proberen argumenten te manipuleren om zo beter achter de werking van de instructie komen.

[johnbetonschaar]

Struikvogel tacktiek begint een beetje de nieuwe werkwijze van Apple te worden. 'Hacker' toont aan dat je malware zo in de app store krijgt. 'Hacker' verliest zijn account.

Wat heeft het afsluiten van zijn account met 'struisvogelpolitiek' te maken? Het is gewoon de standaardprocedure wanneer een developer zich niet aan de voorwaarden houdt, en die is voor iederen gelijk, ook voor white-hat hackers. Het lek in kwestie was een week later al gedicht in iOS 5.0.1, dus er wordt wel degelijk iets mee gedaan. De developer account van Miller zal ongetwijfeld uiteindelijk gewoon weer geunblocked worden.

Security bedrijf toont aan dat sandbox niet waterdicht is. Apple past documentatie aan. Alles onder het motto 'doorlopen mensen, er is niets te zien'.

Er staat 'Apple kwalificeert het lek als niet gevaarlijk'. Zonder verdere informatie over wat je er wel en niet mee kan, en of het daadwerkelijk om een relevant beveiligingsprobleem gaat, is het makkelijk roepen van de zijlijn. Ik kan uit het artikel echt niet opmaken of het hier om een lek gaat dat zelfs maar de moeite van het vermelden waard is.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 09:09]

[zwippie]

In het bronartikel staat proof-of-concept code voor een applicatie in een sandbox zonder netwerk rechten, die via scripting tóch een netwerkconnectie op kan zetten. Dat is in potentie dus zeker gevaarlijk. De sandbox restricties worden op die manier gewoon omzeild zonder dat je dat door hebt als gebruiker.

Ik kan het niet reproduceren (heb geen mac) en natuurlijk zullen er haken en ogen aan deze methode zitten, maar ook jij kan alleen maar van de zijlijn roepen dat je erop vertrouwt dat wat Apple zegt klopt. Probeer de code eens te draaien zou ik zeggen, en post je bevindingen hier.

En het lek is de moeite van het vermelden waard omdat:

• De sandbox functionaliteit blijkbaar niet geheel waterdicht is, en
• Apple hier vrij laconiek op reageert.

[SunnieNL]

Pas de documentatie aan is zoiets als 'it''s not a bug, it's a (undocumented) feature"

[ppl]

Ik denk dat het aanpassen van de documentatie te maken heeft met hoe de sandboxing in OS X richting developers gepresenteerd wordt.

In Snow Leopard zit dit ook al alleen is de sandboxing nogal erg beperkt omdat deze ook erg simplistisch van opzet is. Je zet een applicatie in een sandbox en vervolgens heeft de app een reeks aan dingen nodig om z'n werk te kunnen doen. Daardoor moet je de boel dusdanig open gooien dat je eigenlijk geen sandbox meer hebt.

In Lion hebben ze dat grondig aangepakt, je kunt nu rechten heel erg inperken. Je hebt nu allerlei losse rechten die je kunt toewijzen. Het probleem daarmee is dat je dat (als ik het goed begrepen heb) aan een proces toewijst. Als je app maar 1 proces is heb je dus weer het oude probleem: je moet alle rechten aan dat proces gaan toewijzen waardoor je eigenlijk ook geen sandbox hebt. Het is een systeem wat dus heel erg afhankelijk is van hoe de ontwikkelaar het implementeert. Als die goed zijn werk doet is de applicatie opgesplitst in allerlei aparte processen waaraan de juiste rechten zijn gekoppeld. Daardoor kan een app niet meer dan wat het nodig heeft en wordt het uitbuiten nogal lastig (juist omdat 1 proces maar een heel beperkt aantal dingen kan doen ipv alles).

Wat ik denk dat hier gebeurd is dat men een app heeft met maar 1 proces die alles mag. Die laat je dan dat script aanroepen en hopsa.

Daarom is het ook van belang dat het gebruik van sandboxing verplicht wordt en dat er iemand controleert of dit goed gebeurd. Dat is waar de Mac App Store dan ook bij komt kijken. Omdat er verder nog niks verplicht is, is dit hele probleem ook eigenlijk een storm in een glas water en moet je het ook meer bij de ontwikkelaar die sandboxing implementeert zoeken dan bij de partij die het aanbiedt (Apple dus). Het feit dat het systeem valt en staat met hoe goed ontwikkelaars de sandboxing implementeren is iets wat je Apple dan weer wel volledig kunt aanrekenen. Het aanpassen van documentatie is in deze eerder bedoeld om meer duidelijk te verschaffen aan ontwikkelaars hoe de sandboxing in OS X nou precies werkt zodat zij het beter kunnen implementeren. Een situatie krijgen waarbij apps alleen kunnen draaien als ze correct gebruik maken van sandboxing is niet iets wat je eenvoudig kunt implementeren, zo'n app store is dan het meest handigste. Uiteindelijk zal het ook meer neer komen op een hele set van security maatregelen.

[kmf]

Tja.. de SandBox van Mac moet waarschijnlijk ook wat uitkristalliseren. Als een app welke in de sandbox zit toegang moet hebben tot het filesysteem, dan is dat toch sowieso al een probleem?
En een systeem zoals iOS waar elke app zijn eigen documentenlade heeft lijkt me niet geschikt voor desktop-omgeving.

[jip_86]

Jammer, hoop dat er nog een oplossing gaat komen voor alle SandBox problemen. Ga waarschijnlijk een zeer nuttige app verliezen als het allemaal doorgaat.