gepe_

NewSID No servia para nada NewSID, una herramienta de seguridad incuestionable durante 12 años, no servía para nada La noticia no es nueva, realmente se hizo oficial y público en noviembre de 2009. Sin embargo, queremos recordar y ofrecer ahora esta información a nuestros lectores porque pensamos que no ha tenido la repercusión que merece. Es la historia de cómo un una herramienta de seguridad programada por el reputado Mark Russinovich ha sido utilizada durante 12 años... y no servía para nada. Sysinternals (liderada por Russinovich y comprada por Microsoft en 2006) jubiló para siempre NewSID en noviembre de 2009, después de ser creada y usada intensamente por muchos administradores desde 1997. Simplemente, no servía para nada, declaró el propio creador. ¿Cómo es posible que alguien con tan extensa y demostrada experiencia creara una herramienta "inútil"? Repasemos la secuencia de hechos e intentemos extraer algunas conclusiones: Detalles técnicos previos De forma breve, el SID (Security Identifier) es una variable numérica en Windows que define internamente a sistemas y usuarios. El sistema trabaja con SIDs y no con los nombres de usuario que nos muestra, por ejemplo, a la hora de acceder a NTFS y comprobar los permisos. Se entenderá con ejemplos: * SID S-1-1-0 es el SID universal del grupo "Todos" en todos los Windows, así este grupo es reconocido por igual en cualquier máquina, por ejemplo. Los SID son siempre los mismos para los grupos por defecto que existen en los Windows (Administradores, Usuarios, "Administradores de dominio", etc.) * S-1-5-21-1390034357-113127714-1060454298 es un ejemplo de SID de una máquina (y no de un usuario). * S-1-5-21-1390067357-113007714-1060284298-500, sería el SID del administrador de esa máquina. La parte final, el RID, siempre es 500 para los administradores y 1000 para el invitado; 1001, para el primer usuario y así sucesivamente. Un usuario borrado y vuelto a crear, aunque sea con el mismo nombre, no será realmente el mismo usuario porque su RID será distinto. Cuando un usuario se autentica en Windows, la Local Security Authority Subsystem (Lsass.exe) crea una sesión de logon y un token. Este token es una estructura numérica que contiene el SID de la cuenta y de los grupos a los que pertenece ese usuario además de todos los privilegios asignados a ese usuario y grupos. Se trata del "salvoconducto" que comprobará Windows cada vez que este usuario quiera realizar algo en el sistema tanto en cuestión de permisos (acceso a archivos en NTFS) como de privilegios. Al presentarse en sesiones remotas (por ejemplo al acceder a unidades compartidas), es necesario autenticarse en el Windows remoto con una cuenta conocida para él (ya sea local o de dominio). En ese momento, el sistema hace uso de ese token para comprobar si realmente un usuario "en remoto" puede acceder. Cuándo y por qué se usaba NewSID En entornos corporativos es común instalar un Windows y clonarlo a otras máquinas. En 1997, Microsoft ya disponía de Sysprep, que es una herramienta que cambia el SID y además "generaliza" un sistema (lo prepara para que sea clonado "sin problemas" ). Pero está muy limitado y (entre otros cambios) solo modifica el SID en Windows "vírgenes", si existen aplicaciones de terceros, no permite hacerlo. NewSID fue programado entonces para modificar consistentemente el SID de una máquina, aunque tuviese otras aplicaciones instaladas. Así, supuestamente, se garantizaba su estabilidad y además se evitaban problemas de seguridad por convivir con otras con el mismo SID. Es casi seguro que todos los usuarios y empresas que han clonado Windows en alguna ocasión han usado NewSID, con la esperanza de eliminar problemas de seguridad potenciales que se supone podían surgir por existir máquinas con el mismo SID en una red. Eso decía todo el mundo y nadie lo cuestionaba. Pero... ¿era necesario? En realidad, "todo el mundo asumió que otra persona sabría exactamente cuál era el problema". La pista Windows Vista empezó a fallar en alguna ocasión tras usar NewSID. Russinovich comenzó a depurar el programa y replantearse su funcionamiento. ¿De verdad mantener el mismo SID en diferentes máquinas era un problema? Este hecho no era cuestionado por nadie, mucho menos por el autor del programa. Pero cuanto más lo pensaba, más convencido estaba de que se había usado una herramienta inútil cambiar el SID no ofrece ventajas ni de seguridad ni de ningún tipo) durante más de 12 años. Mark pensó que la única forma de que efectivamente supusiera un problema, es que el SID realmente fuera referenciado por alguna máquina externa en alguna ocasión. Sólo así cabría la posibilidad de "usarlo ilegítimamente" de alguna forma en una red y que el hecho de compartir el SID fuera peligroso (permitiese a personas acceder a recursos que no le corresponden). Si el SID "viajara" hacia la otra máquina al compartir una unidad, por ejemplo, podría emplearse de forma insegura al comprobar los permisos. La clave Pero lo cierto es que Windows solo permite autenticarse en otro ordenador a través de un usuario válido para ese otro sistema (ya sea local o del dominio al que ambos pertenezcan). Una vez que se le ofrece ese usuario para autenticarse, la máquina remota toma el SID de su propia SAM, y si es el dominio, es el controlador el que lo toma de su base de datos. Ese Windows nunca hace referencia al SID de la máquina que quiere conectarse. Por tanto concluyó que el SID realmente no tiene un papel relevante a la hora de acceder a un sistema remoto y autenticarse sino que, lo que realmente cuenta, es un nombre de usuario y una contraseña. Aunque se comparta el SID, no se permitiría el acceso a nada. De hecho, realmente era obvio. Desde siempre, existen SIDs "universales" como el del grupo "Todos", la cuenta SYSTEM... ¿Ha supuesto alguna vez esto un problema de seguridad en una red? Sin embargo, se dan un par de excepciones en las que el SID sí que permitiría acceso a recursos ajenos: una de ellas es en el caso de discos duros externos formateados con NTFS. Dos máquinas con mismo SID podrían acceder a los archivos… pero la verdad es que existen otras maneras mucho más sencillas de acceder a un disco duro externo NTFS sin cifrar que la de "compartir" SIDs… Mark lo habló con los desarrolladores de Microsoft y el equipo de seguridad y, tras discutirlo ampliamente, retiraron NewSID en noviembre de 2009. Mantienen Sysprep porque realiza otras acciones necesarias para los Windows a la hora de clonar sistemas. ¿Y ahora qué? El propio Mark se sorprende de que el mito de la duplicación de SIDs no haya sido cuestionado hasta ahora. Como él mismo escribe "todo el mundo asumió que otra persona sabría exactamente cuál era el problema". Pero nadie lo sabía. De hecho, no había problema alguno. Mark programó, con la mejor de las intenciones y de una manera técnicamente brillante, una herramienta que solucionaba un problema que no existía. Ni siquiera para Microsoft estaba claro el asunto, y la herramienta no fue cuestionada en ningún momento. Tuvieron que pasar más de 12 años para descubrir que el esfuerzo realmente no hacía ningún bien (aunque afortunadamente, tampoco causaba ningún mal). Fuente: http://www.hispasec.com/unaaldia/4227/ http://www.hispasec.com/unaaldia/4229/ Más información: The Machine SID Duplication Myth http://blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx

