[iOS] Werking Jailbreakme.com

[BKJ]

Heb even eea uitgezocht naar werking van Jailbreakme.com. Dit heb ik gedaan:

1. Firefox met User Agent Switcher op iPhone 4-agent naar http://www.jailbreakme.com gesurft
2. Source gedownload
3. Javascript Tidy eroverheen
4. Source geanalyseerd

Met een paar 'alert()''s op de juiste plek kom je een heel eind.

Aan de hand van de user agent string weten ze welke iPhone en welk OS je draait. Op basis hier van sturen laden ze een externe url in met pdf'jes(??). Zie deze opendir: http://www.jailbreakme.com/_/

Deze pdf'jes worden door middel van:

JavaScript:

new Image()

ingeladen.

Vanaf daar raak ik het spoor bijster....

Hoe gaat de jailbreak verder? Wat doet de JS? Waarvoor zijn de pdf'jes?

[Verwijderd]

Door de afbeeldingen in te laden forceren ze het OS om deze te gaan renderen via de PDF renderer. Hier zit een exploit in waardoor ze dmv buffer overflow data kunnen injecteren in het code deel van het geheugen.

Vervolgens zal het OS deze code draaien en vanaf dat moment kunnen ze doen wat ze willen.

[BKJ]

Verwijderd schreef op maandag 02 augustus 2010 @ 15:46:
Door de afbeeldingen in te laden forceren ze het OS om deze te gaan renderen via de PDF renderer. Hier zit een exploit in waardoor ze dmv buffer overflow data kunnen injecteren in het code deel van het geheugen.

Vervolgens zal het OS deze code draaien en vanaf dat moment kunnen ze doen wat ze willen.

Als ik via Safari op de iPhone de pdf rechtstreeks opvraag dan gebeurt er iets anders nl.

[Verwijderd]

jups er word een safari exploit gebruikt om cydia te installeren op de iphone.
net als vroegah in de good old days van iphone 1.
pdf kan gebruikt worden als container om cydia in te verstoppen. geen idee waarom anders een pdf.

[ Voor 27% gewijzigd door Verwijderd op 02-08-2010 15:49 ]

[Verwijderd]

Verwijderd schreef op maandag 02 augustus 2010 @ 15:48:
jups er word een safari exploit gebruikt om cydia te installeren op de iphone.
net als vroegah in de good old days van iphone 1.
pdf kan gebruikt worden als container om cydia in te verstoppen. geen idee waarom anders een pdf.

MacOS icm de iPhone heeft geen enkele mogelijkheid om te voorkomen dat er code loopt in het datadeel of dat een buffer overflow dergelijke exploits kan veroorzaken.

Dit maakt het zo lek als bijvoorbeeld Windows XP

Safari op de iPhone is qua beveiliging ook het niveau IE6, vrijwel geen enkele security features.

[ Voor 8% gewijzigd door Verwijderd op 02-08-2010 15:54 ]

[Verwijderd]

Verwijderd schreef op maandag 02 augustus 2010 @ 15:54:
[...]

MacOS icm de iPhone heeft geen enkele mogelijkheid om te voorkomen dat er code loopt in het datadeel of dat een buffer overflow dergelijke exploits kan veroorzaken.

Dit maakt het zo lek als bijvoorbeeld Windows XP

Safari op de iPhone is qua beveiliging ook het niveau IE6, vrijwel geen enkele security features.

ik vind het iig weer ideaal deze jailbreak. ik was zo klaar op mijn 3gs.

[BKJ]

Verwijderd schreef op maandag 02 augustus 2010 @ 16:03:
[...]

ik vind het iig weer ideaal deze jailbreak. ik was zo klaar op mijn 3gs.

offtopic:
Overigens heb ik het nog niet voor elkaar op mijn nieuwe iphone4. Blijft hangen op paars scherm, dus het is nog niet ideaal...

[Verwijderd]

BKJ schreef op maandag 02 augustus 2010 @ 16:06:
[...]

