O melhor pedaço da Maçã.

Opinião de especialista: sistema operacional da Apple foi a plataforma mais vulnerável de 2014, #sqn

Hacker num computador

por Patrick Tracanelli [@eksffa]

Publicidade

Nesta semana, o Gizmodo e o Gizmodo Brasil irresponsavelmente reproduziram a notícia sobre o levantamento realizado pela empresa de soluções de segurança GFI. Irresponsável pois a GFI em si tem um alcance limitado de usuários e os que ela alcança, em linhas gerais, têm um senso crítico mais afiado e conseguem discernir fatos contundentes de desinformação, ou simples informação demasiadamente simplificada. Já o Gizmodo alcança um público mais amplo e genérico, que em linhas gerais tem menos embasamento para uma análise crítica sobre temas nada simples. Desta forma, o público que confia no Gizmodo merece uma análise e um comentário revisando os fatos em vez da simples reprodução do conteúdo.

Infelizmente, isso não aconteceu por lá. Mas no MacMagazine um artigo com alguns esclarecimentos despontou e, no melhor interesse da discussão ampla dos fatos, resolvi complementar alguns pontos.

Hacker num computador

Hacker num computador, via Shutterstock.

Publicidade

Na IDS Tecnologia, nós amamos Apple. Mas antes de ser uma empresa dedicada aos produtos e serviços Apple, a IDS nasceu como uma empresa de Segurança da Informação, e chegar à Apple como plataforma para usuário final foi uma evolução natural do foco original, que sempre foi a segurança. Em especial a partir do fim do Mac OS 9 e do nascimento do Mac OS X, a oportunidade de ter um Unix com todas as vantagens, os recursos e o poder de um Unix na mesa ou na mão de um executivo, um produtor de conteúdo, um administrador ou um advogado, ou de qualquer outro usuário final, sem o peso de ter que aprender a usar Unix, ou seja, com a facilidade e intuitividade que assinam cada produto Apple.

Quando falamos de Segurança da Informação, existe um entendimento comum chamado de “ampla divulgação” (“full disclosure”) de falhas e vulnerabilidades que devem ser adotadas responsavelmente pelos fabricantes e fornecedores, bem como pesquisadores e grupos que descobrem as vulnerabilidades. Existe esse entendimento apesar de informal, comum, indicado, sustentado e defendido, que na prática envolve responsabilidades de todos os lados.

Publicidade

Existe um fluxo mínimo esperado, que é normalmente é:


Descoberta » Comprovação » Notificação ao fornecedor » Prazo de correção » Correção » Ampla divulgação


A etapa de ampla divulgação ocorre no sentido de alertar e fazer o usuário perceber que ele precisa atualizar, que a falha está lá — ela tem sua criticidade informada e é importante o usuário fazer a parte dele agora, que é providenciar atualização/correção — ou mitigação, se não existir correção —, ou seja, é um “esteja ciente do risco”.

Publicidade

Existem ciclos reduzidos nos quais as falhas são descobertas pela própria equipe que desenvolve o produto. Ou seja, típicos que podem ser apenas “Correção » Ampla divulgação”.

Cada ampla divulgação é na prática acompanhada de um Security Advisory (um anúncio, num formato similar entre os fabricantes) que dão detalhes da(s) falha(s), correções e mitigações. São esses SAs que passam a compor as bases de vulnerabilidades, como o CVE do MITRE ou o NVD do governo americano.

A pergunta então que devemos nos fazer é: “Ter um número maior de SAs é, de fato, indício de que o sistema é mais vulnerável ou indício de que o fabricante é responsável e dá a devida satisfação e informa seus usuários?” É uma questão de responsabilidade, e medir a segurança de um sistema pelo número de SAs é um desfavor ao entendimento comum dessa responsabilidade e respeito ao usuário. E pior, esse desfavor pode refletir numa postura errada do fabricante se ele achar que, para o marketing, “quanto menos Security Advisories, melhor”.

A vulnerabilidade passa a ser conhecida a partir da ampla divulgação. Sabe o famoso “0-day” que você pode ter ouvido falar por aí? É uma vulnerabilidade explorada a qualquer tempo antes do dia-1, ou seja, antes da ampla divulgação — isto é, a exploração de uma falha não amplamente divulgada. E aí é que está a importância do SA e do full disclosure. Se os fabricantes adotam (e diversos adotam) a política de “quanto menos SAs, melhor pro marketing” não significa que o sistema é mais seguro, que tem menos falhas. Significa apenas que existem mais falhas sendo exploradas sem conhecimento amplo. Mais “0-days”.

