C, PHP, VB, .NET

В средата на февруари Епъл пуснаха критично обновяване на iOS. Версията беше iOS 7.0.6. После се оказа, че засяга всякакви i-работи, че дори и версии на OSX операционната система. Този бъг позволяваше да се прави man in the middle атака срещу iPhone, iPad и други епъл устройства. А за който не си е обновил софтуера, това важи все още и ще важи – уязвимостта е при клиентските приложения :)

Грешката идва при прилагането на т.нар. „forward secrecy“ проверка. Идеята е да се използва „ephemeral ключ“ – трафика не се криптира само с public key, но и с допълнителен временно генериран ключ, който гарантира, че дори в бъдеще ако някой открадне основния private key, той няма да успее да декриптира „стар“ трафик, защото няма да има ephemeral ключа. Проблемът на Apple се коренеше във файла им sslKeyExchange.c – официалната SSL/TLS библиотека на Епъл. В нея се виждаше следния код:

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;
}

Нека пропуснем подробностите и да караме по-общо и по-грубо – явно има код, който прави три проверки за checksum – имаме три if-а с извикване на SSLHashSHA1.update() функцията. Ако някоя от тях даде резултат различен от 0, се отива на маркера „fail“, който очевидно връща число – статус, който означава, че сертификата не е валиден. Иначе, ако всичко е наред, статуса ще е 0.

Къде е грешката в кода тук? Вижте вторият if – „в него“ има два пъти „goto fail„. А всъщност… те не са в пограмен блок! Тоест вторият „goto fail“ ще се изпълни със сигурност – той е самостоятелна операция, която се изпълнява без условен оператор. Тоест тези проверки дават гарантирано преминаване в блока за грешка – fail, – независимо какво се проверява!

Ето и къде всъщност е проблема – представете си, че първите две проверки дават валиден сертификат. Тоест във втория if условието „err = SSLHashSHA1.update(&hashCtx, &signedParams))“ e записало в променливата „err“ число равно на нула. Свободният „goto fail“ незабавно ще изпрати програмата във „fail“ блока, а там се прави… просто „return err;„. Тоест функцията връща резултат err равен на 0. По този начин третата проверка – „if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)“ – никога не е извършена, а функцията е върнала резултат 0, който означава, че всичко е наред.

Решението на този проблем е ясно – просто излишния ред в кода трябва да се премахне. Проблемите, който той създава обаче са големи – хакерите могат да си генерират сами невалидни SSL сертификати, които не отговарят на последната проверка, а браузъра на i-устройството ще ги приеме за валидни. Имате предпоставка (практически лесно осъществима) за man-in-the-middle атака.

Източник: https://www.imperialviolet.org/2014/02/22/applebug.html