Security Tracker reporta el primer problema de seguridad (vía Slash)encontrado en el código de Windows que se liberó el jueves 12. A menos de 4 días y ya hay un problema que se encontraba oculto en IE5.0
The author states that this flaw was found by reviewing the recently leaked Microsoft Windows source code. The flaw reportedly resides in 'win2k/private/inet/mshtml/src/site/download/imgbmp.cxx'.
Ya empezaron los problemas de seguridad.
Update 18:44
El principio de los problemas
Esta falla de seguridad se conoce a menos de 4 días de haberse "liberado" el código de Windows NT y 2000. Convengamos que no es tiempo suficiente para mirar detenidamente los 600 Mb de código liberado, que esta falla no toma control total de la PC y que, a un Black-Hat, le sería más interesante y útil dedicarle tiempo a buscar fallas de seguridad que permitan tomar control de los datos y/o equipos remotamente.
Primer idea "esta falla sólo se liberó para demostrar que las fallas existen y están ocultas; no buscan hacer daño sino demostrar la inseguridad intrínseca de Windows".
En realidad no existe el SO seguro 100%, simplemente existe la responsabilidad de cerrar agujeros que existen en un producto, antes de salir al mercado, o cuando eso no sea posible porque el potencial no se descubrió, arreglarlo urgentemente al descubrirlo.
Segunda idea: "la necesidad de lanzar nuevos productos y generar ingresos con las dos únicas unidades de negocio que dan plata (MsOffice y MsWindows) no dan tiempo de hacer, al mismo tiempo, revisiones de seguridad línea por línea"
Cuando uno desarrolla código en un ambiente cerrado/propietario realizar una auditoría de seguridad es algo bastante complicado (Un simple ejemplo: en mi caso realizar una auditoría a un sistema de BI con acceso vía web, implicó contratar a una consultora y firmar más de 4 acuerdos de diferentes niveles de ruptura de contrato, confidencialidad, daños y perjuicios emergentes, etc.) y en el caso de Windows debe ser aún peor.
Estamos hablando del conjunto de código más rentable y secreto del mundo. Un monstruo de más de 40 millones de líneas que, encima, sirvió como excusa para juicios contra monopolio, juicios por interoperabilidad y juicios por políticas comerciales.
Tercera idea: "Una auditoría externa daría acceso a terceros al código-de-oro de MS. Y no tiene sentido comercial porque al ser yo el único con acceso a ese código nadie debería poder ver los problemas de seguridad"
Algunos escenarios potenciales
Todo, pero ABSOLUTAMENTE todo, lo que se escribió sobre el tema en estos cuatro días fueron escenarios y suposiciones sin una base firme, porque no se tenía conocimiento real de las líneas "liberadas", de los módulos incluídos en este "robo" y, mucho menos, de la capacidad de encontrar utilidad en los mismos.
Sin embargo con este primer problema, es evidente que algunas de las suposiciones no eran erradas. Al menos la primera preocupación sobre la seguridad empezó a demostrar su validez y, teniendo en cuenta que esto afecta a IE 5.0 pero NO a IE 6.0, creo válido que tengamos en cuenta la cantidad de vulnerabilidades no solucionadas, o sea que hacer un upgrade de 5.0 a 6.0 , garantiza protección de esta vulnerabilidad recien descubierta, pero no implica seguridad 100%.
Podemos aprovechar y descartar algunas ideas conspirativas como "MS puede decir que algun programa Open Source utiliza código robado y hacer la `Gran SCO´" no es lógico, para algo existen los snapshot previos que servirían como "arte previo" y demostrar que el código no ha sido robado, lo que podría poner al demandate en el lugar de demandado por falsas afirmaciones y etc.
Interesante posiblidad
En el primer post sobre el tema, yo imagine que se podría encontrar "el camino" a hacer más interoperables algunas aplicaciones de terceras partes, sean nativas en Linux o no y en los comentarios, mientras se decía que era ridículo hacerlo porque "Win estaba muerto" (o algo así).
Pero, según la "Historia Oficial" este código estaba en manos de un Partner que tiene un producto para interoperabilidad de Aplicaciones Win32 en entornos Unix o sea que para desarrollar necesitaban las APIS, rutinas.. para hacer exactamente eso!
Tener a mano el código que "llama" las funciones a ejecutar es algo increíble para un desarrollador y seguro en algún momento alguien tomará ventaja de eso... y no será simple agarrarlos, porque a los developers el código no les interesa, sólo les interesa saber como "llamar" esos procedimientos, API´s y demás, para lograr que sus programas interoperen, casi, nativamente.
Boomerang
Microsoft siempre dijo "el control del código nos permite tener un producto mas seguro". ¿Que pasaría si empiezan a aparecer Bugs, Exploits y otros problemas de seguridad casi al mismo tiempo que soluciones a estos? ¿No demostraría esto que el "peer-review" tiene más efectividad que otros sistemas?
¿No sería este otro golpe a las Relaciones Públicas de MS? Convengamos que en un primer momento su comunicado de prensa fue poco menos que patético, solo diciendo "no fue un error de seguridad nuestro" y "no hay impacto actual sobre los clientes", cosa lógica porque no podía haberlo en menos de 15 minutos ;)
Este tema sólo va a desembocar, seguramente, en más vulnerabilidades y, tal vez, sólo tal vez en un cambio en las políticas de seguridad de MS.
Yo dije que tardarian 2 semanas pero veo que se dan mucha prisa.
esto demuestra que el codigo abierto ahce posible que se pueda encontrar mejor los errores de codigo. parece que tu post anterior propiciara esta situacion (el de las ventajas del codigo abierto frente al cerrado), una vez mas la realidad supera la ficcion.
Esto demuestra la gran ventaja del codigo abierto.. al final de tanta gente detectando y corrigiendo errores, obtienes un codigo mas depurado y un sistema con mayor calidad, seguridad y estabilidad.
Viva el Open Source!