Então vamos analisar novamente os fatos.

Sendo imparcial mas justo com a Apple e seus usuários, vejamos os SAs da Apple, mês a mês, em 2014: a Apple “põe na sua própria conta” falhas que não são dela, mas que de alguma forma afetam o OS X. Por exemplo: você tem várias falhas de Java, Flash Player, Apache, PHP, MySQL e até OpenSSL na conta dela sendo que essas falhas não são da Apple ou de softwares que a Apple mantém, desenvolve ou tem responsabilidade direta.

Mas sim, a Apple tem responsabilidade indireta perante seus usuários que podem ser afetados por essas falhas, então, de forma responsável — já que a falha afeta o OS X ou o iOS —, ela as divulga, simplesmente porque é o certo, o responsável a ser feito.

A Apple poderia ter outra postura. Poderia atualizar seu Apache, PHP, OpenSSL, Java, Flash, etc. de maneira furtiva (na surdina) sem emitir SAs. Afinal, se a falha não é dela, por que o SA tem que ser? Que a Oracle lance seus SAs pro Java, a Adobe pro Flash, a Apache Foundation pro Apache, e por aí vai. Mas o que a Apple faz é o mais correto: criar o SA e informar seus usuários, dando satisfação e ampla divulgação que o problema existe, pode afetar o usuário, que a correção está disponível e incentivar atualização o quanto antes.

Vejamos alguns desses, divulgados por exemplo no início de 2014, identificados pelo APPLE-SA-2014-02-25-1:

Apache
Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5,
OS X Mountain Lion v10.8.5, OS X Mavericks 10.9 and 10.9.1
Impact: Multiple vulnerabilities in Apache
Description: Multiple vulnerabilities existed in Apache, the most
serious of which may lead to cross-site scripting. These issues were
addressed by updating Apache to version 2.2.26.
CVE-ID
CVE-2013-1862
CVE-2013-1896

curl
Available for: OS X Mavericks 10.9 and 10.9.1
Impact: An attacker with a privileged network position may intercept
user credentials or other sensitive information
Description: When using curl to connect to an HTTPS URL containing
an IP address, the IP address was not validated against the
certificate. This issue does not affect systems prior to OS X
Mavericks v10.9.
CVE-ID
CVE-2014-1263 : Roland Moriz of Moriz GmbH

LaunchServices
Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5,
OS X Mountain Lion v10.8.5
Impact: A file could show the wrong extension
Description: An issue existed in the handling of certain unicode
characters that could allow filenames to show incorrect extensions.
The issue was addressed by filtering unsafe unicode characters from
display in filenames. This issue does not affect systems running OS X
Mavericks v10.9 or later.
CVE-ID
CVE-2013-5178 : Jesse Ruderman of Mozilla Corporation, Stephane Sudre
of Intego

NVIDIA Drivers
Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5,
OS X Mountain Lion v10.8.5, OS X Mavericks 10.9 and 10.9.1
Impact: Executing a malicious application could result in arbitrary
code execution within the graphics card
Description: An issue existed that allowed writes to some trusted
memory on the graphics card. This issue was addressed by removing the
ability of the host to write to that memory.
CVE-ID
CVE-2013-5986 : Marcin Kościelnicki from the X.Org Foundation
Nouveau project
CVE-2013-5987 : Marcin Kościelnicki from the X.Org Foundation
Nouveau project

PHP
Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5,
OS X Mountain Lion v10.8.5, OS X Mavericks 10.9 and 10.9.1
Impact: Multiple vulnerabilities in PHP
Description: Multiple vulnerabilities existed in PHP, the most
serious of which may have led to arbitrary code execution. These
issues were addressed by updating PHP to version 5.4.22 on OS X
Mavericks v10.9, and 5.3.28 on OS X Lion and Mountain Lion.
CVE-ID
CVE-2013-4073
CVE-2013-4113
CVE-2013-4248
CVE-2013-6420

