BuzzE om 13:37, 21-02-2006
Tiger 'herkent' volgens mij niet eens dat het een shell script is. Daar zit nou juist de zwakke plek. Safari/Tiger herkent blijkbaar alleen shell scripts met een #!-regel aan het begin.

Wel dus. Zoals al op pagina 1 zei: als ik in Finder kijk staat er in de type kolom gewoon netjes "Terminal document".

Precies! Maar een shell script is iets anders dan een Terminal Document. Dat is een subtiel maar erg belangrijk verschil! Iemand die dit veiligheidslek uitbuit maakt daar slim gebruik van. Een shell script is iets dat al op UNIX systemen in de jaren '70 bestond. De feature in OS X dat je aan een bestand een applicatie kan koppelen (zoals de Terminal) is specifiek voor de Mac. Daar komt geen 'herkennen' aan te pas van de kant van OS X. Dat is gewoon een instelling die is opgeslagen in de Resource Fork van het bestand.

Je kan ook een heel gevaarlijk shell script maken. Maar als je die niet de executable bit meegeeft, of als je daar een #!-regel in gebruikt, of als je niet expliciet aangeeft (met Get Info) dat hij met de Terminal geopend moet worden, dan is het ongevaarlijk als ik deze op een website zet waar Safari gebruikers langs komen.

