Was pas­siert ist: Char­lie Mil­ler, ein be­kann­ter Ent­wick­ler und Se­cu­ri­ty-Ex­per­te der iOS-Platt­form hat (nicht zum ers­ten Mal) ein Si­cher­heits­pro­blem ent­deckt. Dies­mal konn­te er nicht we­ni­ger als be­lie­bi­gen, nicht-si­gnier­ten Code in einer An­wen­dung des Apps­to­res zur Aus­füh­rung brin­gen, wie er in einem Video de­mons­triert. Dar­auf­hin hat Apple nicht nur seine Tes­t­an­wen­dung aus dem Apps­to­re ent­fernt, son­dern ihm auch sei­nen De­ve­l­oper Key ent­zo­gen - damit ist es ihm nicht mehr mög­lich, An­wen­dun­gen für das iPad oder iPho­ne zu ent­wi­ckeln.

Hin­ter­grund

App­les Se­cu­ri­ty-Kon­zept ba­siert auf Code­si­gning und einem Re­view­pro­zess. Eine An­wen­dung, die in den Apps­to­re soll (die ein­zi­ge Quel­le für Soft­ware im iOS-Uni­ver­sum), wird zu­nächst von Apple in einem Re­view­pro­zeß un­ter­sucht. Die De­tails die­ses Re­view­pro­zes­ses sind un­be­kannt, es wird dabei je­doch auf De­si­gn­kri­te­ri­en (muß dem Sty­le­gui­de ent­spre­chen), In­halt (Ju­gend­schutz, nack­te Haut, volks­ver­het­zen­de Aus­sa­gen, etc.) und Si­cher­heit (bös­wil­li­ge, ver­steck­te "Zu­satz­funk­tio­nen") ge­ach­tet. Hier­zu wird je­doch nicht der Source­code, son­dern nur das fer­ti­ge Bi­när­pa­ket her­an­ge­zo­gen. Ist der Test zur Zu­frie­den­heit von Apple, er­hält die An­wen­dung eine di­gi­ta­le Si­gna­tur und wird in den Apps­to­re ge­stellt.
iPho­ne und iPad prü­fen bei dem Ver­such, eine An­wen­dung zu in­stal­lie­ren, deren Si­gna­tur. Nur mit einer gül­ti­gen Si­gna­tur wird die An­wen­dung in­stal­liert - alles an­de­re muß drau­ßen blei­ben. Da aber Ent­wick­ler ihre An­wen­dun­gen tes­ten müs­sen, er­hal­ten sie (gegen eine jähr­li­che Ge­bühr) einen spe­zi­el­len Ent­wick­ler­schlüs­sel, der es ihnen er­laubt, auf ihren ei­ge­nen Ge­rä­ten (und nur die­sen) An­wen­dun­gen zu in­stal­lie­ren.

Fail 1: "Pro­fes­sio­nel­ler" Um­gang mit Si­cher­heits­lü­cken

Char­lie Mil­ler hat nun - wie­der ein­mal - ein Pro­blem ent­deckt und dies öf­fent­lich ge­macht. Leute mit aus­rei­chend kri­mi­nel­ler En­er­gie hät­ten sol­che Schwä­chen für sich be­hal­ten, selbst aus­ge­nutzt oder ver­kauft (es gibt für Ze­ro-Day Ex­ploits in­zwi­schen wohl einen durch­aus lu­kra­ti­ven Markt). Er ent­schied sich aber, die Öf­fent­lich­keit zu in­for­mie­ren und so Apple die Mög­lich­keit zu geben, das Pro­blem zu be­he­ben.
Ei­gent­lich soll­te Apple sol­chen Leu­ten dank­bar sein - statt­des­sen aber wirft Apple ihn aus dem Ent­wick­ler­pro­gramm (was dank des re­strik­ti­ven Ein­sat­zes DRM-Tech­no­lo­gi­en mög­lich ist). So geht man nicht mit sol­chen Leu­ten um!

Fail 2: Der Re­view-An­satz

