Isara ang ad
Balita

iOS 7.0.6 at mga detalye ng pag-update ng SSL

Daniel Hruska
10

Ilang araw na ang nakalipas, inilabas ng Apple ang ika-daan Pag-update ng iOS 7.0.6, tungkol sa pagpapalabas na ipinaalam namin sa iyo. Maaaring marami ang nagulat na ang update ay inilabas din para sa mas lumang iOS 6 (bersyon 6.1.6) at Apple TV (bersyon 6.0.2). Ito ay isang patch ng seguridad, kaya hindi kayang i-update ng Apple ang isang bahagi lamang ng mga device nito. Higit pa rito, ang isyung ito ay nakakaapekto rin sa OS X. Ayon sa tagapagsalita ng Apple na si Trudy Muller, isang update sa OS X ang ilalabas sa lalong madaling panahon.

Bakit napakaraming hype ang pumapalibot sa update na ito? Ang isang depekto sa code ng system ay nagbibigay-daan sa pag-verify ng server na ma-bypass sa secure na paghahatid sa relational na layer ng modelo ng sangguniang ISO/OSI. Sa partikular, ang kasalanan ay isang masamang pagpapatupad ng SSL sa bahagi kung saan nagaganap ang pag-verify ng certificate ng server. Bago ako pumunta sa karagdagang paliwanag, mas gusto kong ilarawan ang mga pangunahing konsepto.

Ang SSL (Secure Socket Layer) ay isang protocol na ginagamit para sa secure na komunikasyon. Nakakamit nito ang seguridad sa pamamagitan ng pag-encrypt at pagpapatunay ng mga nakikipag-usap na partido. Ang pagpapatunay ay ang pagpapatunay ng ipinakitang pagkakakilanlan. Sa totoong buhay, halimbawa, sasabihin mo ang iyong pangalan (identity) at ipakita ang iyong ID para ma-verify ito ng ibang tao (authenticate). Ang pagpapatotoo ay nahahati sa pagpapatunay, na isang halimbawa lamang na may pambansang kard ng pagkakakilanlan, o pagkakakilanlan, kapag ang taong pinag-uusapan ay maaaring matukoy ang iyong pagkakakilanlan nang hindi mo ito ipapakita sa kanya nang maaga.

Ngayon ay mapupunta ako sandali sa sertipiko ng server. Sa totoong buhay, ang iyong sertipiko ay maaaring, halimbawa, isang ID card. Ang lahat ay batay sa asymmetric cryptography, kung saan ang bawat paksa ay nagmamay-ari ng dalawang susi - pribado at pampubliko. Ang buong kagandahan ay nakasalalay sa katotohanan na ang mensahe ay maaaring i-encrypt gamit ang pampublikong susi at i-decrypt gamit ang pribadong key. Nangangahulugan ito na ang may-ari lamang ng pribadong key ang makakapag-decrypt ng mensahe. Kasabay nito, hindi na kailangang mag-alala tungkol sa paglilipat ng lihim na susi sa parehong mga partido sa pakikipag-usap. Ang sertipiko ay ang pampublikong susi ng paksa na pupunan ng impormasyon nito at nilagdaan ng awtoridad sa sertipikasyon. Sa Czech Republic, ang isa sa mga awtoridad sa sertipikasyon ay, halimbawa, Česká Pošta. Salamat sa sertipiko, mapapatunayan ng iPhone na talagang nakikipag-ugnayan ito sa ibinigay na server.

Gumagamit ang SSL ng asymmetric encryption kapag nagtatatag ng koneksyon, ang tinatawag na SSL handshake. Sa yugtong ito, ang iyong iPhone ay nagpapatunay na ito ay nakikipag-usap sa ibinigay na server, at sa parehong oras, sa tulong ng asymmetric encryption, isang simetriko na susi ay itinatag, na gagamitin para sa lahat ng kasunod na komunikasyon. Mas mabilis ang simetriko na pag-encrypt. Tulad ng nasulat na, ang error ay nangyayari na sa panahon ng pag-verify ng server. Tingnan natin ang code na nagiging sanhi ng kahinaan ng system na ito.

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa,
SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen)

{
   OSStatus err;
   …

   if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
       goto fail;
   if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
       goto fail;
       goto fail;
   if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
       goto fail;
   …

fail:
   SSLFreeBuffer(&signedHashes);
   SSLFreeBuffer(&hashCtx);
   return err;
}

Sa pangalawang kondisyon if makikita mo ang dalawang utos sa ibaba goto fail;. At iyon ang hadlang. Ang code na ito ay nagiging sanhi ng pangalawang utos na maisakatuparan sa yugto kung kailan dapat ma-verify ang sertipiko goto fail;. Ito ay nagiging sanhi ng pangatlong kundisyon upang malaktawan if at hindi magkakaroon ng verification ng server.

Ang mga implikasyon ay ang sinumang may kaalaman sa kahinaang ito ay maaaring mag-alok sa iyong iPhone ng isang pekeng sertipiko. Ikaw o iyong iPhone, iisipin mong naka-encrypt ang iyong pakikipag-ugnayan, habang may umaatake sa pagitan mo at ng server. Ang ganitong pag-atake ay tinatawag man-in-the-middle attack, na halos isinasalin sa Czech bilang man-in-the-middle attack o tao kabilang. Ang isang pag-atake gamit ang partikular na depekto sa OS X at iOS ay maaari lamang gawin kung ang umaatake at ang biktima ay nasa parehong network. Samakatuwid, mas mabuting iwasan ang mga pampublikong Wi-Fi network kung hindi mo pa na-update ang iyong iOS. Ang mga gumagamit ng Mac ay dapat pa ring mag-ingat tungkol sa kung aling mga network sila kumokonekta at kung anong mga site ang kanilang binibisita sa mga network na iyon.

Ito ay lampas sa paniwala kung paano ang isang nakamamatay na error ay maaaring gawin ito sa mga huling bersyon ng OS X at iOS. Maaaring ito ay hindi pantay-pantay na pagsubok ng hindi magandang nakasulat na code. Nangangahulugan ito na ang programmer at ang mga tester ay magkakamali. Ito ay maaaring mukhang hindi malamang para sa Apple, at kaya lumalabas ang mga haka-haka na ang bug na ito ay talagang isang backdoor, ang tinatawag. pinto sa likuran. Ito ay hindi para sa wala na sinasabi nila na ang pinakamahusay na backdoors ay mukhang banayad na mga pagkakamali. Gayunpaman, ang mga ito ay hindi nakumpirma na mga teorya lamang, kaya't ipagpalagay natin na may nagkamali lang.

Kung hindi ka sigurado kung immune ang iyong system o browser sa bug na ito, bisitahin ang page gotofail.com. Tulad ng makikita mo sa mga larawan sa ibaba, ang Safari 7.0.1 sa OS X Mavericks 10.9.1 ay naglalaman ng isang bug, habang sa Safari sa iOS 7.0.6 ay maayos ang lahat.

Mga Mapagkukunan: iMore, Reuters
Zdroj
Pagtalakay
Mga Paksa: , , , , , , , , ,

Kaugnay



Karamihan sa nabasa mga artikulo

.