FAQ de Advisories

[AlbertoBSD]

Contenido

• Conceptos
  
• Como reportar una vulnerabilidad
  
• Formato sugerido para el reporte de una Vulnerabilidad
  
• Lista de Advisories públicos mas relevantes
  
• Full Disclosure Policy
  
  
  Advisories: En términos informáticos son Avisos sobre fallas de seguridad, generalmente son públicos después de que la falla a sido reportada hacia el vendor y este notifica que ya tiene un parche. Existen también aquellos que son liberados antes de que exista el parche y es cuando empiezan a salir Zero-day exploits.
  Estos advisores pueden variar en contenido y forma, van desde la simple nota de la existencia de una vulnerabilidad en alguna función o modulo de programa o hasta la explicación técnica de en que puntos esta la falla, y la manera de explotarla.
  
  Proof of concept: Prueba de concepto es un corto y/o incompleta realización (o síntesis) de un determinado método o idea para demostrar su viabilidad, o una manifestación, en principio, cuyo objetivo es verificar que un concepto o teoría es, probablemente, en condiciones de explotación de una manera útil. Un (algo sinónimo) plazo es "la prueba de principio".
  La prueba de concepto es generalmente considerado un hito en el camino hacia el pleno funcionamiento del prototipo.
  En seguridad informática, el término de prueba de concepto (código de prueba de concepto o PoC) se utiliza a menudo como un sinónimo de un Zero-day, principalmente para su pronta creación, no tiene ventaja sobre algunos de vulnerabilidad.
  
  
  
  Lista de Advisories de elhacker.net
  
  http://www.elhacker.net/advisories/
  
  
  Como reportar una vulnerabilidad
  
  Ya sea que encontremos un bug/error de pura casualidad o investigación y logremos detallar los pasos de como lo descubrimos y/o realizamos en ese momento podremos dar reporte a la falla.
  
  
  
  
  • El primer paso es delimitar el alcance de la falla.
  Verificamos si es la ultima versión del software ya que si no es así o si existen actualizaciones que no tengamos puede que demos con una falla vieja, esta puede o no puede estar reportada.
  
  Dependiendo de esto ultimo procederemos o no y trataremos de ver si versiones anteriores son vulnerables también.
  
  
  
  • Medir el impacto de la falla
  Aqui determinamos el impacto de la falla sobre el sistema que la hospeda, entre los mas comunes tenemos:
  
  Denegación de Servicio
  Es el mas común, generalmente no pasaremos de hacer que la aplicación deje de funcionar
  
  Consumo de recursos
  Si no deja de funcionar, podremos causar algún consumo adicional de memoria y/o microprocesador
  
  Ejecución de Código
  Es lo que se busca en la mayoría de las veces, si logramos insertar código y ejecutarlo el sistema podría estar totalmente comprometido
  
  Revelado de información
  En dado caso podríamos revelar información que se supone que no deberíamos de poder ver.
  
  Algun Error menor
  Se podría dar la situación en la simplemente sobrescribamos alguna variable menor. Solo por mencionar algún ejemplo.
  
  
  
  
  • Encontrar el medio de comunicación con el creador del software (vendor)
  Esto es mas importarte. La mayoría de los software que son públicos tienen un correo/pagina de contacto. Es importante comunicarte con el vendor y darle detalles de la falla que encontraste los pasos que seguiste, y si puedes da sugerencias para mejorar el software.
  
  
  
  
  • Arreglado/Corregido
  Después de Intercambiar algunos correos y ver que el bug sea arreglado y este disponible un parche o nueva versión ahora si es posible publicar el bug en un blog/web propios y posteriormente publicarlo en alguna pagina como securityfocus, milw0rm entre otras.
  
  Cabe mencionar que muchas veces el bug no sera parcheado o puede tardar mucho.
  
  
  
  
  Formato sugerido para el reporte de una Vulnerabilidad
  
  Generalmente estos se reportan en texto plano.
  La mayoría de lista de correo esperan no mas de 80 caracteres por fila.
  Organización y Secciones recomendadas
  
  
  
  • Limitación
  • Descripción del Software
  • Descripción del Problema
  • Impacto
  • Solución
  • Referencias
  • Créditos
  
  La organización de dichas secciones puede variar y por su puesto que estas se reportan en ingles.
  
  Un ejemplo del reporte de una vulnerabilidad podria ser el siguiente
  
  
  Código [Seleccionar] Expandir
  
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=============================================================================
Sun Mar 8 21:06:34 CST 2009 Heuristics and Exploiting Vulnerabilities
elhacker.net

