Sådan crasher du dine Mac-programmer med 8 tastetryk

Det virker upåklageligt og meget sikkert :O)

Jeg har lige testet dette på min mac med ML. Og der sker ikke noget, den åbner bare stien og viser mig harddisken og netværket.

Husk at starte med stort 'F'. Fejlen kan fremkaldes her.

MacBook Pro mid 2009 15" 2,66GHz med MacOS 10.8.2 crasher ikke når jeg skriver de 8 bogstaver i Safaris adressefelt.

Istedet for "see applikationen crasher hvis vi gør det her man ellers aldrig gør - HAHAHA"

http://www.macworld.com/article/2027007/url-detection-flaw-causes-os-x-a...

Det er en sikkerhedsfeature der validere URLer inden de parses fra data detectors... Hvis valideringen ikke finder at URLen er valid (eller et forsøg på en bufferoverflow) lukkes den App der har forsøgt at parse URLen.

Måske en let overreaktion men fordi det er Mac OS X der lukker for Appen men det gør at det her er ikke en exploitable buffer overrflow det er mere i stil med at man lukker øjnene når man nyser pga birkeallergi hvis man går under et blomstrende birketræ..

En utilsigtet effekt men heldigvis ikke akut blindhed...

Formentligt en sideeffekt af at Apple for et par år siden lukkede for et muligt overflow i data detectors med mystiske unikode tegn... I retrospekt lidt for effektivt men åbentbart en sjælden nok forekommende fejl til at det ikke er belevet opdaget før nu.

så hvis man laver noget javascript der redirecter browseren til File:/// så dør baby ?

> Det er en sikkerhedsfeature der validere URLer inden de parses fra data detectors... Hvis valideringen ikke finder at URLen er valid (eller et forsøg på en bufferoverflow) lukkes den App der har forsøgt at parse URLen.

Ja. Og det er problemet. Hvorfor har en library funktion en "assert" som hårdt afslutter applikationen uden at brugeren får mulighed for at gemme sine data?

En assert som hårdt afslutter processen er en ret voldsom måde at reagere på forkert bruger input. Normalt vil man reservere hårde procesafslutninger til situationer hvor der er grund til at tro a arbejdshukommelsen er i en ukendt og ustabil tilstand (memory corruption). Dette er imidlertid ikke en memory corruption bug.

I et højniveau sprog som fx. Java, C#, Ruby eller Python ville man håndtere sådan en situation med en exception: Det er ikke korrekt at fortsætte men der er ikke grund til at smide alt på gulvet. En exception giver kalderen mulighed for at håndtere situationen med at komme på benene igen.

Problemet er, at Unix arkitekturen (i modsærning til Windows) IKKE har OS understøttet structured exception handling (SEH). Der er kun returkoder og terminering af processen. Der er også mulighed for at benytte signals, men disse er både meget grovkornede og heller ikke strukturerede på en måde så "senderen" kan forvente at kalderen enten håndterer situationen eller bliver termineret.

I den konkrete situation har udvikleren af API'et altså skulle vælge hvad der skal gøres når en validering typer på et sikkerhedsproblem (men ikke memory corruption). Hvis han brugte en returkode er der ikke sikkerhed for at kalderen faktisk opdager problemet, hvilket kan lede til et sikkerhedsproblem. Hvis han brugte en "assert" så risikerer brugere tab af data men funktionen kan så garantere at malformet URIs ikke slipper igennem. I mangel på exception handling som ikke kan bruges når det er en funktion som skal udstilles så den kan bruges fra C, Objektive-C mm fordi OS'et ikke understøtter dette, så har Apple altså valgt at risikere brugernes data.

"En assert som hårdt afslutter processen er en ret voldsom måde at reagere på forkert bruger input. Normalt vil man reservere hårde procesafslutninger til situationer hvor der er grund til at tro a arbejdshukommelsen er i en ukendt og ustabil tilstand (memory corruption)."

Eller at der er en auto detekteret URL string der ikke lever op til at være valid. Noget der også børe resultere i processafslutning med extreme prejudice.

At sikkerheden er priotereret over brugervenligheden (som også er tilfældet med de seneste "NEJ du kan IKKE benytte java, punktum") og når der er en real risici mener jeg det er bedre at være på den sikre side.. Specielt når OSet har system vide versionsstyring og autosafe APIer der gør at applikationer kan genstarte uden datatab, noget der også sikre brugerene mod datatab fra andre kilder (strømsvigt, meteornedslag osv osv)... At det her så er en bug og at Apple måske skulle begrænse scopet af Datadetectors (kan ikke lige se hvorfor de skal benyttes i et URL felt fx ;) er hvad det er og noget der bliver fikset så snart Apple har fundet en måde at gøre det der ikke kan udnyttes som et sikkerhedshul...

"Eller at der er en auto detekteret URL string der ikke lever op til at være valid. Noget der også børe resultere i processafslutning med extreme prejudice."

At bruger input ikke er valid bør ALDRIG lede til at processen termineres. Det er ukarakteristisk dårlig stil. En proces bør kun afsluttes når videre afvikling ikke kan forsvares. I et veldesignet operativ system/applikation er det kun når der er indikation på memory corruption.

Når en funktion opdager en indikation på at noget ikke er som det skal være (men ikke memory corruption) bør der kun meldes fejl. Hvis der er tale om et muligt sikkerhedsproblem bør funktionen melde fejl på en måde som garanterer at kalderen ikke kan fortsætte uanfægtet og er nødt til at håndtere fejlen. Her er en returkode ikke nok.

Det korrekte her vil være at kaste en exception. Det garanterer at program flowet ikke kan fortsætte, men det giver også kalderen mulighed for at finde et sted at kompensere og bringe applikationen ind i en kendt tilstand igen. I dette tilfælde kunne en fejlmeddelelse være i orden. Så ville du have fået en fejlmeddelelse efter det 3. / men ville stadig kunne taste og ændre URIen til en valid URI.

Men OS X mangler støtte for structured exception handling. Hvert enkelt programmeringssprog der benyttes kan have sin egen interne exception handling (fx C++). Men på tværs af API'er exceptions ikke benyttes fordi der ikke er nogen OS defineret måde at registrere handlere og kaste exceptions.

Programmøren har I dette tilfælde valgt at risikere brugerens data hellere end applikationens sikkerhed. Det er måske et ok valg når der ikke er bedre alternativer. Under et mere avanceret operativsystem havde han ikke behøvet at foretage det valg.

"Kære bruger, strengen du har indtastet er desværre ikke gyldig.

[OK]"

Du må være blevet vanvittig. Simpel validering hører da ingen steder hjemme i et moderne OS som OSX! Enhver ved da, at det er langt sejere, når et program crasher. Så kan man jo føle sig lidt som en 1337-hacker, når man crasher sidemandens Safari.