다니엘 흐루스카 며칠 전, 애플은 100번째 제품을 출시했습니다. iOS 7.0.6 업데이트, 우리가 당신에게 알려준 출시에 대해. 이 업데이트가 이전 iOS 6(버전 6.1.6) 및 Apple TV(버전 6.0.2)용으로도 출시되었다는 사실에 많은 사람들이 놀랐을 것입니다. 이것은 보안 패치이므로 Apple은 장치의 일부만 업데이트할 여유가 없습니다. 게다가 이 문제는 OS X에도 영향을 미칩니다. Apple 대변인 Trudy Muller에 따르면 OS X 업데이트는 가능한 한 빨리 출시될 것이라고 합니다.
이번 업데이트를 둘러싸고 왜 그렇게 과대광고가 벌어지고 있나요? 시스템 코드의 결함으로 인해 ISO/OSI 참조 모델의 관계 계층에서 보안 전송 시 서버 확인을 우회할 수 있습니다. 특히 서버 인증서 확인이 이루어지는 부분의 잘못된 SSL 구현이 문제입니다. 자세한 설명을 시작하기 전에 기본 개념을 설명하는 것을 선호합니다.
SSL(Secure Socket Layer)은 보안 통신에 사용되는 프로토콜입니다. 통신 당사자의 암호화 및 인증을 통해 보안을 달성합니다. 인증은 제시된 신원을 확인하는 것입니다. 예를 들어 실생활에서는 이름(신분증)을 말하고 상대방이 확인(인증)할 수 있도록 신분증을 보여주면 됩니다. 그런 다음 인증은 확인으로 나뉘는데, 이는 국가 신분증, 즉 신분증을 사용하여 사전에 제시하지 않고도 해당 사람이 귀하의 신원을 확인할 수 있는 경우입니다.
이제 간단히 서버 인증서를 살펴보겠습니다. 실생활에서 귀하의 인증서는 예를 들어 ID 카드가 될 수 있습니다. 모든 것은 각 주체가 개인 키와 공개 키라는 두 개의 키를 소유하는 비대칭 암호화를 기반으로 합니다. 전체적인 아름다움은 메시지가 공개 키로 암호화되고 개인 키로 해독될 수 있다는 사실에 있습니다. 이는 개인 키의 소유자만이 메시지를 해독할 수 있음을 의미합니다. 동시에 비밀 키를 통신 당사자 모두에게 전송하는 것에 대해 걱정할 필요가 없습니다. 그러면 인증서는 해당 정보로 보완되고 인증 기관에서 서명한 주체의 공개 키입니다. 예를 들어 체코 공화국의 인증 기관 중 하나는 Сeská Pošta입니다. 인증서 덕분에 iPhone은 해당 서버와 실제로 통신하고 있는지 확인할 수 있습니다.
SSL은 연결을 설정할 때 소위 비대칭 암호화를 사용합니다. SSL 핸드셰이크. 이 단계에서 iPhone은 해당 서버와 통신하고 있는지 확인하는 동시에 비대칭 암호화를 통해 모든 후속 통신에 사용되는 대칭 키가 설정됩니다. 대칭 암호화가 더 빠릅니다. 이미 작성한 바와 같이 서버 확인 중에 이미 오류가 발생했습니다. 이 시스템 취약점을 일으키는 코드를 살펴보겠습니다.
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;
}
두 번째 조건에서는 if 아래에서 두 개의 명령을 볼 수 있습니다 실패해;. 그리고 그것이 걸림돌이다. 그런 다음 이 코드는 인증서를 확인해야 하는 단계에서 두 번째 명령이 실행되도록 합니다. 실패해;. 이로 인해 세 번째 조건이 건너뛰게 됩니다. if 서버 확인이 전혀 없습니다.
이는 이 취약점을 아는 사람은 누구나 귀하의 iPhone에 가짜 인증서를 제공할 수 있다는 의미입니다. 당신 또는 iPhone에서는 암호화된 통신을 하고 있다고 생각할 것입니다. 반면에 귀하와 서버 사이에는 공격자가 있습니다. 이런 공격을 일컬어 중간자 (man-in-the-middle) 공격, 이는 대략 체코어로 번역됩니다. 중간자 공격 또는 가운데 사람. OS X 및 iOS에서 이 특정 결함을 이용한 공격은 공격자와 피해자가 동일한 네트워크에 있는 경우에만 실행될 수 있습니다. 따라서 iOS를 업데이트하지 않은 경우 공용 Wi-Fi 네트워크를 피하는 것이 좋습니다. Mac 사용자는 어떤 네트워크에 연결하고 해당 네트워크에서 어떤 사이트를 방문하는지 여전히 주의해야 합니다.
어떻게 이런 치명적인 오류가 OS X와 iOS의 최종 버전에 포함될 수 있었는지 믿을 수 없습니다. 잘못 작성된 코드를 일관되지 않게 테스트했을 수도 있습니다. 이는 프로그래머와 테스터 모두 실수를 한다는 것을 의미합니다. 이는 Apple의 경우 가능성이 낮아 보일 수 있으므로 이 버그가 실제로 소위 백도어라는 추측이 표면화됩니다. 뒷문. 최고의 백도어는 미묘한 실수처럼 보인다고 말하는 것은 당연합니다. 그러나 이는 아직 확인되지 않은 이론일 뿐이므로 단순히 누군가 실수를 했다고 가정하겠습니다.
귀하의 시스템이나 브라우저가 이 버그에 면역인지 확실하지 않은 경우 해당 페이지를 방문하십시오. gotofail.com. 아래 이미지에서 볼 수 있듯이 OS X Mavericks 7.0.1의 Safari 10.9.1에는 버그가 포함되어 있지만 iOS 7.0.6의 Safari에서는 모든 것이 정상입니다.
공격을 통해… 나는 오랫동안 그렇게 좋고 진심 어린 웃음을 본 적이 없습니다!
그럴 수도 있지만 저는 개인적으로 이 메시지가 어떤 식으로든 APPLE이 모든 사용자에게 보내는 메시지로 이해합니다(그리고 이 오류가 발생할 가능성에 대해 언급한 2가지 이상의 가능성은 실제라고 생각하지 않습니다). 둘 다 APPLE 사물의 일반 소유자에 대한 단순한 조롱입니다!
당신이 옳았다는 사실에 감사드립니다.
나는 이것이 진짜 실수라고 믿습니다. 한 브랜치가 한 줄 더 길다면 버전 관리 시스템에서 두 브랜치를 병합할 때 생성되었다고 상상할 수 있습니다. 어쨌든, 이것은 프로그래머가 블록에 본문이 있으면 한 줄이라도 포함하도록 강요하는 것이 타당하다는 것을 확인하는 또 다른 사례일 뿐입니다.
자세한 설명 감사드립니다!
토론 범위 밖에서 글을 써서 미안하지만 이제 idnes에서 더 큰 iPhone이 iPhablet이라고 불려야 한다는 내용을 읽었습니다. :-D 거의 잃어버릴 뻔했습니다.. :-D 모든 사과 애호가 여러분께 인사드립니다.
….. 와, 창의력이 서서히 사라지는 게 아니군요….. 어쩌면 그냥 오리일 수도 있겠네요!
안녕하세요. 업데이트 후 배터리 수명 문제가 있나요? iP5에 대한 많은 불만이 있은 후 새 배터리를 구입했기 때문에 거의 이틀 동안 지속되는 새 배터리가 있습니다. 업데이트 후 8시간만에 휴대폰이 죽어서 많이 사용하지 않게 되었습니다.
개인적으로 손전등에 문제가 등록되지 않았습니다. 예, 과거에는 그렇습니다. iOS를 백업하고 완전히 다시 설치하는 것이 항상 도움이 되었습니다. 도움이 되길 바랍니다.
오늘 그렇게 했는데 안타깝게도 아무런 변화가 없었습니다. :-/