[FUG-BR] [OFF-TOPIC]Foi realmente colocado backdoor no ipsec do OpenBSD?

[Paulo Henrique - BSDs Brasil]

Em 24/11/2012 23:51, Otacílio escreveu:
> On 24/11/2012 22:25, Antônio Pessoa wrote:
>> 2012/11/23 Paulo Henrique - BSDs Brasil <paulo.rddck em bsd.com.br>:
>>> Antônio,
>>> Concordo contigo em partes, infelizmente por não estar na empresa
>>> durante a tarde fará com que o e-mail saia da ordem da thread, e torne a
>>> compreensão um pouco ruim.
>>>
>>> Defesa de opinião pessoal.
>>>
>>> Considero que qualquer processo de auditoria não é  100% plena devido a
>>> circunstâncias da ocasião.
>>> Considere que voce ler o codigo e analisar cada parte dele e o mesmo
>>> sobre todo o contexto não é possivel garantir  que o codigo é 100%
>>> seguro e executará somente a rotina no qual o mesmo foi projetado.
>>> O código por mais que venha a ser analisado, uma condição externa é que
>>> poderá interferir na sua operação fazendo com que o buraco seja exposto.
>>>
>>>
>>> Imagine a seguinte situação:
>>>
>>> A NSA/FBI paga para a intel/AMD/Oracle colocar uma instrução de
>>> proposito exclusivo no processador, tal instrução altera a forma de
>>> calculo sobre um algoritmo especifico no userland/kerneland permitindo
>>> que o buraco seja ativado, o código do IPSec poder ter sido construído
>>> visando com um dos objetivos ativar tal recurso no processador, tal
>>> instrução pode ser ativada através de uma circunstância qualquer de
>>> operação do processador que poderá gerar tal brecha, contudo é uma
>>> brecha controlável, e que os criadores considerarão que a mesma estaria
>>> sendo buscada durante processos de auditoria e colocaram condições para
>>> que a mesma não mostre a cara o tempo todo, como o bóson de hings, todos
>>> falam que existe e que ja está até quase provado que o LHC de fato
>>> localizou ele, mesmo depois de 1 seculo de sua previsão ele ainda não
>>> foi plenamente provado, conseguiu acompanhar o raciocínio.
>>> Para a auditoria ser 100% será necessário acompanhar cada instrução em
>>> tempo de execução sobre todas as condições existentes, conclusão a
>>> auditoria é 99.9% plena, um humano não consegue  analisar plenamente e
>>> sem cometer erros 50 Mbs ou 100Mbs de arquivo txt para cada condições
>>> possível, e o computar é burro para poder fazer essa tarefa.
>>>
>>> Resumo ou se reescreve toda a pilha/algoritmos para garantir que o
>>> código não se baseou no objetivo de gerar uma circunstancia que poderá
>>> vir a ativar tal falha ou nunca mais será considerado 100% seguro, visto
>>> que não achar não é o mesmo que não existir, e uma vez comendado a
>>> possibilidade de ser verdade passa a ser automaticamente 50% com
>>> possibilidades de apenas obter 100% de verdade, visto que para ser
>>> mentira a mesma nem deveria ter sido levantada.
>>> Não é possível com exceção dos engenheiros das fabricantes de
>>> processadores termos acesso ao projeto do processador para poder ter
>>> plena certeza que não há possibilidade de se ter uma condição que venha
>>> criar a brecha, e o processador é um do fatores externos, pode haver
>>> outros que tornaria a coisa realmente conspiratória.
>>>
>>> No final compreender o que é ou não seguro depende muito do grau de
>>> compreensão da área, para usuários técnicos como nós, conseguimos
>>> diferenciar IPsec de Internet, mais para um usuário leigo, vugo Patrão,
>>> ele não compreende bulufas e vai simplesmente acreditar que software
>>> livre está vendido para NSA/FBI ou qualquer outra agencia e que qualquer
>>> outro sistema operacional não baseado no open-source é mais seguro,
>>> afinal alguém falou que o Solaris ou IBM/AIX ou SGI Irix poderia ter
>>> sofrido com tal especulação? Infelizmente não focou o OpenBSD e o IPSec
>>> amplamente apontando que diversos outros sistemas tem Pilhas IPSec
>>> derivadas dela.
>>>
>>> Marketing negro tambem é levado em consideração:
>>>
>>> Mais um pouquinho e acho que serei o próximo autor do filme "Teoria da
>>> conspiração".
>>>
>>> Abraços, e estou somente defendendo minha opinião pessoal.
>>>
>>
>> Ambos estamos, mas como pessoas civilizadas, claro, respeitando cada
>> um dos lados, e isso é o que deixa a discussão interessante. :-)
>>
>>
>>> --
>>> Paulo Henrique.
>>> BSDs Brasil - FUG-BR
>>> site: www.fug.com.br
>>>
>>> Rip Irado !!!
>>> flamers > /dev/null
>>>
>>
>> Concordo que o fator externo citado, apesar de ser uma possibilidade
>> mais longínqua, mesmo que possível, torne uma auditoria mais difícil,
>> mas não acredito que um trecho de código sem sentido, ou fora de
>> contexto, passe despercebido de tantas pessoas, ainda mais se
>> considerarmos desenvolvedores da qualidade do Theo, entre outros.
>> Tomando o exemplo, hipotético, de uma macro que, apesar de não ser
>> suspeita, não está no lugar certo, ou está fora de contexto, ou
>> simplesmente é inútil, redundante. Isso, por si só, seria motivo para
>> ser melhor analisada. Não encaixa no seu exemplo, é apenas para
>> ilustrar. Tanto que na época da auditoria foram achados dois bugs no
>> IPSec, bugs que só uma auditoria mais rigorosa que a usual teriam
>> revelado.
>>
>> Enfim, acredito que, apesar de difícil (toda auditoria é, ou deveria
>> ser), com um trabalho bem feito e criterioso não é impossível. Mas
>> como você disse, é apenas minha opinião também.
>>
>> P.S.: Não falo tudo isso apenas por ser OpenBSD, também confio na
>> transparência e qualidade da equipe do FreeBSD.
>>
>> --
>> Atenciosamente,
>>
>> Antônio Pessoa
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
>
> Eu penso o seguinte, como por alguma instrução ou sequência que mude o
> comportamento do processador e ainda manter isso oculto? Uma macro daria
> na cara, e o código do IPSEC não é escrito em C? Então o código gerado
> seria dependente do compilador e tal. E ainda tem que manter toda a
> equipe de desenvolvimento do processador calada. Eu acho isso
> simplesmente muito difícil.
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Otacilio,

Realmente pode ser dificil, contudo ressalvo que essas empresas tem 
politicas contra vazamento de informações bem superiores a muitos 
governos, onde para se conseguir tal objetivo ( calar a boca dos 
desenvolvedores do processador ) não é dificil.
Quanto ao processador em si foi uma sugestão, o fator externo por de 
estar em um controlador qualquer da placa-mãe ou outro dispositivo que 
seja necessário.

Abraços a todos !!


-- 
Paulo Henrique.
BSDs Brasil - FUG-BR
site: www.fug.com.br

Rip Irado !!!
flamers > /dev/null