Apple lançou uma correção urgente de uma vulnerabilidade no seu SSL (Secure Sockets Layer) de código, usado para criar conexões seguras para sites através de Wi-Fi ou outras ligações, para seus dispositivos iPhone, iPad e iPod Touch.
A correção, que agora está disponível tanto para iOS 6 e iOS 7, parece ter sido introduzida em uma alteração de código feita antes do lançamento do iOS 6.0.
Ela também afeta computadores Mac rodando Mac OSX - e não há nenhuma correção anunciou ainda, embora a Apple diz que se está "em breve".
O bug, e sua descoberta, levantam uma série de questões. Aqui está o que sabemos, o que nós não sabemos, eo que esperamos saber. (Apple se recusou a comentar em relação a uma série de questões que colocamos sobre a vulnerabilidade.)
Como posso verificar se estou vulnerável?
Ir para gotofail.com e ver o que a mensagem que você recebe. Se tudo é bom vai ter uma mensagem verde. Em um dispositivo iOS, você receberá um aviso para atualizar. Se você estiver em um Mac, você quer pegar uma mensagem amarela (em um navegador seguro ressaltando que outras aplicações podem estar vulneráveis) ou uma mensagem de vermelho (dizendo-lhe para corrigir o seu browser).
O que devo fazer?
Se usa um iPhone, iPad ou iPod Touch, atualizar seu software operacional. Vá para Configurações -> Geral -> Atualização de Software.Para dispositivos que usam iOS 7, atualização para o iOS 7.0.6, para dispositivos iOS 6, que não podem ser atualizados para o iOS 7 (o iPhone 3GS ou iPod Touch 4G), atualização para 6.1.6.
Note-se que a Apple não está oferecendo uma atualização para o iOS 6 para dispositivos que podem ser atualizados para o iOS 7 (iPhone 4, iPad 2, etc). Para aqueles, suas únicas opções são atualizar ou viver perigosamente.
Se estiver usando um Mac em uma versão mais antiga do sistema operacional, ou seja, 10,8 ("Mountain Lion") ou anterior, você está seguro.
Se você estiver usando um Mac com o mais novo sistema operacional, 10,9 (ou "Mavericks"), não use o Safari para se conectar a sites seguros até que haja uma atualização. Use o Mozilla Firefox ou Google Chrome: eles usam o seu próprio código para conectar a sites seguros. Nenhum bug foi encontrado em que.
O que o bug faz?
Na teoria (e talvez, dependendo de quem sabia sobre isso, na prática) que poderia permitir que as suas ligações a sites seguros de ser espionado e / ou seus detalhes de login capturado. A atualização do software impede isso. O bug afetou o SSL / TLS conexão criptografada para locais remotos.
Qual é a importância de SSL / TLS?
Quando o seu dispositivo (portátil ou PC) se conecta a um site usando o SSL método / TLS (Secure Sockets Layer / Transport Layer Security), o site apresenta uma criptografia "certificado" cadeia de identificar-se e a autoridade que emitiu o certificado. O dispositivo já tem uma lista de autoridades emissoras que são confiáveis, e vai verificar o nome do site eo certificado apresenta com essa autoridade.
É um processo de quatro etapas:
• Sítio apresenta cadeia de certificados
• certificado de seu dispositivo verifica do site corresponde ao nome do site que você está no
• O dispositivo verifica se o certificado provém de autoridade emissora válido
• Seu navegador verifica que a assinatura da cadeia de certificado corresponde a chave pública do local .
• Sítio apresenta cadeia de certificados
• certificado de seu dispositivo verifica do site corresponde ao nome do site que você está no
• O dispositivo verifica se o certificado provém de autoridade emissora válido
• Seu navegador verifica que a assinatura da cadeia de certificado corresponde a chave pública do local .
Em teoria, um certificado que tem o nome errado para o site, ou que não tenha sido emitida pela autoridade, ou que esteja fora da data, não será confiável. Neste ponto, você receberá um aviso no seu navegador dizendo que há algo errado e que você não deve continuar ou seus dados podem estar em risco.
Um certificado falsificado pode significar que o site que você está se conectando está realmente sendo executado por alguém que quer para recolher os seus detalhes de login do usuário - como aconteceu no Irã.Em 2011, o governo não é reconhecido por ter usado um certificado emitido por uma autoridade certificada subvertido a criação de um site, que (por meio de desvio de DNS) poderia fingir ser do Google gmail.com - e capturou os dados de dissidentes que pensavam que estavam entrando em o site .
Portanto, é importante que o dispositivo pode autenticar certificados SSL corretamente. Às vezes vai encontrar sites onde você receberá um aviso de certificado, mas que dizem que você deve confiar nele (por exemplo, porque isso é uma subsidiária com um nome diferente daquele que detém o certificado). Seja cauteloso. Não aprovar certificados sem ser cauteloso.
Qual foi o erro?
Devido a uma linha repetida singe de código em uma biblioteca da Apple, quase qualquer tentativa de verificar um certificado em um site teria sucesso - ou não a assinatura do certificado era válido. É só lançar um erro se o próprio certificado é inválido (devido a estar fora da data, por exemplo).
O bug é no código abaixo: é o segundo "Ir a falhar;", e que seria realizado em todas as circunstâncias.
estática OSStatus
SSLVerifySignedServerKeyExchange (SSLContext * ctx, bool isRsa, SSLBuffer signedParams,
uint8_t * assinatura, UInt16 signatureLen)
{
OSStatus err;
...
if (! (err = SSLHashSHA1.update (& hashCtx, e serverRandom)) = 0)
Ir à falhar;
se ((err = SSLHashSHA1.update (& hashCtx, e signedParams)) = 0!)
Goto falhar;
empreendedores falham;
if ((err = SSLHashSHA1.final (& hashCtx, e hashOut)) = 0!)
Goto falhar;
...
fail:
SSLFreeBuffer (& signedHashes);
SSLFreeBuffer (& hashCtx);
retorno err;
}
Quando o erro aparecer?
No iOS 6.0, que veio a público em Setembro de 2012. Ainda não está claro exatamente quando o erro apareceu no Mac OSX, mas é provável que seja, ao mesmo tempo, já que os sistemas operacionais móveis e desktop usar árvores de código comuns. O bug não estava lá na versão final do iOS 5, 5.1.1, lançado maio 2012 . O mesmo código foi aparentemente levado por diante através iOS em 7 e Mac OSX 10.9, é mesmo nas versões mais recentes do iOS 7.1 , que ainda está em beta.
(As linhas vermelhas são removidos no código atualizado; as linhas verdes são adicionados.)
Não é uma diferença óbvia, a menos que você está olhando para ele e, nesse caso, destaca-se como uma ferida polegar para qualquer programador.
Como é que o bug chegou lá?
Aqui temos duas teorias divergentes: acidente ou conspiração. Ou é um erro estúpido dentro da Apple, ou é um plano nefasto pela NSA (ou outros?) Para seduzir as comunicações dos alvos através da plantação de uma porta traseira em uma peça-chave do código.
Argumentando contra o plano de conspiração é o fato de que a Apple publica este código na sua página de código-fonte aberto . Com base em que "muitos olhos fazem erros superficial", e que toda a internet tem sido capaz de olhar para este épico "Ir a falhar" para idades. Se a NSA coloca seus backdoors secretos para fora no aberto como este, você esperaria que eles sejam encontrados muito mais rápido.
Argumentando por conspiração nefasta é - bem, não muito. Apple deve tê-lo encontrado, mas não o fez, de qualquer de seus compiladores (gcc e Clang) deveria ter jogado um erro, mas por outros testes mostraram que ele não a menos que você tem uma bandeira de advertência particular (por "código inacessível" ) definido. Um compilador que apontava para "código inacessível" (isto é, um segmento de código que nunca será ativado porque ele se encontra abaixo de um desvio código que se aplica sempre) teria pego ele.
Um ex-funcionário da Apple que trabalhava no Mac OSX disse ao Guardian que é "extremamente improvável, pelo menos em circunstâncias normais" que a falha foi adicionado maliciosamente. "Há muito poucas pessoas em qualquer equipe na Apple, e assim conseguir mudanças perdidos na confusão seria difícil. O outro lado é que não existem fortes cheques consistência / integridade internas sobre a base de código, por isso, se alguém fosse esperto o suficiente para subverter processos normais não haveria maneiras fáceis dentro "
Mas, o programador acrescentou, "essa mudança não especificamente destacam-se como de natureza maliciosa." A forma como ele quase certamente aconteceu é que foi um erro de copiar / colar, ou um problema de merge (entre dois ramos de código) que passou despercebido - "duas mudanças similares poderiam causar um conflito" (onde o código tem um fluxo ilógico) "e na resolução deste conflito um engenheiro pode ter cometido um erro."
O que os programadores dizem?
Um ex-funcionário da Apple que trabalhava no Mac OSX, incluindo atualizações de navegação e atualizações de segurança, disse ao Guardian que a Apple será capaz de identificar quem fez o código de check-in, que criou o bug. "Apesar de gerenciamento de código fonte está em uma base da equipe-a-time (não há política de toda a empresa), quase todas as equipe utiliza algum sistema ( Git ou SVN ), que seria capaz de rastrear commits [alterações no código que são "comprometidos" para uso] e atribuir a culpa. "
A explicação mais provável é que ela ocorreu através da fusão de dois ramos de código (onde duas ou mais pessoas estavam trabalhando no segmento de código). Código fusão é completamente comum na programação profissional; conciliar conflitos entre os ramos separados tende a ser feito à mão, usando editores que irá aparecer "diffs" (diferenças) entre o velho, novo e alternativo novo código.
Adam Langley, que trabalha na segurança para o navegador Chrome, do Google (mas não trabalhou para a Apple), diz :
Este tipo de erro sutil no fundo do código é um pesadelo.Eu acredito que isso é apenas um erro e eu me sinto muito ruim para quem pode ter escorregado em um editor e criou.
O fato de que a Apple está consertando o buraco agora sugere que não é de inspiração NSA. Embora, como John Gruber apontou , é perfeitamente possível que a NSA descobriu este buraco quando iOS 6 foi lançado e sabia que poderia explorá-la.
Um facto peculiar: se a NSA tinha conhecimento desta falha de segurança, ele não parece ter dito o Departamento de Defesa dos EUA, que passaram iOS 6 para uso no governo maio 2013.
Quando a Apple encontrou o erro?
No início de janeiro. Em 8 de janeiro contactou CVE, a vulnerabilidades comuns e banco de dados Erros (usado por todos os principais desenvolvedores de software) para reservar o número bug CVE 2014-1266 para a vulnerabilidade descoberta recentemente e embora CVE não sabia o que era a vulnerabilidade.
Apple parece depois de ter começado a trabalhar na correção e como estendê-lo. O que é estranho é que apesar de encontrar a vulnerabilidade, então, não corrigi-lo em duas versões beta do iOS 7.1 que foram lançados após esse período. Uma possibilidade - embora a empresa não vai confirmar isso - é que ele descobriu a falha para autenticar o certificado em janeiro, mas demorou até agora para diminuir a peça defeituosa do código - embora dada a rapidez com que tomou o resto da web para fazer a mesma (uma questão de algumas horas) esta parece improvável.
Por que a Apple não detectou o erro antes?
Seus testes de não encontrá-lo. A empresa não vai dizer o que os métodos que ele usa - se o teste de unidade (em que pedaços individuais de código são testados individualmente) ou testes de regressão . onde o novo código é testado contra testes conhecidosO ex-programador de lá diz que "a Apple não tem uma forte cultura de testes ou desenvolvimento orientado a testes. A Apple depende excessivamente em 'dogfooding' [usando seus próprios produtos] para processos de qualidade, que em situações de segurança não é apropriado.
"De um bom ponto de vista de engenharia de software, este tipo de questão deveria ter sido encontrado. É uma vergonha que eles não estão executando análise estática de código em tudo (e muito menos automaticamente) sobre tais bases de código importantes "O problema com a análise estática de código é que ele pode gerar falsos positivos -. avisos sobre falhas que não são - o que levou a várias equipes rejeitar a ideia, embora não esteja claro se a equipe de segurança foi uma delas.
Como é que a Apple encontrar o erro?
Parece ter sido a partir de uma revisão linha por linha de código, quase certamente despertou pelas revelações publicadas pelo Guardian of esforços prisma da NSA - e suas outras reivindicações para ter SSL rachado . Em um ponto houve especulações de que a revisão do código foi instigada por Kristin Paget, que até recentemente era responsável pela segurança da Apple OS X núcleo, tendo ingressado em setembro de 2012.
Mas Paget (que acaba de começar a trabalhar para Tesla) temdesencadeado um ataque contra a Apple em seu blog para a liberação da correção para iOS, mas também não remendar o ambiente de trabalho, ao mesmo tempo:
O QUE O ETERNO AMOR F ** K, APPLE?!?! Você seriamente acabou usar uma das suas plataformas para soltar um 0 dias SSL em sua outra plataforma? Quando eu sento aqui no meu mac estou vulneráveis a este e não há nada que eu possa fazer, porque você não poderia lançar um patch para ambas as plataformas ao mesmo tempo?Você sabe que há um monte de ao vivo, façanhas que trabalham para isso na natureza agora, certo?
Como ela aponta, sistema de atualização de segurança da própria Apple usa SSL - assim pode que ser cortado por um "homem no meio" ataque para plantar malware?
Como sobre o seu próprio sistema de atualização - que é vulnerável?Venha o inferno na, Apple. Você acabou de cair um 0 dia feio [vulnerabilidade zero-day] sobre nós e, em seguida, foi para casa no fim de semana - Ir à falha de fato.FIX. SEU. A MERDA.
Por que a Apple não corrigiu o bug para Mac OSX, ao mesmo tempo, como o fez para iOS?
Certamente deve ter, como Paget ressalta. Outro ex-funcionário da Apple concorda, aparentemente a Apple decidiu em vez de lançar a correção para Mavericks como parte de sua atualização de software 10.9.2 e não como uma atualização de segurança em separado (o que fez antes). Mas outros insetos foram encontrados em 10.9.2, atrasando o seu lançamento - e reduzindo a segurança dos usuários de Mac.
Existiram erros como foi antes?
Erros abundam em software - e os erros de criptografia são surpreendentemente fáceis de fazer. Em maio de 2011, um pesquisador de segurança apontou que as contas de usuários WhatsApp poderia ser seqüestrado, porque eles não foram criptografados em tudo, até setembro de 2011, houve uma falha no mesmo aplicativo que permitem que as pessoas enviem mensagens forjadas fingindo ser de ninguém.
Um erro comum é o uso de logins padrão que são deixados ativo: milhões de roteadores ao redor do mundo têm IDs de usuário e senhas padrão (geralmente "admin" e "admin"), que podem ser exploradas por hackers.
Um erro de codificação semelhante emparedada Zune da Microsoft no último dia de 2008 - que, como ele teria sorte, foi um ano bissexto.Houve um erro de codificação do software para o chip temporizador que não permitiria isso para exibir uma data equivalente ao 366 º dia do ano.
A Apple também tem feito alguns erros flagrantes semelhantes - principalmente em ter alarmes que não ajustar o horário de verão, quando o fez, e assim manteve acordar as pessoas ou uma hora mais cedo ou mais tarde.
Google também teve um erro na versão 4.2.0 de seu software Android : você não pode adicionar os aniversários de pessoas nascidas em dezembro para seus contatos, porque esse mês não foi incluído.
E a Microsoft tinha uma falha de longa duração no Windows 95 e Windows 98 o que significa que se o seu computador tinha sido executado de forma contínua por um pouco menos de 50 dias, seria de repente cair - e você tem que reiniciá-lo. Por quê? Porque é medido "uptime" usando um registrador de 32 bits, que incrementado cada milissegundo. Depois de 2 ^ 32 milissegundos (aka 49 dias e 17 horas), o registo era apenas 1s - ea única maneira de repor-se desligar a alimentação.
Que lições estão aí com isto?
Nos palavras de Arie Van Deursen , professor em engenharia de software da Universidade Tecnológica de Delft, na Holanda,
Ao ver pela primeira vez este código, eu estava mais uma vez pego de quão incrivelmente programação é frágil.Basta adicionar uma única linha de código pode trazer um sistema de joelhos.
Não só isso - mas o código de falha foi tanto usado e publicado por 18 meses, e testado por uma organização de segurança do governo, que passou a ser utilizado. Bugs de software pode ser pernicioso - e eles podem se esconder nas áreas mais essenciais. E mesmo as empresas que foram escrevendo software ao longo de décadas pode colidir com eles.
Mas o ex-funcionário da Apple diz que a menos que a empresa apresenta melhores regimes de ensaio - análise estática de código, testes unitários, testes de regressão - "Eu não estou surpreso com isso ... será apenas uma questão de tempo até que outra bomba como esta atinge. "A única - mínimo - conforto:" Eu duvido que ele é malicioso. "
Nova atualização corrige falhas de segurança no OS X
Sistema operacional da Maçã chega a versão 10.9.2 e ganha ainda suporte para FaceTime Audio
Na última semana, diversas falhas de segurança foram identificadas no OS X, mas aApple se moveu rapidamente para evitar que maiores problemas ocorressem com seus usuários. Nesta terça-feira (25), a companhia liberou uma nova atualização para o seu sistema operacional, que chega a versão 10.9.2.
A correção veio para uma linha de código presente no SO que permitia que determinados aplicativos no Mac, no iPhone e no iPadficassem expostos a ataques conhecidos como “man-in-the-middle”. Nesse tipo de ação, um hacker poderia se passar por site ou serviço confiável e interceptar as informações trocadas entre duas máquinas (usuário e banco, por exemplo).
A atualização já está disponível na seção de update de software do menu Apple dos Macs e pode ser realizada em máquinas com OS X Mavericks e Mountain Lion.
Mais novidades
No Mavericks, as novidades não para na questão da segurança e o sistema passa a ganhar suporte para o FaceTime Audio nos aplicativos de Mensagens e FaceTime. Além disso, correções de rede privada, áudio e do Safari, bem como aprimoramentos do aplicativo de email também estão presentes.
Sem comentários:
Enviar um comentário