Linux 2.5.25.10 liberado, y lo que piensa Linus de la gente de OpenBSD


Hace una semana fue liberada la nueva versión del de . En el correo anunciando su liberación se encuentra un pequeño resumen:

> It contains a number of assorted bugfixes all over the tree.  And once
> again, any users of the 2.6.25 kernel series are STRONGLY encouraged to
> upgrade to this release.

Lo curioso es que no mencionan muchos detalles acerca de la IMPORTANCIA de actualizar. Entre algunas respuestas al anuncio el equipo de PaX anuncio que dentro de los commits que se habían obviado mencionar se incluían una serie de correcciones al kernel que tenían alto impacto en la seguridad del mismo. (http://lwn.net/Articles/285438/, http://lwn.net/Articles/286263/, http://lwn.net/Articles/287339/, http://lwn.net/Articles/288473/)

En la misma discusión se cuestionaron las políticas de manejo de bugs “con impacto de seguridad” en los changelogs y demás notas de versiones, junto con otros aspectos de manejo de documentación al respecto. Esto llevo a que se hiciera hincapié en “la importancia de tener full/none/half/etc disclousures para los bugs que tengan relevancia en la seguridad”, con el siguiente párrafo:

so guys (meaning not only Greg but Andrew, , et al.), when will you
publicly explain why you're covering up security impact of bugs? and even
more importantly, when will you change your policy or bring your process
in line with what you declared?

Luego, en un reply de Linus:

Security people are often the black-and-white kind of people that I can't
stand. I think the  crowd is a bunch of masturbating monkeys, in
that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.

Y de hecho tiene muy buenas razones para haber dicho eso, ya que la industria de la seguridad informática se ha convertido en todo un teatro donde el que monte la mejor película es el que tiene la razón.

Linus dice que los bugs que tienen impacto en la seguridad son bugs normales, y tiene razón, técnicamente nadie diseña bugs en su software, y si tienes un bug probablemente no tengas la oportunidad de elegir si afecta o no en la integridad de la seguridad del kernel.

Son bugs normales, y como bugs se deben tratar, más no glorificar el esfuerzo de la persona que lo encontró ya que asi como existe ese bug, hay muchísimos más y de mayor complejidad en el kernel. No hay razón para que exista tal burocracia de tratarlos de manera muy diferente y subirlos sobre un pedestal y escribiendo HOWTO’s para como explotarlos.

De todas maneras, esto tambien influye en la comunidad de la seguridad informatica, ya que entre menos full disclousure tengamos, menor el numero de ataques y vulnerabilidades publicadas. Obviamente la idea no es no publicar los bugs, sino corregirlos y seguir el proceso de solucion y testeo que normalmente se sigue con los demas bugs.


Si te ha gustado el post, compartelo y ayudanos a crecer.

Unete a nuestra Fanpage Siguenos en Twitter

Autor: DragoN

Ingeniero en Sistemas y Telecomunicaciones de la Universidad de Manizales. Information Security Researcher con más de 10 años de experiencias en Ethical Hacking, Pen Testing y Análisis Forense. Docente Universitario en Pre y Post-Grado, Speaker y Organizador de diferentes eventos de Seguridad Informática, Co-Fundador del ACK Security Conference y Fundador de DragonJAR SAS y de La Comunidad DragonJAR, una de las comunidades de seguridad informática mas grandes de habla hispana y referente en el sector.

Compartir este Artículo
  • NONROOT

    Respeto tu opinión, pero el tema para mi es demasiado profundo para aclararlo en 3 líneas.

    Todo depende de los escenarios en los que hayas estado y de como te hayas comportado.
    Es muy diferente pensar como desarrollador (como linus), como hacker, como usuario final y etc. Todo depende.

    En algunos aspectos la seguridad informatica o la industria de la misma se comporta de forma incoherente, quizas como un circo o quizas como un espectaculo donde se aprovecha para vender productos e imagen, pero por otro lado, esa misma industria crea conocimiento y permite que fluya de una manera abierta. Siempre me he declarado a favor del full disclosure, tengo mis razones, pero como te digo no se explica en 3 líneas.

    En cuanto a los comentarios sobre lo que dice linus, ya se debatió el tema en la lista misc de openbsd, y son cosas que pasan todo el tiempo, quien tiene la razon?, imposible decirlo.

    A linus se le critica que esconde las cosas y que nunca hace commits con mucha información, lo que no permite que muchas personas aprendan del desarrollo del kernel, la gente de openbsd hace lo mismo.
    Son iguales, solo que unos hablan de mejoramiento (performance) continuo del kernel y otros hablan de proactividad en aspectos de seguridad.

    Un bug es un bug, pero un bug de seguridad no es comparable definitivamente a uno normal, solo por el hecho que se juega con la información de las personas y eso si es algo delicado. El provedor de un producto debe responder por eso, debe mantener, mejorar sus productos y debe garantizar la confidencialidad de los datos.
    Que de eso se haga un show es otro cuento, pero esos tipos de BUGS, jamas serán comparables, aunque sean igual de tontos o sean igual de complejos de encontrar y solucionar.
    No es lo mismo que mi programa se maximize de forma incorrecta a que una aplicacion web permita un acceso no autorizado a una base de datos de clientes. Hay muchas cosas de fondo para analizar.

    No es mas por ahora.

    Y la recomendación para todos, no se dejen guiar por los lideres de los mega proyectos, linus. theo y cualquier otra cantidad de gente estan en lo que estan y nunca vamos a poder seguir una corriente de pensamiento, porque ellos la crearon y son los que estan convencidos de eso, ni siquiera mucha gente del mismo core, se los aguanta. Entonces que nos deberia importar a nosotros?

  • arpunk

    Hay algunos temas que tocas que yo estoy de acuerdo, sin embargo existen algunos items que vale la pena resaltar.

    La industria no crea conocimiento, la industria ha explotado conocimiento inherente a la naturaleza del hacker y se ha mantenido en esta posición durante años. Si te pones a mirar, son muy pocos autores renombrados de herramientas y técnicas que han salido de la industria misma, el resto de personas no pertenecen o sienten lo mismo por la industria que Linus, y eso es innegable. También me queda sonando el tema del libre conocimiento gracias a la misma industria, ¿acaso no son ellos los que por lo general no apoyan el full disclousure por las repercusiones que esto pueda tener en la seguridad de los “clientes”?, de pronto no es toda la comunidad que rodea este circo, sin embargo si es la gran mayoría y eso deja algunas dudas en el aire.

    Tienes razón en la responsabilidad que tienen las personas de dar soporte a sus productos y por eso es la necesidad de majar este tipo de bugs de manera diferente, sin embargo, ¿es Linus quien da soporte para Linux?, no conozco bien el caso de OpenBSD, sin embargo en Solaris un bug de seguridad es técnicamente un bug, pero existe un soporte aparte para las actualizaciones criticas de dicho bug por la naturaleza de Solaris y su relación con Sun, y eso es completamente diferente al disparate que arman por los mensajes de un commit…

    Gracias por el comentario, tienes puntos fuertes a tener en consideración :)