Oracle demanda a Google por violación de patentes Así es, Oracle le dice al mundo que ha presentado una demanda contra Google ante una Corte de Distrito en California EE. UU. La empresa liderada por Larry Ellison asegura que el sistema operativo Android, producido por Google, viola su propiedad intelectual tan solo por usar Java. En particular, Oracle dice que puesto que Android está construido a partir de aplicaciones Java y otras tecnologías relacionadas, entonces quebranta una o más partes de siete diferentes patentes. Karen Tillman, vocero de Oracle, detalla: Karen Tillman dijo:Al desarrollar Android, Google infringrió consciente, directa y repetidamente la propiedad intelectual de Oracle relacionada con Java. Esta demanda busca remedios apropiados a tal violación. Según Oracle, Google debería estar al tanto de esa situación pues antes contrató ingenieros que fueron trabajadores de Sun, ---entre ellos Eric Schmidt, actual CEO de Google---. Andrew Paderson, vocero de Google, dice que la compañía que representa hará comentarios hasta revisar la demanda. Recordemos que Oracle adquirió Sun hace ya varios meses y con ello docenas de proyectos de software ---algunos de ellos dejados en el olvido---. Google, por su parte, vende unos 200.000 teléfonos móviles Android cada día. Así que todos y cada uno de ellos son, por decirlo así, producto de la piratería de Google. Pero al tratar la cuestión en la blogósfera estamos olvidando de mencionar algunos aspectos bastante importantes y al mencionar las patentes incluídas en la demanda sin profundizar toda la cuestión parece una locura. A ver, primero estamos olvidando de notar (en muchos artículos que he visto, es en los comentarios donde se dice) que el lenguaje de programación Java es 100% GPL y existen además OpenJDK y IcedTea, con los cuales podemos trabajar con Java en un entorno completamente libre, sin depender de ninguna JVM privativa (como la de Sun). El mismísimo Richard Stallman dio el ok para que los programadores trabajemos con Java. Ocurre que el panorama en Java ME es más bien distinto y si alguien quiere implementar la tecnología en desarrollos privativos, debe pagar licencias a Sun (ahora Oracle). Entonces, en este sentido, la ley estaría del lado de Larry. Por otro lado, el principal punto en el que el tratamiento de la noticia está siendo bastante amarillista se ve reflejado en titulares como “Oracle entierra el espíritu de Sun”, en el que se pone a Sun Microsystems como una compañía buena y respetable (por no decir pura e inmaculada) que fue adquirida por el gigante y malvado Oracle y todo lo que conocemos hoy en día. Claro que Sun tenía una política corporativa mucho más respetable que la de Oracle, ¿pero están famliarizados con el concepto "zona de grises"? Las cosas suelen ser más complejas que eso. El día de hoy y en respuesta a la demanda, James Gosling, creador del lenguaje que renunció a su puesto tras la adquisición de Oracle, escribió una entrada en su blog personal titulada apropiadamente “Finalmente, el ventilador está salpicando la mierda". Bastante corta, en ella dice: Oracle presentó una demanda por patentes contra Google. ¡Qué sorpresa! Durante las reuniones entre Sun y Oracle, cada vez que se mencionaba la situación entre Sun y Google, podíamos ver brillar los ojos de los abogados de Oracle. Pero presentar demandas por patentes nunca estuvo en el código genético de Sun. Hay dos lecturas de la entrada, pero para comprenderla es genial complementar su lectura con declaraciones realizadas en el mes de marzo por Jonathan Schwartz, ex CEO de Sun, también en su blog personal: Jonathan Schwartz dijo:Entiendo el valor de las patentes -con fines ofensivos y, aún más importante, defensivos. Sun posee algunas de las licencias más importantes de internet, por lo que nadie en la industria podría venir por nosotros sin temer un contra ataque. Y no hay mejor defensa que un buen ataque. Con respecto a la demanda, seguramente lleguen a un acuerdo y Google le pague a Oracle una importante suma de dinero que nunca conoceremos y Larry Ellison se quede un poco más tranquilo, aunque es posible también (que roguemos que así sea) la SFLC y la Public Patent Foundation invaliden las patentes, teniendo en cuenta el área ambigua en que están siendo utilizadas y con una licencia GPL. Ayudaría también a Google reemplazar todas las persiones de Java dentro de Android por OpenJDK. Pero el problema, como hemos dicho en este blog varias veces, son las patentes aplicadas al software. Aún tratándose de software libre, somos víctimas de las patentes (¡RMS tenía razón!) .Creo que las renuncias de algunos de los ingenieros más creativos de Sun, personas que participaron de algunos de los momentos más importantes de los últimos tiempos, que colaboraron en la creación de BSD y algunos de los protocolos y estándares que todos damos por sentado no tienen tanto que ver con prácticas nefastas de Oracle sino que demuestra un fracaso. El fracaso de una compañía con una profunda preocupación por la tecnología pero con una preocupante falta de conducción. Y eso, queridos amigos, es un pecado. Volviendo al asunto en cuestión, Google acaba de romper el silencio y realizó una breve declaración a TechCrunch: Google dijo:Estamos desepcionados de que Oracle haya decidido atacar a Google y la comunidad open source con esta demanda sin sentido. La comunidad de Java va mucho más allá de cualquier corporación y trabaja todos los días por construir una web mejor. Defenderemos con toda nuestra fuerza los estándares open source y continuaremos trabajando con la industria en el desarrolo de la plataforma Android. Google es, recordemos, uno de los responsables del uso actual de Java, gracias a Android y el GWT. En conclusión, toda la situación es un gran #fail y no es un buen día para ser un Java developer. ¿La esperanza? Claro que hay esperanza y es el OpenJDK: con él podemos utilizar, además de Java, lenguajes interesantísimos como Scala, Clojure y Groovy y ports de Python, Ruby, Erlang y un largo etcétera, que se convierten así en el futuro de una plataforma que supera al lenguaje para el que fue creada. Independiente del resultado, en palabras del creador del blog CodeMonkeysm, una de las voces más respetadas en el mundo de la programación: Google dijo:Creo que la demanda de Oracle acercará a la gente a OpenJDK -y eventualmente, el Java de Oracle morirá. Fuente: