[MASOCH-L] Sipvicious

Durval Menezes durval at tmp.com.br
Fri Apr 25 15:39:59 BRT 2014 

Prezado Douglas,

On Fri, Apr 25, 2014 at 02:14:46PM -0300, Douglas Fischer wrote:
[...]
> Quando eu analiso o ambiente do cliente, e chego a conclus??o que o que cabe
> melhor ali ?? uma solu????o de caixa fechada, um dos fatores que levo em
> considera????o ?? justamente o c??digo ser fechado.

Se nao olharmos estritamente para o aspecto de seguranca, eu concordo com voce
que em alguns casos a solucao "fechada" pode atender melhor a um ou outro cliente
(quando por exemplo a solucao aberta nao tem uma interface amigavel o suficiente,
e o cliente nao quer investir na contratacao/formacao de empregados com nivel 
tecnico suficiente para operar a solucao aberta e com interface menos amigavel).

Ou ainda, quando nao ha' solucao aberta que implemente determinada funcionalidade
necessarias para o cliente com o nivel de estabilidade e desempenho necessarios,
e ele nao tem tempo de esperar que a solucao aberta estabilize, nem esta' disposto
a investir (seja via um "bounty", ou pagando consultores para
customizar/depurar/otimizar a solucao opensource para o caso dele).

Mas, friso, nunca vi uma situacao em que a solucao fechada fosse mais segura que
a solucao aberta.

> Vou exemplificar minha posi????o tomando como exemplo descoberta de novas
> vulnerabilidades de seguran??a em solu????es.
> 
> TODAS solu????es est??o sujeitas a vulnerabilidades de seguran??a.
> Acho que disso ningu??m discorda, certo?

