[GUFSC] ports do FreeBSD pode? funcionar no OpenBSD

[Emerson Ribeiro de Mello]

Ol=E1 Bernardo !!!

N=E3o estou dizendo com rela=E7=E3o a falhas de seguran=E7a e sim falhas na
aplica=E7=E3o.

Citando novamente o Oracle como exemplo, uma empresa estava programando
uma Stored Procedure como deve ser programada, abusando de todo o
potencial deste grande recurso existentes nos BD relacionais. L=E1 pelas
tantas ela descobre o comando: inc(10) retorna erro, coisa que n=E3o era
para acontecer, pois =E9 uma fun=E7=E3o padr=E3o que funciona em qq BD.

Ent=E3o a empresa comunica a Oracle, esta ir=E1 procurar investigar pq some=
nte
com aquele empresa deu esse problema, vai ver o hardware, a vers=E3o do BD,
a rotina q estava sendo executada, a carga do sistema no momento do erro,
enfim...tudo oq pode ter propriciado tal falha.

Achada uma solu=E7=E3o para tal problema, esta disponibiliza a corre=E7=E3o=
, envia
para a empresa a qual descobriu, claro, essa empresa teve que esperar um
tempo at=E9 a solu=E7=E3o aparecer.

Faz uma modifica=E7=E3o nas futuras vers=F5es do BD, e caso uma nova empres=
a
venha reclamar de tal erro, a resposta a esta ser=E1 instantanea.

Manjou a vantagem ? A primeira empresa perdeu uma semana para ter a
solu=E7=E3o, as demais perder=E3o alguns minutos. E claro, as futuras vers=
=F5es
n=E3o ter=E3o mais este erro.

Quanto mais gente utiliza um programa, mais ele =E9 testado e assim tende a
ser mais est=E1vel. O que acontece com as vers=F5es Alpha e Beta...acho q a=
 MS
nao espera muito tempo pra lan=E7ar a final, n=E9 :)

Falo,

Emerson


> > Eu discordo desse ponto de vista. Um dos maiores trunfos do Oracle, por
> > exemplo, =E9 que milhares de empresas o usam, da=ED o software =E9 test=
ado
> > mais que tudo no mundo. E assim fica mais f=E1cil de achar falhas e lan=
=E7ar
> > as devidas corre=E7=F5es.
> Caro Emerson, isso ocorreria num cen=E1rio onde todos estariam bem
> informados, fizessem suas atualiza=E7=F5es diariamente, estivessem todos =
bem
> preparados para uma eventual falha, mas o que acontece =E9 que nem todo
> mundo se d=E1 a esse trabalho.
> Deixe eu explicar um pequeno detalhe: quando sai uma vulnerabilidade e
> algu=E9m prepara um exploit pra ela, se voc=EA estiver lidando com uma
> vulnerabilidade de buffer overflow, voc=EA ter=E1 que saber o offset para
> que se possa explorar a vulnerabilidade. O offset depende de cada
> compila=E7=E3o. Se voc=EA muda um --isso --aquilo no configure, o bin=E1r=
io
> muito provavelmente vai ter um offset diferente. Desse modo, um exploit
> que diga que invada um "wu-ftpd 2.2(1) Red Hat Linux", n=E3o funcionar=E1
> automaticamente numa compila=E7=E3o da mesma vers=E3o feita para Debian.
> =C9 claro que isso pode ser alterado pra que voc=EA possa "invadir" ambos
> Debian e Red Hat, mas num universo onde 99% dos "hackers" (script
> kiddies, na verdade) s=F3 sabem digitar: ./exploit www.servidor.com.br
> isso n=E3o acontece, ent=E3o s=F3 o fato de voc=EA recompilar o bin=E1rio=
 j=E1 te
> livra desses 99% de sem-c=E9rebro que porventura pipoquem no seu servidor=
=2E
> >
> > [ ]'s
> > Emerson
>
> []'z
> Bernardo Silveira
> bernardojts@ig.com.br
> http://www.beastieb.host.sk/
>
> _______________________________________________
> GUFSC mailing list
> GUFSC@das.ufsc.br
> http://www.das.ufsc.br/mailman/listinfo/gufsc
>