offtopic:
Overigens heb ik het nog niet voor elkaar op mijn nieuwe iphone4. Blijft hangen op paars scherm, dus het is nog niet ideaal...

Cache en cookies al eens leeggegooid ?

[kronolith]

BKJ schreef op maandag 02 augustus 2010 @ 16:06:
[...]

offtopic:
Overigens heb ik het nog niet voor elkaar op mijn nieuwe iphone4. Blijft hangen op paars scherm, dus het is nog niet ideaal...

Eerst gesyncht met iTunes? Reboot wil trouwens ook wel eens helpen

[Petervanakelyen]

Of de mirror van de site geprobeerd? Ik kan aannemen dat heel de wereld nu zijn iDevice aan het jailbreaken is

[Noxious]

Behoorlijk tricky dus, je zou haast bang worden met een iPhone naar een onbekende site te surfen omdat iedere willekeurige code gedraait kan worden. Sterker nog, het zou ook in ads op 'normale' websites kunnen terugkomen zelfs.. brr

[kronolith]

Noxious schreef op maandag 02 augustus 2010 @ 16:25:
Behoorlijk tricky dus, je zou haast bang worden met een iPhone naar een onbekende site te surfen omdat iedere willekeurige code gedraait kan worden. Sterker nog, het zou ook in ads op 'normale' websites kunnen terugkomen zelfs.. brr

Inderdaad, denk je naar tweakers te gaan, heb je ineens een JB op je iphone

[CyBeR]

Verwijderd schreef op maandag 02 augustus 2010 @ 15:54:
[...]

MacOS icm de iPhone heeft geen enkele mogelijkheid om te voorkomen dat er code loopt in het datadeel of dat een buffer overflow dergelijke exploits kan veroorzaken.

NX-bits bedoel je? Volgens mij ondersteunt heel ARM dat niet.

Edit: excuseer, vanaf armv6 heeft 't gebeuren een NX-bit (alleen noemen ze 't XN). iPhones gebruiken armv7, dus ik neem dan aan dat dat erin zit. Rest de vraag waarom 't niet gebruikt wordt.

Dit maakt het zo lek als bijvoorbeeld Windows XP

Safari op de iPhone is qua beveiliging ook het niveau IE6, vrijwel geen enkele security features.

Lekker onderbouwd weer.

[ Voor 15% gewijzigd door CyBeR op 02-08-2010 16:32 ]

[painkill]

Je moet altijd nog zelf eerst de pdf link openen, of zoals op die site een slider schuiven.
Straks komt er nog een antivirus etc voor de iphone

[Petervanakelyen]

Als ze het er als een slider kunnen laten uitzien, zullen een paar slimmeriken het er ook wel als nog iets onschuldigers uit kunnen laten zien. Maar ik verwacht wel dat de bug in kwestie redelijk snel door Apple gefixt zal worden. Ze vinden jailbreaken blijkbaar niet zo leuk

[Noxious]

painkill schreef op maandag 02 augustus 2010 @ 16:29:
Je moet altijd nog zelf eerst de pdf link openen, of zoals op die site een slider schuiven.
Straks komt er nog een antivirus etc voor de iphone

Mwah je kan ook prima een redirect doen of zaken laten uitvoeren door JavaScript.

[Verwijderd]

CyBeR schreef op maandag 02 augustus 2010 @ 16:27:
[...]


NX-bits bedoel je? Volgens mij ondersteunt heel ARM dat niet.

Edit: excuseer, vanaf armv6 heeft 't gebeuren een NX-bit (alleen noemen ze 't XN). iPhones gebruiken armv7, dus ik neem dan aan dat dat erin zit. Rest de vraag waarom 't niet gebruikt wordt.

Merknaam maakt me weinig uit. Ik doel op de functie waarmee de CPU verteld kan worden in welk deel van het geheugen code staat (en dus de instruction pointer heen mag wijzen) en in welk deel van het geheugen data staat en dus nooit code uitgevoerd mag worden.
ARM noemt het XN, AMD NX of EVP en Intel XD, maar komt allemaal op hetzelfde neer.