Concordo que tanto solucoes abertas como fechadas podem conter vulnerabilidades;
solucoes abertas, entretanto (devido `a Lei de Linus, que diz que "havendo olhos
o bastante, todos os bugs sao rasos") as solucoes abertas tendem a ter seus bugs
descobertos e resolvidos mais MUITO mais rapidamente do que nas fechadas.

Assim, os bugs em solucoes abertas tendem a ser em menor numero, e a permanecerem
por menos tempo, do que em solucoes fechadas.

> Empresas como Checkpoint, Cisco, Palo-Alto, quando tem vulnerabilidades
> identificadas em suas solu????es tem a pr??tica de INFORMAR INDIVIDUALMENTE
> que est??o cadastrados como usu??rios daquela plataforma afetada ANTES DE
> DIVULGAR PUBLICAMENTE A VULNERABILIDADE.
>    P.S.: Da?? a import??ncia de manter um contrato
>       de suporte com o fabricante, e l??gicamente
>       manter seu cadastro devidamente atualizado
>       por l??..

Voce nao deve ter prestado atencao ao meu ponto no email anterior;
repetindo aqui: quando o bug em um produto fechado fica "escondido" por
conta de um "conchavo" entre o fabricante e a NSA (ou outra "autoridade"
qualquer) ele nao e' consertado (e muito menos informado a ninguem) ate'
que ele seja descoberto e explorado por um terceiro.

> Quando se usa ferramentas OpenSource, a informa????o sobre a vulnerabilidade
> chega ao mesmo tempo na m??o do administrador do ambiente e do poss??vel
> intrusor, o que dispara uma corrida entre corrigir e atacar(Haja vista o
> HeartBleed).

Isso nao e' geralmente verdade: o procedimento responsavel de "disclosure"
de bugs de seguranca manda primeiro avisar ao responsavel (seja o time de
desenvolvimento do produto aberto, seja o fabricante do produto fechado),
e somente apos um prazo "razoavel" (mais do que suficiente para o problema
ser sanado) tornar a informacao publica.

O que aconteceu no caso do Heartbleed foi um certo "estrelismo" (IMNSHO) do
pessoal da Codenomicon, que menos de 4 dias apos terem descoberto (e reportado
de forma inicialmente responsavel, via CERT-FI) o bug, resolveram tornar a 
informacao publicamente disponivel antes da equipe de desenvolvimento do OpenSSL
(que ja' tinha recebido a informacao da falha, bem como um patch para a sua
correcao, ha' mais de 15 dias da equipe do Google que descobriu originalmente
o problema) ter tempo de terminar de fazer o release da versao incorporando a
correcao, e menos ainda das distribuicoes atualizares seus pacotes para a nova
versao e os disseminarem. 

Veja que o caso do Heartbleed, alem de poder ter acontecido de forma semelhante
tambem com produtos de software fechado (como de fato acontece com
bastante frequencia), foi uma excecao: a grande maioria dos problemas de
seguranca em produtos abertos sao descobertos, reportados privativamente,
corrigidos e disseminados muito antes de serem explorados. Nao e' o que
vemos nos produtos fechados, onde notadamente a exploracao do problema
chega muito antes da sua solucao pelo fabricante (e' so' observar o
fracasso de seguranca constante que e' o Windows).

Isso, e' claro, trata-se somente da minha opiniao, mas acredito que seja uma
opiniao bem fundamentada...

Um Grande Abraco,
-- 
  Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)


> 
> Em 25 de abril de 2014 13:25, Durval Menezes <durval at tmp.com.br> escreveu:
> 
> > Prezados,
> >
> > Desculpem-me, mas discordo de ambas as posicoes; a saber:
> >
> > Douglas: o que voce diz muito se parece com a velha posicao de que
> >          "ninguem nunca foi mandado embora por comprar da IBM".
> >          Com todo o respeito (e ressalvando que nao acredito que tenha
> >          sido isso que que voce tenha *querido* dizer), esta e' uma
> >          posicao mediocre de quem esta' tentando somente proteger o
> >          proprio traseiro, nada digna de tecnicos como nos, que
> >          frequentamos o MASOCH-L.
> >
> > Bruno: ninguem garante que *somente* a NSA saiba; se o furo esta' la',
> >        e' questao de tempo ate' ser descoberto por alguem que ira' vender
> >        a falha no mercado de "zero days" para o proximo ataque em massa
> >        a la Zeus ou similar. Questoes de privacidade `a parte, na minha
> >        opiniao o grande problema do "conchavo" entre os fabricantes de
> >        produtos fechados e a NSA e' que ele praticamente garante que
> >        os problemas vao permanecer no codigo eternamente enquanto nao
> >        forem descobertos (e utilizados) por terceiros... o que IMNSHO
> >        mais uma vez demonstra que nao e' possivel construir estruturas
> >        de informacao realmente seguras utilizando produtos fechados.
> >
> > Um Grande Abraco,
> > --
> >   Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)
> >
> >
> > On Fri, Apr 25, 2014 at 12:04:44PM -0300, Douglas Fischer wrote:
> > > Assim...
> > >
> > > Eu n??o acho que a NSA precise usar meu SIP Session Manager p/ vender
> > > liga????es VOIP Piratas.
> > >
> > > E se o Router que eu especifiquei e configurei for hackeado pela NSA,
> > > atrav??s de supostas backdoors impostas ao fabricante, bom... Meu
> > trabalho
> > > foi bem feito!
> > > N??o ser?? uma vergonha para mim.
> > >
> > > Mas se eu especificar uma distro X, deixar passar algum furo, e algum
> > > noobie usando Cain e Abel conseguir entrar nela, meu filme vai ficar bem
> > > tostado...
> > >
> > >
> > >
> > > Em 25 de abril de 2014 11:48, Bruno Cabral <bruno at openline.com.br>
> > escreveu:
> > >
> > > > Aquelas que os furos apenas a NSA sabe...
> > > >
> > > > !3runo
> > > >
> > > >
> > > > > Por isso eu amo appliances...
> > > > >
> > > > > Appliances MESMO, n??o distro customizadas.
> > > > > Aquelas onde tudo ?? chrootado, onde a console ?? limitada, onde
> > tudo ??
> > > > > capado...
> > > >
> > > > __
> > > > masoch-l list
> > > > https://eng.registro.br/mailman/listinfo/masoch-l
> > > >
> > >
> > >
> > >
> > > --
> > > Douglas Fernando Fischer
> > > Eng?? de Controle e Automa????o
> > > __
> > > masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> 
> 
> 
> -- 
> Douglas Fernando Fischer
> Eng?? de Controle e Automa????o
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l

More information about the masoch-l mailing list