Início
No dia 22 de agosto, o Projeto Fedora emitiu um “relatório de infra-estrutura” confirmando o que muitos observadores já suspeitavam: houve uma grave falha de segurança no projeto. O atacante conseguiu chegar ao sistema usado para assinar os pacotes distribuídos pelo Fedora. É claro que isso está bem perto de ser o pior dos cenários: se um intruso se apodera de um sistema desses, capturar a chave de assinatura dos pacotes e a passphrase usada para empregar a chave torna-se uma tarefa relativamente simples. E essas assinaturas, por sua vez, poderiam ser usadas para criar pacotes hostis que seriam aceitos como genuínos por instalações do Fedora de todo o mundo.
Felizmente para o projeto Fedora (e para seus usuários), uma auditoria determinou que ninguém usou a chave durante a permanência do intruso. Por isso, ainda que houvesse a possibilidade da passphrase ter sido capturada, ela não foi exposta e, conseqüentemente, não foi comprometida.
Nem é preciso dizer que mesmo assim o projeto está mudando sua chave de assinatura de pacotes.
O interessante é que o Fedora não foi o único alvo do ataque: o Red Hat também foi comprometido. Ao contrário do Projeto Fedora, a Red Hat não emitiu um comunicado específico sobre a invasão; ao invés disso, a informação foi incluída em uma atualização de segurança do openssh. Nesse caso o atacante teve mais sucesso, ao ponto de conseguir assinar “…um pequeno número de pacotes OpenSSH relativos apenas ao Red Hat Enterprise Linux 4 (apenas nas arquiteturas i386 e x86_64) e no Red Hat Enterprise Linux 5 (apenas na arquitetura x86_64).” Vale a pena questionar esse jogo de palavras: só é preciso assinar um único pacote openssh (o que certamente é um “pequeno número de pacotes”) para comprometer milhares de hosts com o RHEL, e os “apenas” que eles usam se referem ao que deve ser a maioria dos sistemas RHEL instalados. É para assustar mesmo, mas a Red Hat já se convenceu de que nenhum dos pacotes comprometidos foram entregues aos assinantes do RHEL. Logo, esse ataque também falhou — mas foi por pouco.
Nem é preciso dizer que explicações como essa trazem mais perguntas do que respostas. A pergunta que o Fedora e a Red Hat vão ter que responder mais cedo ou mais tarde é: como esse invasor entrou? Presume-se que o Fedora e a Red Hat rodem suas próprias distribuições, cada qual em seu sistema interno; deduz-se que, se essas distribuições contêm uma vulnerabilidade que permitiu a um atacante entrar no sistema, muitos outros grandes sistemas também podem estar vulneráveis. Se ao invés disso, o comprometimento do sistema for resultado de um erro de um administrador ou desenvolvedor (ou, quem sabe, de um laptop perdido), os administradores responsáveis por sistemas Fedora e RHEL podem dormir um pouco mais tranqüilos. De qualquer maneira, eles merecem saber como esses eventos se passaram.
Algumas pessoas gostariam de dispor dessa informação imediatamente. Além disso, imagina-se que haja uma boa quantidade de reclamações (também, imagina-se, de um grupo relativamente pequeno de pessoas) nas listas do Fedora quanto à maneira como o incidente foi tratado. Este editor também argumentou que as informações levaram muito tempo para vir à tona. Agora vou argumentar que, embora o Fedora ainda precise revelar algumas coisas, o projeto declarou o suficiente para conseguir respirar um pouco enquanto tenta recompor sua infra-estrutura e entender o que de fato aconteceu. Há vários bons motivos para que essas informações não tenham sido divulgadas imediatamente, incluindo a óbvia possibilidade de que ninguém saiba ainda como o invasor conseguiu acesso ao sistema. Não adianta malhar o Fedora nesse momento.
De qualquer maneira, qualquer coisa que o projeto possa dizer aos seus usuários sobre se há ou não motivos para que eles se preocupem com uma vulnerabilidade não revelada em seus sistemas seria bem-vinda, e quanto mais cedo isso acontecer, melhor.
Enquanto isso, o que pode ser feito, e o que o membro do conselho do Fedora, Jeff Spaleta, em particular, tem defendido, é que se pense em como lidar com a situação da próxima vez. Segundo Jeff,
Temos um problema de comunicação? Talvez. Mas problemas de comunicação não equivalem a problemas de confiança. Mas considerando que foi o primeiro evento dessa natureza a atingir o projeto, não acho de todo inesperado que tenham havido problemas de comunicação. Não acho que nenhum de nós, da Red Hat ou de fora dela, já tenha debatido sobre como lidar com esse tipo de situação. Não me lembro de ter havido algum debate público sério sobre como deva se dar a comunicação em uma situação dessas. E não vou aceitar que as pessoas pensem que fazer as coisas de um modo diferente deveria ser algo óbvio para aqueles em posição de lidar com as informações.
Se as pessoas querem que as coisas melhorem, se (Deus me livre) uma coisa dessas acontecer novamente, então é preciso trabalhar sério para que seja redigido um processo de comunicação aceito legalmente como um processo de trabalho viável, sem tocar perigosamente em questões de responsabilidade legal.
O Projeto Fedora certamente deve preparar uma política específica para situações como essa. Seria bom para os usuários do Fedora, mas seus efeitos poderiam ir além disso: uma política desse tipo poderia servir de exemplo para outros distribuidores. Afinal de contas, é provavelmente seguro dizer que o Fedora não é o único distribuidor que ainda não se encarregou de elaborar planos para esse tipo de desastre.
Todos nós precisamos de planos como esse. Seja isso bom ou ruim, os distribuidores hoje ocupam uma posição importante no que se refere à segurança de boa parte da internet. Milhões de sistemas rodam pacotes assinados por distribuidores Linux; eles dependem, implicitamente, da segurança do processo usado na criação dos pacotes. Esse processo não é pequeno; ele pode envolver centenas de desenvolvedores, sem contar todos os envolvidos nos projetos de desenvolvimento upstream. As conseqüências de uma falha em qualquer elo da corrente de confiança podem ser drásticas. Não é de se surpreender que o sistema da distribuição tenha sido atacado; talvez a única surpresa seja que isso não aconteça com mais freqüência (nós, pelo menos, nunca soubemos de nada a esse respeito). Ataques como esse vão acontecer novamente, e os desenvolvedores precisam ter uma idéia bem definida de como reagir.
Vale mencionar um assunto relacionado: no momento em que escrevo este artigo (25 de agosto), já se vão quase duas semanas sem atualizações de segurança no Fedora. Os usuários do Fedora ainda não receberam patches para várias vulnerabilidades significativas, como a vulnerabilidade do link simbólico do postfix. A Red Had agiu melhor, mas não muito. Os usuários do Linux dependem fortemente do processo de atualizações de segurança e, no caso dessas duas distribuições, o processo foi seriamente abalado. Se alguma vulnerabilidade realmente séria tivesse sido revelada nesse período, as pessoas encarregadas de manter seguros sistemas Fedora e Red Hat poderiam estar numa situação difícil. Não é preciso ser muito paranóico para para imaginar esse tipo de abalo sendo sendo usado intencionalmente como parte de um “zero-day attack”, em que um espertinho se aproveita de alguma vulnerabilidade que tenha sido anunciada antes que o fornecedor tenha tido tempo de emitir um patch.
Esse incidente serve como uma espécie de alarme tanto para os distribuidores quanto para os usuários. Os distribuidores que desejem manter a confiança de seus usuários devem pensar em documentar coisas como:
* Como manter seguros os elos da corrente do empacotamento. Seria bom saber quantas pessoas podem assinar pacotes, e como elas obtêm acesso aos sistemas nos quais os pacotes são assinados.
* Que tipo de planos o distribuidor tem para lidar com os problemas de segurança. É de se imaginar que a Red Hat tenha um bom número de funcionários trabalhando para entender o incidente e se recuperar dele. Será que outros distribuidores estariam dispostos e seriam capazes de fazer o mesmo?
* Quais são os planos para lidar com falhas de segurança graves? Como distribuir atualizações de segurança quando a integridade do sistema de pacotes estiver comprometida?
* Se algo der errado, quando e como as informações serão comunicadas à comunidade de um modo geral?
Qualquer um que esteja implantando um sistema importante baseado em Linux deve se fazer essas perguntas ao escolher uma distribuição para o sistema. Se o sistema exige alta confiabilidade, provavelmente faz sentido buscar um fornecedor que ofereça garantias mediante uma taxa. Mas a lição que aprendemos com os eventos recentes é a de que agora é a hora de fazermos essas perguntas, e não quando algo der errado e todo mundo estiver correndo em círculos.
De modo geral, os usuários do Linux têm sido muito bem servidos pelos distribuidores desde o início. Os distribuidores reúnem milhares de programas e os integram em um todo coerente; depois eles disponibilizam os resultado, muitas vezes de graça. Eles fornecem correções quando algo dá errado, e a maioria deles dá uma atenção especial aos problemas de segurança. Eles têm feito um trabalho de excelente qualidade, não sendo usados como veículos de programas hostis. É um ótimo sistema, e ele não mudou. Mas aprendemos alguma coisa sobre o quanto nós dependemos desse sistema, e sobre como ele pode falhar. Aplicar as lições aprendidas com esse episódio deve nos ajudar a ter mais segurança no futuro.
Felizmente para o projeto Fedora (e para seus usuários), uma auditoria determinou que ninguém usou a chave durante a permanência do intruso. Por isso, ainda que houvesse a possibilidade da passphrase ter sido capturada, ela não foi exposta e, conseqüentemente, não foi comprometida.
Nem é preciso dizer que mesmo assim o projeto está mudando sua chave de assinatura de pacotes.
O interessante é que o Fedora não foi o único alvo do ataque: o Red Hat também foi comprometido. Ao contrário do Projeto Fedora, a Red Hat não emitiu um comunicado específico sobre a invasão; ao invés disso, a informação foi incluída em uma atualização de segurança do openssh. Nesse caso o atacante teve mais sucesso, ao ponto de conseguir assinar “…um pequeno número de pacotes OpenSSH relativos apenas ao Red Hat Enterprise Linux 4 (apenas nas arquiteturas i386 e x86_64) e no Red Hat Enterprise Linux 5 (apenas na arquitetura x86_64).” Vale a pena questionar esse jogo de palavras: só é preciso assinar um único pacote openssh (o que certamente é um “pequeno número de pacotes”) para comprometer milhares de hosts com o RHEL, e os “apenas” que eles usam se referem ao que deve ser a maioria dos sistemas RHEL instalados. É para assustar mesmo, mas a Red Hat já se convenceu de que nenhum dos pacotes comprometidos foram entregues aos assinantes do RHEL. Logo, esse ataque também falhou — mas foi por pouco.
Nem é preciso dizer que explicações como essa trazem mais perguntas do que respostas. A pergunta que o Fedora e a Red Hat vão ter que responder mais cedo ou mais tarde é: como esse invasor entrou? Presume-se que o Fedora e a Red Hat rodem suas próprias distribuições, cada qual em seu sistema interno; deduz-se que, se essas distribuições contêm uma vulnerabilidade que permitiu a um atacante entrar no sistema, muitos outros grandes sistemas também podem estar vulneráveis. Se ao invés disso, o comprometimento do sistema for resultado de um erro de um administrador ou desenvolvedor (ou, quem sabe, de um laptop perdido), os administradores responsáveis por sistemas Fedora e RHEL podem dormir um pouco mais tranqüilos. De qualquer maneira, eles merecem saber como esses eventos se passaram.
Algumas pessoas gostariam de dispor dessa informação imediatamente. Além disso, imagina-se que haja uma boa quantidade de reclamações (também, imagina-se, de um grupo relativamente pequeno de pessoas) nas listas do Fedora quanto à maneira como o incidente foi tratado. Este editor também argumentou que as informações levaram muito tempo para vir à tona. Agora vou argumentar que, embora o Fedora ainda precise revelar algumas coisas, o projeto declarou o suficiente para conseguir respirar um pouco enquanto tenta recompor sua infra-estrutura e entender o que de fato aconteceu. Há vários bons motivos para que essas informações não tenham sido divulgadas imediatamente, incluindo a óbvia possibilidade de que ninguém saiba ainda como o invasor conseguiu acesso ao sistema. Não adianta malhar o Fedora nesse momento.
De qualquer maneira, qualquer coisa que o projeto possa dizer aos seus usuários sobre se há ou não motivos para que eles se preocupem com uma vulnerabilidade não revelada em seus sistemas seria bem-vinda, e quanto mais cedo isso acontecer, melhor.
Enquanto isso, o que pode ser feito, e o que o membro do conselho do Fedora, Jeff Spaleta, em particular, tem defendido, é que se pense em como lidar com a situação da próxima vez. Segundo Jeff,
Temos um problema de comunicação? Talvez. Mas problemas de comunicação não equivalem a problemas de confiança. Mas considerando que foi o primeiro evento dessa natureza a atingir o projeto, não acho de todo inesperado que tenham havido problemas de comunicação. Não acho que nenhum de nós, da Red Hat ou de fora dela, já tenha debatido sobre como lidar com esse tipo de situação. Não me lembro de ter havido algum debate público sério sobre como deva se dar a comunicação em uma situação dessas. E não vou aceitar que as pessoas pensem que fazer as coisas de um modo diferente deveria ser algo óbvio para aqueles em posição de lidar com as informações.
Se as pessoas querem que as coisas melhorem, se (Deus me livre) uma coisa dessas acontecer novamente, então é preciso trabalhar sério para que seja redigido um processo de comunicação aceito legalmente como um processo de trabalho viável, sem tocar perigosamente em questões de responsabilidade legal.
O Projeto Fedora certamente deve preparar uma política específica para situações como essa. Seria bom para os usuários do Fedora, mas seus efeitos poderiam ir além disso: uma política desse tipo poderia servir de exemplo para outros distribuidores. Afinal de contas, é provavelmente seguro dizer que o Fedora não é o único distribuidor que ainda não se encarregou de elaborar planos para esse tipo de desastre.
Todos nós precisamos de planos como esse. Seja isso bom ou ruim, os distribuidores hoje ocupam uma posição importante no que se refere à segurança de boa parte da internet. Milhões de sistemas rodam pacotes assinados por distribuidores Linux; eles dependem, implicitamente, da segurança do processo usado na criação dos pacotes. Esse processo não é pequeno; ele pode envolver centenas de desenvolvedores, sem contar todos os envolvidos nos projetos de desenvolvimento upstream. As conseqüências de uma falha em qualquer elo da corrente de confiança podem ser drásticas. Não é de se surpreender que o sistema da distribuição tenha sido atacado; talvez a única surpresa seja que isso não aconteça com mais freqüência (nós, pelo menos, nunca soubemos de nada a esse respeito). Ataques como esse vão acontecer novamente, e os desenvolvedores precisam ter uma idéia bem definida de como reagir.
Vale mencionar um assunto relacionado: no momento em que escrevo este artigo (25 de agosto), já se vão quase duas semanas sem atualizações de segurança no Fedora. Os usuários do Fedora ainda não receberam patches para várias vulnerabilidades significativas, como a vulnerabilidade do link simbólico do postfix. A Red Had agiu melhor, mas não muito. Os usuários do Linux dependem fortemente do processo de atualizações de segurança e, no caso dessas duas distribuições, o processo foi seriamente abalado. Se alguma vulnerabilidade realmente séria tivesse sido revelada nesse período, as pessoas encarregadas de manter seguros sistemas Fedora e Red Hat poderiam estar numa situação difícil. Não é preciso ser muito paranóico para para imaginar esse tipo de abalo sendo sendo usado intencionalmente como parte de um “zero-day attack”, em que um espertinho se aproveita de alguma vulnerabilidade que tenha sido anunciada antes que o fornecedor tenha tido tempo de emitir um patch.
Esse incidente serve como uma espécie de alarme tanto para os distribuidores quanto para os usuários. Os distribuidores que desejem manter a confiança de seus usuários devem pensar em documentar coisas como:
* Como manter seguros os elos da corrente do empacotamento. Seria bom saber quantas pessoas podem assinar pacotes, e como elas obtêm acesso aos sistemas nos quais os pacotes são assinados.
* Que tipo de planos o distribuidor tem para lidar com os problemas de segurança. É de se imaginar que a Red Hat tenha um bom número de funcionários trabalhando para entender o incidente e se recuperar dele. Será que outros distribuidores estariam dispostos e seriam capazes de fazer o mesmo?
* Quais são os planos para lidar com falhas de segurança graves? Como distribuir atualizações de segurança quando a integridade do sistema de pacotes estiver comprometida?
* Se algo der errado, quando e como as informações serão comunicadas à comunidade de um modo geral?
Qualquer um que esteja implantando um sistema importante baseado em Linux deve se fazer essas perguntas ao escolher uma distribuição para o sistema. Se o sistema exige alta confiabilidade, provavelmente faz sentido buscar um fornecedor que ofereça garantias mediante uma taxa. Mas a lição que aprendemos com os eventos recentes é a de que agora é a hora de fazermos essas perguntas, e não quando algo der errado e todo mundo estiver correndo em círculos.
De modo geral, os usuários do Linux têm sido muito bem servidos pelos distribuidores desde o início. Os distribuidores reúnem milhares de programas e os integram em um todo coerente; depois eles disponibilizam os resultado, muitas vezes de graça. Eles fornecem correções quando algo dá errado, e a maioria deles dá uma atenção especial aos problemas de segurança. Eles têm feito um trabalho de excelente qualidade, não sendo usados como veículos de programas hostis. É um ótimo sistema, e ele não mudou. Mas aprendemos alguma coisa sobre o quanto nós dependemos desse sistema, e sobre como ele pode falhar. Aplicar as lições aprendidas com esse episódio deve nos ajudar a ter mais segurança no futuro.