Topic: flv2mpeg4: Malformed parameters Denial of Service

======================================================================

Table of Contents

1- Affected Software.
2- Background.
3- Problem Description.
4- Severity
5- Solution
6- Time Table
7- Credits
8- About elhacker.net

======================================================================
1) Affected Software

flv2mpeg4 v1.1

Prior versions may also be affected.

======================================================================
2) Background

flv2mpeg4 allows you convert a Flash Video / FLV file (YouTube's videos,etc)
to MPEG4 (AVI/MOV/MP4/MP3/3GP) file online. It is using a compressed domain
transcoder technology (outline in Japanese). It converts FLV to MPEG4 faster
and less lossy than a typical transcoder.

http://www.freebsd.org/cgi/url.cgi?ports/multimedia/flv2mpeg4/pkg-descr

======================================================================
3) Problem Description

As we can see flv2mpeg4 receives 2 parameters the first is expected to be
a flv file and second mpeg4 (AVI/MOV/MP4/MP3/3GP), the problem is a clerical
error in the parameters or a parameter poorly trained, causing the
application to stop running unexpectedly

for example:

Anon@localhost % flv2mpeg4 Video.flv Video.mpg
Segmentation fault (core dumped)

in this mpg extension is incorrect

Anon@localhost % flv2mpeg4 Video.flv `perl -e '{print "A"x4000,".avi"}'`
Segmentation fault (core dumped)

Although the extension is correct in this case, does not allow such a long
file name

======================================================================
4) Severity

Rating: Very low risk
Impact: Denial of service
Where: Local

======================================================================
5) Solution

Run flv2mpeg4 done correctly with the parameters in order

======================================================================
6) Time Table

22/12/2008 - Vendor notified.
23/12/2008 - Vendor response.
08/03/2009 - Public disclosure.

======================================================================
7) Credits

Discovered by Anon, elhacker.net

======================================================================
8) About elhacker.net

Overall objective of the forum elhacker.net
Promote research and encourage the dissemination of knowledge by providing
a means of information, protecting and fighting for their freedom.

Subforum Heuristics and exploitation of vulnerabilities.
Following the overall objective of the forum, subforum Heuristics and
exploitation of vulnerabilities (Bugs and Exploits), aims at promoting
research into techniques for detection and exploitation of vulnerabilities
in any operating system or program that might allow the execution of
arbitrary code, or any other means which violate the confidentiality,
integrity, or availability of information.

http://foro.elhacker.net/
http://foro.elhacker.net/bugs_y_exploits-b32.0/

=============================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkm0mE4ACgkQd963iVkvICn7GQCeIonHNhFV/pdu7uvuZG4ucq+A
lMEAoIEDL8JsG1mbb2RrAutEN2TaXs/5
=mi4f
-----END PGP SIGNATURE-----

  
  Como ven tiene las secciones recomendadas y alguna extras, ademas va firmado mediante pgp lo cual es recomendable hacer.
  
  
  
  
  Para reportar (en Ingles) algúna falla en las listas de BugTraq
  
  :http://www.securityfocus.com/archive/post/1
  
  
  Lista de Advisories públicos mas relevantes
  
  Veremos los ultimos Advisories publicos, con las opciones de ir especificando el vendor del software y la version del mismo
  :http://www.securityfocus.com/bid
  
  La lista de Symantec no están extensa como las anteriores sin embargo contiene Advisores mas relevantes de la familia de M$ y algunos otros como Adobe
  :http://www.symantec.com/business/security_response/landing/vulnerabilities.jsp
  
  Full Disclosure Policy (RFPolicy) v2.0
  :http://www.wiretrip.net/rfp/policy.html
  
  
  Saludos.

