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

[jorge luis carvalho santos luis]

> Date: Sun, 25 Nov 2012 11:39:39 -0200
> From: paulo.rd...@bsd.com.br
> To: freebsd@fug.com.br
> Subject: Re: [FUG-BR] [OFF-TOPIC]Foi realmente colocado backdoor no ipsec do 
> OpenBSD?
> 
> 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.rd...@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
> 
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Antes de colocar esse tópico na lista Freebsd, coloquei na lista Openbsd-BR, 
mas quando vi que nunca responderiam, coloquei esse tópico aqui.
Porque será que não fui respondido?
Há alguém da lista Freebsd que é inscrito na lista Openbsd-BR?
Será que se os moderadores da lista Freebsd colocarem esse tópico na lista 
Openbsd-BR também não serão respondidos?
                                          
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd