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