App­les Se­cu­ri­ty-Kon­zept fußt dar­auf, daß wäh­rend des Re­views bös­wil­li­ge Pro­gram­me er­kannt wer­den. Nach der In­stal­la­ti­on gibt es (im Ge­gen­satz zu An­dro­ids Pri­vi­le­ges) keine wei­te­ren Maß­nah­men, wel­che den Scha­den in ir­gend­ei­ner Weise ein­schrän­ken; so hat bei­spiels­wei­se jede An­wen­dung Zu­griff auf das In­ter­net - egal, ob sie es für ihren (of­fi­zi­el­len) Zweck bräuch­te oder nicht. Eine sehr ähn­li­che De­bat­te er­leb­ten wir ge­ra­de beim Staats­tro­ja­ner: Auch hier ging es darum zu be­wei­sen, daß das Pro­gramm eine be­stimm­te Funk­tio­na­li­tät nicht hat. Aus Sicht der theo­re­ti­schen In­for­ma­tik ist das nicht mög­lich - das be­sagt das Hal­te­pro­blem. Aber auch in der Pra­xis kann man Funk­tio­na­li­tät be­lie­big kom­pli­ziert ver­schlei­ern, so daß die Re­view­er bei Apple (wel­che ja tau­sen­de Ein­rei­chun­gen pro Tag re­view­en müs­sen) hier kaum eine rea­lis­ti­sche Chan­ce haben dürf­ten. Of­fen­bar ge­lang es Char­lie Mil­ler, sol­che Zu­satz­funk­tio­nen am Re­view­pro­zeß von Apple vor­bei­zu­schmug­geln - und de­mons­trier­te so die Un­si­cher­heit und Un­voll­stän­dig­keit des Pro­zes­ses, und rüt­tel­te damit quasi an den Grund­fes­ten des iOS-Se­cu­ri­ty-Kon­zep­tes.

Fail 2b: Die Ar­ti­kel­über­schrift bei t3n

Der Be­richt bei t3n hier­zu ist be­ti­telt mit Feh­ler in App­les Code­si­gning re­du­ziert Si­cher­heit auf An­dro­id-Ni­veau. Das ist - wie man aus der vo­ri­gen Be­schrei­bung sehen kann - schlicht falsch. Der Feh­ler re­du­zier­te die Si­cher­heit unter An­dro­id-Ni­veau... ge­nau­er Ge­sagt in Rich­tung null. Eine An­wen­dung unter An­dro­id kann (egal, ob bös­wil­lig oder of­fi­zi­ell) nur die Funk­tio­nen nut­zen, wel­che der Be­nut­zer bei der In­stal­la­ti­on ab­ge­nickt hat. Dafür sorgt das Kon­zept der Pri­vi­le­gi­en. Na­tür­lich setzt das eine ge­wis­se Auf­merk­sam­keit des Users vor­aus ("Wieso braucht ein Te­tris-Clo­ne Zu­griff auf meine ak­tu­el­le Po­si­ti­on und das In­ter­net? Nein, das in­stal­lie­re ich lie­ber nicht"), und auch an der Gra­nu­la­ri­tät der Pri­vi­le­gi­en gibt es be­rech­tig­te Kri­tik... aber das ist immer noch deut­lich bes­ser als der Schutz unter iOS.

Edit: Mehr De­tails...

Die­ser Ar­ti­kel bei Heise er­läu­tert ein paar tech­ni­sche De­tails mehr. Ich hatte zu­nächst ver­mu­tet, daß Mil­ler einen Feh­ler in der Re­view-Me­tho­dik (und damit eine Mög­lich­keit, Code am Re­view­pro­zeß "vor­bei­zu­schmug­geln") aus­fin­dig ge­macht hat; dem Ar­ti­kel nach liegt das Pro­blem aber in der neuen Ja­va­Script-En­gi­ne Nitro; nach einer JIT-Kom­pi­lie­rung von Ja­va­scripts hat das Kom­pi­lat wohl alle Kom­pe­ten­zen einer (si­gnier­ten) An­wen­dung. Nor­ma­ler­wei­se soll­te nur der Brow­ser Zu­griff auf Nitro haben - ir­gend­wo hier dürf­te die von Mil­ler ent­deck­te Lücke ste­cken.