QuickLook
Available for: OS X Mountain Lion v10.8.5
Impact: Downloading a maliciously crafted Microsoft Office file may
lead to an unexpected application termination or arbitrary code
execution
Description: A memory corruption issue existed in QuickLook’s
handling of Microsoft Office files. Downloading a maliciously crafted
Microsoft Office file may have led to an unexpected application
termination or arbitrary code execution. This issue does not affect
systems running OS X Mavericks 10.9 or later.
CVE-ID
CVE-2014-1260 : Felix Groebert of the Google Security Team

Peguei apenas alguns — a intenção não é reproduzir todos os SAs de 2014, mas veja em destaque o que é importante notar. Você vê em que software é a falha, em que versões do sistema ela afeta, como foi corrigido e quem descobriu originalmente a falha quando não foi a própria equipe Apple.

Claro, Quick Look, Launch Services e tantos outros são softwares Apple, responsabilidade da Apple e são sim falhas dos sistemas OS X ou iOS quando identificados como tal. Mas note que o volume de falhas que não são da Apple é expressivo ao longo dos anos.

O artigo original criado pela empresa GFI, excessivamente simplista, é no mínimo confuso e o update oficial que eles deram ficou ainda mais confuso — sobre o agrupamento de sistemas operacionais Apple e Linux e fragmentação por versão nos Windows, enfim, nada positivo para transparência e compreensão dos dados. Então convido os leitores a fazerem uma pesquisa por conta própria, na mesma origem alegadamente utilizada, a National Vulnerability Database dos Estados Unidos.

É bem simples: escolham na caixa Vendor o fabricante Apple, depois na caixa de seleção o Product Mac OS X. Depois selecionem de janeiro de 2014 a dezembro de 2014 e observem o resultado. Primeiro que há uma divergência entre o que você pesquisa e o que o artigo original da GFI aponta. Não importa como você pesquisa, se de forma avançada ou por string, os dados são divergentes. Não se tem uma metodologia clara e a explicação da GFI não explica nada. Mas pesquise e olhe as falhas. Avalie que falhas são de produtos Apple de fato, ou de terceiros que afetam os produtos Apple.

Busca de falhas sobre o OS X na National Vulnerability Database

O Windows Server (e Workstation também, é claro) foi afetado pelas falhas de SSL, Java, Flash, Reader e tantas outras. No entanto, a Microsoft não gerou SAs. Isso torna o Windows mais seguro?

Aliás, os advisories de falhas de Active X por exemplo, vão para a conta de falhas da suíte Office e não do Windows, mesmo o Windows tendo instalado isso por padrão. As milhares de falhas do Internet Explorer, as oficiais e não-oficiais, vão para a conta do IE e não do Windows — mesmo o Windows vindo com o IE por padrão.

A maior diferença é a de postura. A Apple é mais responsável e mais transparente, informa mais. Acaba sofrendo o efeito negativo de “parecer” que tem mais falhas, o que é ruim não só para a Apple mas para todos. Porque isso desmotiva a empresa ser transparente… ela paga um pato que não é dela, sob os olhos menos atentos.

Esta semana, por exemplo, saíram quatro SAs do FreeBSD, um de igmp e um de vt que são do FreeBSD. Outro é bind, outro é openssl. Se o projeto FreeBSD tivesse uma postura não-responsável, como faz a Microsoft, as falhas do BIND e do OpenSSL poderiam não ter gerado SAs (ainda que corrigidas) e ficar apenas na conta dos contrib ou apenas pro VulXML que documenta as vulnerabilidades de aplicações de terceiros as quais podem afetar o FreeBSD. Se o FreeBSD não gerasse advisory do que é contrib, o número de alertas seria menos da metade por ano.

Mas isso seria bom? Certamente não… ainda que a causa-origem do problema não seja de responsabilidade do fabricante, se afeta o produto, a ampla divulgação é o caminho correto.

Microsoft e Cisco, dentre tantos outros grandes fabricantes de tecnologia, não são exemplos bons no que tange à postura correta de segurança. São publicamente criticados em eventos específicos de segurança e alguns times de pesquisadores, como do Google, que têm sido mais agressivos e tomado postura de dar prazo bem determinado pra correção antes de eles mesmos fazerem a ampla divulgação. E esses disclosures que não geram SAs por parte do fabricante acabam não indo “pra conta” dela — reforçando a distorção.

