[img=right]http://www.macfreak.org/base/data/news/images/pwn2own_browsers.png[/img]Op ZDnet is een zeer interessant interview verschenen met Charlie Miller. Dit is de persoon die het in enkele seconden voor elkaar kreeg om een MacBook te hacken die voorzien was van alle security updates en dergelijke van Apple.

Wat mij vooral opvalt in dit interview is hoe makkelijk het volgens hem is  om een Mac te hacken:

For all the browsers on operating systems, the hardest target is Firefox on Windows. With Firefox on Mac OS X, you can do whatever you want.  There’s nothing in the Mac operating system that will stop you.

Van alle browsers op verschillende systemen is Firefox onder Windows de lastigste. Met Firefox op Mac OS X kan je doen wat je wilt. Er is niets in het systeem op de Mac dat je tegenhoudt.

We zijn dan als Mac gebruikers relatief veilig voor virussen en dergelijke, maar als ik dit zo lees liggen er wel gevaren op de loer...

Bron: ZDnet

Er moet wel het een en ander genuanceerd worden hier. De
hack vond niet letterlijk in 5 seconden plaats, maar was al
lang van tevoren voorbereid.

Bovendien blijkt wel dat deze man het vooral op de Mac
voorzien heeft. Zo zegt hij dat hij niet eens gekeken heeft
of de hack ook op Windows werkt, maar vervolgens heeft hij
wel vele aannames over de veiligheid op Mac OS X vs Windows.
Daar valt voor mij weinig waarde aan te hechten zolang dit
niet (goed) onderbouwd wordt.

Het enige wat je er wijs van wordt, is dat de man zegt dat address space randomization niet goed genoeg is in OS X. Hij introduceert een verkeerd stuk code, mogelijk door een buffer overflow te misbruiken, en hij weet vooraf waar die code zich zal bevinden. Daardoor kan hij het systeem misbruiken. Het is (voor zover ik weet) inderdaad waar dat dat op OS X nog minder goed geregeld is dan in de nieuwste versie van Windows.

Verder vind ik het nogal een lompe houding die de man uitstraalt. Hij zegt 'ik geef de bugs die ik ontdek niet meer door aan Apple, dat zoeken ze lekker zelf maar uit'. En hij is daarmee dus het toonbeeld van een hacker die puur voor eigen gewin werkt en helemaal niet 'voor het nut van het algemeen', wat ze nogal eens beweren bij dit soort 'onderzoek'.

Appleidee om 9:42, 24-03-2009

Daar valt voor mij weinig waarde aan te hechten zolang dit
niet (goed) onderbouwd wordt.

Hij onderbouwt het wel. De beveiliging voor dit type hacks is
op OSX nog niet volledig. Goede beveiliging is pas mogelijk
op een 64 bit systeem als Snow Leopard.
De geheugenbeveiliging van Vista is overeenkomstig met FreeBSD.
Apple werkt nauw samen met het BSD-security team, dus heb ik er
alle vertrouwen in dat Snow Leopard qua beveiliging op gelijke
hoogte gaat komen.

Zie http://blogs.zdnet.com/security/?p=1325

ben toch wel benieuwd naar de vulnerabilities van Leopard dan...

Spooter om 13:44, 24-03-2009
ben toch wel benieuwd naar de vulnerabilities van Leopard dan...

Zo moet je het niet zien. Het zijn fouten in applicaties als Safari.
Geheugenruimte wordt door hackers gemanipuleerd (bekend als
buffer-overflow, met talloze varianten) om code uit te voeren
die ze zelf in het geheugen hebben geplaatst.

Nu zijn er diverse oplossingen om dit moeilijker te maken,
die zitten echter (haast) niet in Leopard, waardoor het voor hackers
eenvoudiger is om het juiste adres te vinden.
Niet dat het een makkie is wnat deze Charlie was er al een paar
maanden mee bezig. Overigens biedt de server versie van leopard
meer bescherming dan de ‘gewone’ versie.

Even voor de volledigheid: ASLR is zowel op 32-bit als op 64-bit toepasbaar. Windows XP had al een (eenvoudige) ASLR, maar Windows Vista heeft een vrij aardige Address Space (Layout) Randomization.

Het heeft niets te maken met de woordlengte van een processor. 32-bit,  64-bit of 128-bit. Het is kwalijk dat Apple CLAIMT Address Space Randomization te hebben in Leopard, maar dat het feitelijk alleen op 64-bits werkt en dan ook nog eens alleen op de Intel processoren (G5 is ook 64-bits).

Crux? Het overgrote deel van Leopard is 32-bit. Had dit anders gekunt? Ja natuurlijk. Apple had ASR ook op 32-bits kunnen bewerkstelligen. Maar dit hebben ze niet gedaan.

Daarnaast is ook nog eens zo dat Apple heel vaak erg laks reageert op meldingen van bugs. Het is bekend dat Apple nu niet bepaald het summum van klantcommunicatie. Ik kan zo'n Charlie best begrijpen: op een gegeven moment heb je er de balen in en doe je geen moeite meer.

Voor wat betreft fouten in Applicaties: is ten dele waar. Ja, er zijn fouten in genoemde applicaties. Maar dat geld ook voor Windows. Echter, door (ondermeer) de AS(L)R-beveiliging is het moeilijker om met de fouten van de toepassingen te misbruiken onder Windows.

Onder MaOS X kan dit dus klaarblijkelijk wel. Daar zit de crux. Het is dus niet het programma, maar het is het OS.