Er moeten dus voor zover ik kan zien aan een viertal voorwaarden voldaan worden wil je dit lek uitbuiten:
1. Het moet een shell script zijn (dus een tekst bestand met commando's waar de shell raad mee weet).
2. Het moet geen #!-regel hebben (dat is blijkbaar een (onvolledige) veiligheidsfeature van Safari. Anders herkent Safari het als shell script en voert hij het niet uit).
3. Het moet executable zijn (dat is een veiligheidsfeature van het bestandssysteem op alle UNIX-achtigen).
4. Het moet (volgens de Resource Fork) automatisch geopend worden met Terminal (dat is een gebruiksgemak feature van het bestandssysteem van OS X).

Bovendien kan je dan nog van de mogelijkheid in OS X gebruik maken van het vermommen van het bestandje door middel van het toekennen van een willekeurige extensie en pictogram. Daarmee verleidt je de gebruiker om het te openen.

Bovendien plaatst Safari standaard de downloads op de Desktop. Het vreemde feit dat dit nep-.jpg bestand met de Terminal wordt geopend kan je alleen maar zien door de Finder in Detailed mode te gebruiken, of door Get Info te gebruiken. De meeste gebruikers zullen dat nooit doen. Die zien een icoon van een verder onbekend jpg-je en dubbelklikken erop om te kijken wat het is zonder verder na te denken. Zelfs als Safari het niet automatisch heeft geopend, omdat ze die optie in de Preferences uit veiligheidsoverwegingen hebben uitgeschakeld.

Edit: spelfoutjes en kleine toevoegingen.

(Bewerkt door BuzzE om 14:27, 21-02-2006)

d'accord... je comprend.

Ik luisterde langs je heen, maar vat nu welke kan je op wilt. En je hebt gelijk.

Ik dacht aanvankelijk dat je ingreep op het feit dat iemand zei dat bij hem/haar het script in Preview werd geopend... En dat leek mij onwaarschijnlijk. Vandaar m'n onderbouwing met die screenshot... Maar dat was dus niet hetgeen waarop jij reageerde. Jij reageerde op het "herkenning gedeelte"

(Bewerkt door Cailin Coilleach om 14:22, 21-02-2006)

Zo. Ik heb ook maar maximum security ingesteld vandaag...

(Edited by Vortix at 15:19, 21-Feb-2006)

Ik had automatisch openen altijd al uitstaan, maar heb daar nu nog meer reden voor.

Dus medeFreaks, niet elke beta van OS X 10.5 zomaar uitpakken!!!!  

Oh youpi... Nou ontstaat er weer een hetze over dit probleem, door mensen die het allemaal niet helemaal begrijpen Ik ben al bezig met "damage control"...

http://gathering.tweakers.net/forum/list_message/25248220#25248220
http://www.waarschuwingsdienst.nl/render.html?it=1356
http://isc.incidents.org/diary.php?storyid=1138

Die laatste vind ik vooral jammer. Van SANS had ik verwacht dat ze het originele rapport wel wat beter door zouden lezen...

Toch is er naar mijn mening wel een virus voor OS X, hoe graag ik ook zou willen van niet.

Dat Oempa-Loempa virus verspreidt zich namelijk zelf via Bonjour. En als iets zichzelf verspreid, is het een virus.

Uhm, dat bericht op waarschuwingsdienst.nl klopt van geen kanten!
Het heeft niks te maken met een filmpje of plaatje OP een website!
Alleen met bestanden die je download in een .zip bestand!

En daar komt een belangrijk detail uit de mouw waar ik niet eerder aan had gedacht. Dit detail maakt dit probleem echter wel _erg_ link.

Op een web pagina kan je een browser "forceren" om een download te starten. Dit kan dus onder water, terwijl de user vrolijk foto's zit te kijken. Deze download is de ZIP file en die bevat weer dat scriptje. Die worden in de gevaarlijke situatie automatisch gerunt -> "Pang! Je bent dood!".

Oftewel: iedereen ASAP die optie voor "automatisch openen van downloads" uit zetten. Maar dat wisten we natuurlijk al, of niet?  

Het is natuurlijk sowieso niet verstandig van Apple dat deze optie bij installatie
standaard aan staat. Het is gewoon vragen om problemen.

Apple zal dan ook z.s.m. met een oplossing moeten komen dunkt me!

Ja, want web servers kunnen ook nog wel eens gehacked worden. Rampscenario: Een beetje slimme hacker neemt tijdelijk de server over van een populaire Mac site en heeft binnen een mum van tijd heel veel computers van nietsvermoedende bezoekers geïnfecteerd.

Om te voorkomen dat dit automatisch gebeurt adviseren wij tot die tijd om in de voorkeuren van Safari de optie "Open veilige bestanden na downloaden" uit te schakelen, of  door tijdelijk Camino of FireFox te gebruiken. En nu maar hopen dat Apple dit lek zo snel mogelijk dicht!

Klopt dit wel? Als je het bestand hebt afgehaald van het net en je start het op met finder, dan doet het er toch niet toe met welke browser je dat bestand hebt afgehaald? Of vergis ik me hier?

EDIT: het klopt wel, ... automatisch ...
ik vind dit geen goed nieuws!

(Bewerkt door ventje853 om 16:47, 21-02-2006)

Boramor om 16:02, 21-02-2006
Uhm, dat bericht op waarschuwingsdienst.nl klopt van geen kanten!
Het heeft niks te maken met een filmpje of plaatje OP een website!
Alleen met bestanden die je download in een .zip bestand!

technisch gesproken is het misschien niet helemaal waar maar als je het bericht goed leest staat er dat er een extentie gespoofed kan worden. Een eenvoudige gebruiker snapt niet al te veel van de technische inhoud. Eenvoudige gebruikers kun je dus ook verleiden een gezipt plaatje of filmpje te downloaden, wat vervolgens uitgepakt wordt en lekker op geklikt, voila, het script wordt uitgevoerd.

Er staat dan ook "om te voorkomen dat dit automatisch gebeurd".

Er zijn drie manieren waarop je met deze vulnerability de mist in kan gaan. Een daarvan is automatisch, eentje semi-automatisch en eentje handmatig.

1. Een site forceert je browser een ZIP file met de payload te downloaden. Staat je browser fout ingesteld, dan word de file geopend en het script gerunt.
2. De gebruiker download een ZIP file met de payload.Staat je browser fout ingesteld, dan word de file geopend en het script gerunt.
3. De gebruiker download een ZIP file met de payload. Hij unzipt de file en klikt op de "jpeg" (of wat voor file het dan ook zou zijn) en het script word gerunt.

Ik persoonlijk zou al raar opkijken van een ingezipt plaatje of filmpje, wie doet dat nou tegenwoordig nog. Maar aan de adnere kant kan je het spoofen als wat voor file dan ook...

Erger nog vind ik dat je een shell executable kan uitvoeren zonder de zogenaamde Unix x permissions.

Ik bedoel nu wordt er ophef gemaakt over dat Safari niet default in de preferences op openen van zogenaamd betrouwbare files mag staan, maar voor het zelfde geld krijg je zo'n plaatje via je mail of hoe dan ook op je computer...

Aan de buitenkant kan je niet zien of het een shell executable is (icoontje en bestands extensie zijn makkelijk aangepast), maar kwalijk is wel dat je vanuit een dubbelklik geen x-permissies koppelt vwb het openen van een terminalsessie (ongeacht of je met een administrator-account bent ingelogd).. !!!!!

Apple vraagt toch ook om je wachtwoord na het installeren van een opgehaalde update ??

(Bewerkt door Spooter om 17:59, 21-02-2006)

(Bewerkt door Spooter om 18:00, 21-02-2006)

Spooter:
Je moet wel degelijk UNIX execute (x) permissies hebben op de file om het script uit te kunnen laten voeren. Maar het is natuurlijk voor de kwaadwillende een koud kunstje om daar voor te zorgen. In de zip file blijven die permissies behouden.

Mac OS X vraagt alleen naar je wachtwoord als er iets veranderd moet worden waar je geen rechten hebt. Omdat iedereen in zijn of haar eigen home directory gewoonlijk lees en schrijf rechten heeft op alle files kan een kwaadwillend script daar dus al veel schade doen. Bij gebruikers die ook admin zijn zijn ook de files in bijvoorbeeld de /Applications folder en delen van de /Library folder kwetsbaar. Alleen voor systeembestanden moet altijd een wachtwoord worden opgegeven, ook door admins. Bij een opgehaalde update worden natuurlijk altijd systeembestanden veranderd. Daarom wordt daar ook altijd om een wachtwoord gevraagd.

BuzzE om 18:22, 21-02-2006
Spooter:
Je moet wel degelijk UNIX execute (x) permissies hebben op de file om het script uit te kunnen laten voeren. Maar het is natuurlijk voor de kwaadwillende een koud kunstje om daar voor te zorgen. In de zip file blijven die permissies behouden.

Hallo Buzze,

toch had deze file (heise.jpg) geen x-permissies.

ik pleit meer voor dat het OS vraagt om een wachtwoord op het moment dat er een executable uitgevoerd gaat worden (zeker als de executable een terminal-sessie wil starten).

Dat kan Apple toch hard in de filemapping vastleggen ??

ik pleit meer voor dat het OS vraagt om een wachtwoord op het moment dat er een executable uitgevoerd gaat worden (zeker als de executable een terminal-sessie wil starten).

Dat kan Apple toch hard in de filemapping vastleggen ??

Ja, maar dat wil je toch ook niet?!

open safari -> vul eerst je password in
open mail -> vul eerst je password in
open adium -> vul eerst je password in
ssh naar een ander systeem -> vul eerst je password in, gevolgd door alle nodige passwords
nslookup  -> vul eerst je password in
ping -> vul eerst je password in
enz enz enz...

nee, dat moet je niet willen...

Aan de andere kant: als je het koppelt aan de vraag: "u start app X voor het eerst op, weet u dit zeker? J/N" dan heb je enige bescherming. Echter, de mensen die nu al in dit soort grappen trappen, zullen daar ook ongetwijfeld zonder te lezen op J klikken...

maar wanneer komt Apple nou eens met een update???

Zeg, het is hier bij ons in NL rond 0900 bekend geworden en toen was het bij hun nog volop nacht. Stel dat het daar een uurtje of acht vroeger is, dan is het daar nu 1100 'sochtends... Ze zijn net begonnen met de werkdag man!

Reken op morgen of overmorgen. Onze tijd dan.

Spooter om 18:30, 21-02-2006Hallo Buzze,

toch had deze file (heise.jpg) geen x-permissies.

Controleer het nog maar eens. heise.jpg heeft bij mij wel degelijk execute permissies (-rwxr-xr-x om precies te zijn). Terminal start wel op maar voert het script niet uit als je de execute permissies van heise.jpg verwijdert (chmod -x heise.jpg) en er vervolgens op klikt. Het wordt dan niet meer uitgevoerd. Zo hoort het natuurlijk ook. Maar nogmaals, een kwaadwillende kan gewoon dat execute bit aanzetten en de file in een zip stoppen, dus is deze discussie verder van ondergeschikt belang.

Het vragen om een wachtwoord bij het uitvoeren van een executable is natuurlijk ook onzin, zoals Cailin Coilleach al aangaf. Het is in Mac OS X, en in alle vergelijkbare systemen gewoon zo dat als je je wachtwoord ingeeft bij het inloggen je de volledige verantwoordelijkheid krijgt van het systeem voor alles waar je op klikt, welke programma's je opent en wat je ermee doet - binnen je eigen home directory. Zo hoort het ook in een goed werkbaar maar tevens goed beveiligd systeem!

Het enige veiligheidslek in OS X is dus het feit dat Safari een script kan uitvoeren zonder dat dat de intentie van de gebruiker is. Dat heeft verder niks met applicaties en wachtwoorden in het algemeen te maken.

Oh nee, nu spreekt het NRC ook al van het eerste Mac OS X virus.

Het leed is dus al geschiedt; de berichten zijn nu het virus!

Dit gaat schade aan de Mac-gemeenschap toebrengen. Systeembeheerders zullen er weer een reden bij hebben om Mac's te weren want de meeste bewaren enkel de negatieve stukken. Er gaat een beeld ontstaan dat OS X onveilig is (not). Waarom, waarom toch eens in de zoveel jaar deze berichten?

Zeg, hou eens op met jammeren! Je moest eens weten hoeveel beveiligingslekken er al geweest zijn in OS X. Zo gaan er ook nog heel veel komen. Je bent nogal kortzichtig als je beweert dat een OS (welk ook) compleet veilig is. Dan heb je volgens mij nog nooit nagedacht over waar die Security Updates eigenlijk voor dienen. In elk complex systeem komen fouten voor, dus ook in besturingssystemen. Mac OS X is daarin echt niet veel anders dan Linux en Windows. Elke goede systeembeheerder weet dat al lang.

Dit is een beetje een uitzonderlijke situatie omdat er zo makkelijk een exploitatie gedemonstreerd kan worden voordat Apple het lek heeft gedicht, maar in feite is er niets meer aan de hand dan dat. Als dit binnenkort verholpen is draait de wereld weer gewoon door.

Toevoeging: Ik kan trouwens nergens in de NRC iets vinden hierover. Kan je wat specifieker zijn over welk artikel je hebt gezien?

Nog een toevoeging: Ik heb het bericht al gevonden: http://www.nrc.nl/media/article226373.ece, maar dit bericht gaat over de relatief ongevaarlijke malware van een paar dagen terug.

(Bewerkt door BuzzE om 20:18, 21-02-2006)

Op macintouch is een actieve discussie aan de gang, waarin men met de volgende (voorlopige) oplossing voor dit specifieke probleem komt:
- Zorg dat je normaal gesproken in een account zonder admin privileges werkt
- Zorg dat de terminal alleen te openen is door iemand met admin privileges

Dit laatste doe je door (na 'get info') de 'owner' van de terminal op degene met admin priviles te zetten, en 'Others' op 'No Access'. Lastig als je vaak in de terminal moet zijn, maar afgezien van heel erg goed opletten welke files je wel en niet opent, volgens mij de enige bruikbare oplossing voorlopig.