Existem mais de 130 falhas de segurança de Windows comprovadas no Secunia, que a Microsoft não reconhece (mesmo tendo a prova da falha lá) e não gera advisory. A Cisco tem mais da metade disso na mesma situação, para várias versões dos sistemas dela.

Isso afeta inclusive empresas e trabalhos de segurança. Por exemplo, aqui na IDS, em um trabalho amplo realizado em uma empresa do setor bancário, foram elencadas três falhas graves no Windows Active Directory Server do cliente, em três serviços diferentes. O Windows é gerenciado nesse banco por terceiros, uma empresa de telecom, que simplesmente não reconhece que existem essas falhas, já que não existe SAs tão pouco hot fixes por parte da Microsoft. Percebem como fica difícil pra todos agirem quando não existe uma postura responsável por parte do fabricante? A consultoria em segurança aponta a falha, a prova de conceito, a mitigação. O cliente, interessado, solicita a correção. A correção não é feita porque não existe e a falha não é reconhecida porque o fabricante não reconhece. O que fazer nessa situação? Nossa recomendação foi a própria equipe do cliente (ou nós mesmos, se o cliente assim o desejar) mitigar o risco — na esperança que, um dia, exista a correção definitiva.

Vamos mais longe que isso.

Sistemas BSD são conhecidos por figurarem sempre entre os mais seguros do mundo. No mundo Apple, OS X e iOS apesar de serem sistemas híbridos Mach/BSD são, de alguma forma, BSD. Vamos no entanto focar nos BSD “sangue puro”.

O FreeBSD, em 2014, teve 31 SAs publicados. Se colocar na tabela dos sistemas “mais inseguros” do artigo em questão, o FreeBSD apareceria na posição número 9 — mais vulnerável que o Windows RT e quase tão vulnerável quanto o Vista!

Pra desconstruir ainda mais a ideia promovida pela análise a agrupamento sem critério no artigo da GFI, vamos pegar agora o OpenBSD de exemplo — tido, vale notar, como o sistema operacional mais seguro do mundo. Olhando os SAs das versões afetadas em 2014, temos: 1, 2 e 3.

Se resolvermos chamar tudo de “OpenBSD”, como a empresa de segurança em questão chamou tudo de “Apple Mac OS X” ou “Linux Kernel” ou “Apple iOS”, o que temos? Um total de 45 SAs, o que colocaria o OpenBSD num incrível 4º lugar como sistema mais vulnerável de 2014, à frente de todos os Windows listados pela matéria original!

E agora, senhores? Como ficamos? É correto e confiável elencar a segurança de um sistema usando como métrica a quantidade de notas de segurança emitidas?

Não dando ênfase à distorção de informações entre o que realmente encontramos no NVD, o que o artigo apresenta. Ou o que é conhecido pela comunidade de segurança e o que é divulgado pelo fabricante. Nem estou me dando ao trabalho de focar em como o agrupamento das falhas para a Apple e o Linux foi feita e por que o Windows foi fragmentado em versões. Estou tentando simplificar ao máximo por que o artigo original, por si só, é no mínimo confuso ao dispor os dados e concluir alguma coisa.

No fim, ou a GFI que é uma empresa de produtos de segurança que tem algum produto a ser promovido para OS X e iOS, ou esse artigo publicado por eles é apenas uma triste constatação da imprecisão com que tratam o tema.

Se alguém ainda acredita que a segurança de um sistema se mede pelo número de advisories, segue a minha recomendação: FreeDOS.


Patrick Tracanelli é formado em Unix Systems pela Universidade da Califórnia, Berkeley. Especialista MBA em Segurança da Informação pela Universidade FUMEC. Diretor da IDS Tecnologia, é program manager e pessoa responsável pelos programas Apple Authorized Training Center (AATC), Apple Value Added Reseller (VAR), Consultants Network (ACN) e Developer. Supervisor de Desenvolvimento Mobile (iOS) e Treinamento Apple. É certificado Apple, BSDA, CISSP, CITRIX, ISO27002 Auditor Leader e outras besteiras de mercado.

Ver comentários do post

Compartilhe este artigo
URL compartilhável
Post Ant.

Updates recentes na App Store: Logic Pro X e Remote, MainStage 3, Apple Store e mais!

Próx. Post

Confira estes tópicos do nosso Fórum: carcaça de MacBook Air energizada, internet nos EUA, Apple Watch vs. Pebble Time e mais!

Posts Relacionados