Nu moet dit overigens ook nog binnen de context geplaatst worden, want MacOS X kent wel een 'sandbox'-methode.  Maar, nu komt het: ook hier geld dat MacOS X Leopard deze mechanismen sproadisch gebruikt.

Vals gevoel van veiligheid. Op de Marketingpagina's van Leopard staat: Address Space Randomization en Sandboxing.

Welnu: Sandboxing wordt nauwelijks of niet correct gebruikt en van Address Space Randomization is vrijwel geen sprake.

Apple, Apple, Apple ... veel beloven weinig geven, doet de marketingguru's in vreugde leven.

Wat mij betreft vraagt Cuppertino om eens goed ge(h/p)a(c)kt te worden. Dusdanig dat men weer de oude vertrouwde kwaliteit gaat leveren. Want klaarblijkelijk zijn de dames en heren in Californie ingedut met al dat succes.

Alleen al hierom zou ik eigenlijk van Apple eisen dat 10.6 een GRATIS of 'special priced' (max 30 euro) upgrade wordt. 10.5 is op de GUI-gimmicks low-level gezien niet hetgeen Apple beloofd heeft.

Groet,


Doctor

Doctor Apple om 16:23, 24-03-2009

Het heeft niets te maken met de woordlengte van een processor. 32-bit,  64-bit of 128-bit.

Wel degelijk. Lees de documentatie er maar op na (van bijvoorbeeld IBM-security experts).
In 32-bit kan het wel maar is het niet echt zinvol. Anders was XP-toch ook niet zo gemakkelijk
te hacken geweest? Hackers achterhalen dan toch nog vrij gemakkelijk het geheugenadres.
In 64-bit is het vrijwel niet te doen.

Appleidee om 9:42, 24-03-2009
De hack vond niet letterlijk in 5 seconden plaats, maar was al
lang van tevoren voorbereid.

Ja, dus? Zijn dat verzachtende omstandigheden? Feit blijft dat het systeem gehackt is. Natuurlijk is daar  voorbereiding voor nodig, maar dat maakt het niet minder ernstig.

En die lompe houding vind ik ook wel meevallen. Voor Apple zijn de bedragen die hij noemt een druppel op de gloeiende plaat. Ze mogen juist blij zijn met dit soort figuren, wellicht houdt het ze scherp en behoed het ons voor kwalijke(re) zaken.

Het lijkt me eerder dat de houding van Apple voor wat betreft security op een hoger niveau getild mag worden, daar plukken we allemaal de vruchten van nietwaar?

Blender om 16:42, 24-03-2009

Citaat

Doctor Apple om 16:23, 24-03-2009

Het heeft niets te maken met de woordlengte van een processor. 32-bit,  64-bit of 128-bit.

Wel degelijk. Lees de documentatie er maar op na (van bijvoorbeeld IBM-security experts).
In 32-bit kan het wel maar is het niet echt zinvol. Anders was XP-toch ook niet zo gemakkelijk
te hacken geweest? Hackers achterhalen dan toch nog vrij gemakkelijk het geheugenadres.
In 64-bit is het vrijwel niet te doen.

Even twee zaken uit elkaar halen: XP is gemakkelijk te kraken geweest, maar dat is niet enkel toe te schrijven aan ASR en 32-bit. De gehele architectuur was nogal 'gammel'. Dit is echt heel erg verbeterd met Vista. Nog steeds niet ideaal, maar aanmerkelijk beter. Op sommige fronten zelfs goed te noemen.

Daarnaast werkt Address Space Randomization onder Vista op zowel 32-bit als 64-bit. Ik ben met je eens dat een 32-bits adressering minder veilig te krijgen is met AS(L)R dan 64-bit. Het punt zit hem gewoon in de grootte van het geheel.

We spreken hier over exponenten. 2^32 versus 2^64 (tot de macht) is een dramatisch verschil:

4,294,967,296 bytes te adreseren in 32-bit (4 gigabyte)
18,446,744,073,709,551,616 bytes in 64-bit (18 exabyte)

Oftewel: op 32-bits systemen kun je maximaal in 4 gigabyte 'randomizeren' tegenover 18 exabyte

Even ter illustratie:

1073741824 gigabytes -> 1048576 terabytes -> 1024 petabytes -> 1 exabyte

Dat is dus het verschil tussen 32-bit en 64-bit in grote lijnen.

Hierdoor is ook Microsoft's implementatie op 32-bit systemen verre van ideaal. Address Space Randomization op 32-bit geeft niet het gewenste resultaat: punt. Daarover ben ik eens.

Maar, Apple's claim dat MacOS X Address Space Randomization en Sandboxing ondersteund is wel heel erg 'soft'. Daarnaast begrijp ik iets niet: als Apple claimt dat 32-bit niet veilig genoeg is: swah. Maar ... waarom ondersteund de PowerPC build van Apple geen ASR op de G5 welke 100% 64-bit is met zelfs een 128-bit rekeneenheid ?

Credietcrisis in Cupertino? Ze hebben alle code op 32-bits gecompileerd, zowel voor x86 als PPC?

Maar goed, we zullen zien hoe Apple de zaken met Snow Leopard aanpakt.

Groet,


Doctor Apple

Doctor Apple om 23:16, 24-03-2009

Apple claimt dat 32-bit niet veilig genoeg is: swah

Het is niet een claim van Apple het is de algemeen heersende opinie
van beveiligingsexperts. Dat is toch wat anders. Ik heb Apple er niets over horen
zeggen, ze zijn namelijk wat stilletjes op dit punt. En dat is marketing technisch gezien
wel zo verstandig.