Sinds Snow Leopard heeft Mac OS X ondersteuning voor deze functie op de desktop (zij noemen het Execute Disable tov eXecute Disable van Intel) maar alleen voor 64-bit applicaties. 32-bit applicaties maken onder Mac OS X dus niet gebruik van deze functie.

Ik denk dat Apple minder aandacht besteed aan software beveiliging op de iPhone, maar eerder de focus leggen op user experience en daarbij de performance van het ding.

Daarnaast heeft Mac OS X geen enkele vorm van buffer overflow bescherming, maar dat ligt weer iets complexer.

Lekker onderbouwd weer.

Lekkere dooddoener weer.

Safari op de iPhone heeft amper beveiligingsfeatures aan boord, niet meer dan logisch, maar op dat niveau is het gelijkwaardig aan IE6. IE6 is een andere bekende browser die ook weinig tot geen beveiligingsfeatures in zich heeft. Lijkt me een prima vergelijking dus.

[ Voor 3% gewijzigd door Verwijderd op 02-08-2010 17:07 ]

[Noxious]

Is dat vergelijkbaar met DEP (Data Execution Prevention) onder Windows?

[CyBeR]

Verwijderd schreef op maandag 02 augustus 2010 @ 17:03:
[...]

Lekkere dooddoener weer.

Safari op de iPhone heeft amper beveiligingsfeatures aan boord, niet meer dan logisch, maar op dat niveau is het gelijkwaardig aan IE6. IE6 is een andere bekende browser die ook weinig tot geen beveiligingsfeatures in zich heeft. Lijkt me een prima vergelijking dus.

En wat versta jij onder 'beveiligingsfeatures'? Afgezien van NX-bits dan dus.

Noxious schreef op maandag 02 augustus 2010 @ 17:05:
Is dat vergelijkbaar met DEP (Data Execution Prevention) onder Windows?

Ja, dat is hetzelfde.

[ Voor 18% gewijzigd door CyBeR op 02-08-2010 17:09 ]

[Verwijderd]

Noxious schreef op maandag 02 augustus 2010 @ 17:05:
Is dat vergelijkbaar met DEP (Data Execution Prevention) onder Windows?

Niet vergelijkbaar, dat is het

CyBeR schreef op maandag 02 augustus 2010 @ 17:07:
[...]


En wat versta jij onder 'beveiligingsfeatures'? Afgezien van NX-bits dan dus.

Buffer overflow bescherming in de browser zelf bijvoorbeeld, plus een strak certificeringsprogramma om te zorgen dat Apple's eigen plugins (en die Apple meelevert van hun eigen partners) dit ook hebben. Of een sandbox achtige omgeving waarin de browser (of liever nog de losse browser threads) draait.
En een tussenlaag tussen de browser en het OS zodat de browser geen toegang heeft tot de hardware, maar dit is niet echt realistisch op een platform als de iPhone.

Welke beveiligingsfeatures heeft Safari op de iPhone volgens jou wel die IE6 niet heeft dan?

[ Voor 5% gewijzigd door Verwijderd op 02-08-2010 17:14 ]

[CyBeR]

Verwijderd schreef op maandag 02 augustus 2010 @ 17:13:
[...]


Buffer overflow bescherming in de browser zelf bijvoorbeeld, plus een strak certificeringsprogramma om te zorgen dat Apple's eigen plugins (en die Apple meelevert van hun eigen partners) dit ook hebben.

Punt is alleen wel dat dit soort dingen nu juist de foutjes in dat soort maatregelen trachten te misbruiken. Dat gaat niet zomaar weg. Met de juiste LD_PRELOAD kun je hello world nog haxx0ren

Of een sandbox achtige omgeving waarin de browser (of liever nog de losse browser threads) draait.

Volgens mij is dit er al. In dit geval wordt ook geen fout in Safari misbruikt maar een in de PDF library.

En een tussenlaag tussen de browser en het OS zodat de browser geen toegang heeft tot de hardware, maar dit is niet echt realistisch op een platform als de iPhone.

Wat voor'n tussenlaag?

Welke beveiligingsfeatures heeft Safari op de iPhone volgens jou wel die IE6 niet heeft dan?

Geen idee. IE6 is toch wel een van de dingen waarvoor ik me compleet niet kan interesseren.

[Verwijderd]

Zwaar offtopic.

Alles valt uiteindelijk te hacken. Al soldeer je het EEPROM eruit en soldeer je je eigen erin, of pas je deze hard aan via de JTAG aansluiting die met wat krassen op de printplaat wel te vinden is.

Punt is alleen dat je door het bezoeken van een website (op een normale manier in de bijgeleverde browser zonder dat bevestiging noodzakelijk is) je hele OS kunt veranderen. Dat geeft toch wel wat aan qua niveau en is redelijk onvoorstelbaar op de desktop.

Mocht zoiets gebeuren onder bijvoorbeeld IE8 in protected mode en je roept Adobe's eigen PDF reader aan die vervolgens op z'n gat gaat door een lek krijg je netjes de melding dat Internet Explorer is vastgelopen. De execution is op dat moment al onderbroken, dus een exploit is niet mogelijk, er wordt netjes een crashreport gemaakt en eventueel verzonden en IE wordt opnieuw opgestart (om met een beetje geluk opnieuw op z'n gat te gaan, maar goed). Ook al zit het probleem dus in de PDF reader en niet in de browser zelf.
Ik neem voor het gemak aan dat het bij Safari op de desktop niet anders zal zijn, al weet ik niet hoe Safari plugins normaal aanroept, of dit in het eigen stukje beschermd geheugen is of losstaand (wat kwalijk zou zijn).

Een detail hierbij is ook nog eens dat je bij IE8 zelf een PDF plugin moet installeren en dus de exploit per definitie niet bestaat waar de plugin niet geinstalleerd is. Zo kun je er zelf voor kiezen om de (IMHO) rommel die Adobe produceert niet te installeren, maar voor een alternatief te gaan. Je kunt zelf onderzoeken of het gekozen alternatief veiliger is. Apple levert een PDF plugin mee op de iPhone, ik ga er dan vanuit dat ze toch wel minimale veiligheidseisen hebben.

[CH4OS]

CyBeR schreef op maandag 02 augustus 2010 @ 16:27:
Edit: excuseer, vanaf armv6 heeft 't gebeuren een NX-bit (alleen noemen ze 't XN). iPhones gebruiken armv7, dus ik neem dan aan dat dat erin zit. Rest de vraag waarom 't niet gebruikt wordt.

Dat het er in zit, is géén definitie dat het ook áán staat.

[Liegebeest]

Noxious schreef op maandag 02 augustus 2010 @ 16:25:
Behoorlijk tricky dus, je zou haast bang worden met een iPhone naar een onbekende site te surfen omdat iedere willekeurige code gedraait kan worden. Sterker nog, het zou ook in ads op 'normale' websites kunnen terugkomen zelfs.. brr

"Haast bang"? Nee, wat mij betreft sluit Apple dit gat vandaag nog. En gaan ze als de donder de boel eens wat beter controleren op gaten

[Verwijderd]

Er zijn nog tientallen andere ongepatchte gaten bekend die hiervoor misbruikt kunnen worden, maak je dus geen zorgen, het voorkomen van een jailbreak via bijvoorbeeld de browser hebben ze niet zomaar voor elkaar

[Liegebeest]

En laat ik me juist zorgen maken om al die andere root-exploitable gaten in de browser

[BKJ]

Hier een uitgebreide(re) uitleg van de Jailbreak:

http://digdog.tumblr.com/...th-pdf-flatedecode-filter