[plAnadecU]

Esta es una buena fuente de reportar bugs:  https://www.zerodayinitiative.com

Siempre sales ganando. Aunque no se si es muy lícito. Venderan los exploits a grupos maliciosos?
Los utilizan para spam/espionaje/chantaje?

Saludos.

[sirdarckcat]

Tanto ZDI como iDefense labs son propuestas completamente legales respaldadas por empresas altamente reconocidas.

Que bueno que los mencionas porque son una alternativa para reportar vulnerabilidades muy importante.

El protocolo de la vida de la vulnerabilidad es publico, y se te reporta como evolucionan las cosas.. no se venden las vulnerabilidades a ningun grupo, los unicos que reciben los detalles de esta son el distribuidor.

Saludos!!

[AlbertoBSD]

Bien ya estan quedando las FAQs

En este topic podremos poner un lista a los Advisories que estemos estudiando o discutiendo. Dicha lista tendría el link al advisory en este foro alguna explicación del mismo o informe de los avances, referencia CVE u Otra si es que tiene, porcentaje entre otros.

[P] PoC
[E] Exploit

Código [Seleccionar] Expandir


[*] [url=LINK]Nombre[/url]
Referencia: AAA-XXXX-YYYY
[quote]Otro advisory del que podemos aprender cosas nuevas[/quote]
Paper: [url=LINK]Nombre[/url]
Porcentaje: %100
[P][E]





Bien aqui pondre en los que me he quedado.

• FFmpeg Type Conversion Vulnerability
  Referencia: CVE-2009-0385
  

  Ejecución de código confirmada por Tobias Klein. Es una vulnerabilidad muy bien explicada, sin embargo no he podido generar el PoC debido a que el archivo que he generado no tiene al parecer el formato adecuado

  Paper: CVE-2009-0385.pdf
  Porcentaje: %50
  
  
• BoF en inet_network(), afecta a Servidor DNS: BIND
  Referencia: CVE-2008-0122
  

  Pequeño Off-by-One, muy simple y no pude verlo desde el principio, con el analisis que se le dio se comprende del todo el por que del Advisory

  Paper: CVE-2008-0122.pdf
  Porcentaje: %100
  [P]
  
  
  
• Winamp <= 5.541, libsndfile <= 1.0.17 AIFF buffer unverified
  Referencia: CVE-2009-0263
  

  "Multiple Buffer Overflow Vulnerabilities" se analizo solo una de las vulnerabilidades debido a que preguntaron por el uso del PoC, me he comunicado con Erik autor de la libreria y hemos visto que solo es un DoS a la aplicacion que use la libreria.

  Porcentaje: %50
  [P]
  

[berz3k]

@Anon

Te falta agregar la politicar FULL-DISCLOSURE , politica implementada ya de hace muchos años por RFP, existe ahora la v2.0, que ha grandes rasgos es la libertad de publicar o no, despues de un periodo del primer contacto con el vendor.

Full Disclosure Policy (RFPolicy) v2.0
:http://www.wiretrip.net/rfp/policy.html

-berz3k.

[AlbertoBSD]

He agregado el Full Disclosure Policy al primer post

• [OB] CVE-2009-3546 - Analisis de libgd
  Referencia: CVE-2009-3546
  

  libGD -- _gdGetColors buffer overflow

  Paper: CVE-2009-3546.pdf
  Porcentaje: %100
  [P]
  

[adulti]

Después de Intercambiar algunos correos y ver que el bug sea arreglado y este disponible un parche o nueva versión ahora si es posible publicar el bug en un blog/web propios y posteriormente publicarlo en alguna pagina como securityfocus, milw0rm entre otras.