Un artículo reciente del blog analizó el hecho de que el 70% de todos los errores de seguridad en los productos de Microsoft se deben a vulnerabilidades de seguridad de la memoria. Muchos de los comentarios que he visto en las redes sociales se reducen a "el problema no es el uso de un lenguaje inseguro en la memoria, sino que los programadores que escribieron este código son malos".
#4 Disiento, incluso juntar trozos de código correcto, puede generar estructuras incorrectas y esto es culpa de el que junta trozos sin comprender las cosas.
Errores típicos son overflows del stack o del heap y son por no falta de validación, como otros muchos errores tipo sqli o rce que aún no teniendo nada que ver, tienen orígenes comunes.
#5 ¿Fallta de validación de qué trozo de los varios? Cuando uno escribe una librería que asigna memoria, implementa (por qué no) la función de ampliar y reducir la memoria usada. Otro módulo que necesita asignar memoria va y muy correctamente usa esa librerría. Cuando amplia memoria, lógicamente borra la nueva antes de soltarla, solo por si acaso. Cuando reduce memoria esto no hace falta. Todo absolutamente correcto.
Entonces un usuario de la aplicación encuentra la manera de hacer que la aplicación reduzca memoria en un valor negativo a base de colar valores especialitos por algun sitio del frontend. El frontend desconoce que detrás haya asignadores de momoria pues eso no es su problema. Es incluso posible que los valores negativos tengan algún sentido. El módulo intermedio incluso los trata después de haber llamado al asignador. La librería va y lo "desasigna negativamente", como debe hacer ya que ese es su trabajo. Ya tienes memoria usable con datos precargados, bienvenido al stack overflow.
#6 Esa librería que describes está mal hecha. Lo primerísimo que tienes que hacer en una función encargada de gestionar memoria es validar que los parámetros son válidos.
De todas formas para tener "memoria usable con datos precargados" no necesitas tanta floritura. Simplemente espera a que la memoria sea liberada y listo. Si tú en un servidor (Menéame mismamente) subes una imagen que en vez de una imagen son datos binarios, es muy posible que esos datos binarios acaben en una zona de memoria libre.
El problema está en hacer que el programa salte a esa memoria, y que esa memoria sea ejecutable.
#8 Este no es el tema. Por supuesto que es siempre1 posible añadir un control adicional que pare el exploit. El tema es si el programador que ha construido el sistema podía saberlo antes de que se reportara el exploit. Lo que defiende el artículo es que ni de coña.
#9 El problema, desde mi punto de vista, es si el programador tiene los conocimientos para evitar el problema, trabajo con programadores muy buenos, pero con una formación nula o insuficiente en seguridad.
#10 Esto de las personas que no saben de seguridad tiene un problema muy insidioso. El caso es que cuanto menos sabes de seguridad más te crees capaz de hacerlo por tí solo. Así se creó el protocolo WiFi 802.11g, un auténtico desastre insalvable.
La realidad es que la seguridad es algo que se debe conocer muy bien. Los profesionales del tema se conocen la historia de los errores cometidos en el pasado, algo esencial.
Una segunda parte es que esas personas"novatas" son muy capaces de hacer las cosas al revés, es decir construir un sistema sin seguridad y añadirla después. Esto podría funcionar pero de forma cara e incompleta. La seguridad debe estar presente desde el diseño inicial y de esta manera se puede añdir sin coste adicional.
Menuda tontería, no hay más que ver el owasp top ten para ver cuáles son los mayores problemas de seguridad y adivina, el problema si son los programadores.
El motivo por el que existen fallos de seguridad es el mismo por el que existen fallos, en general. Los humanos cometen errores. Puedes calificar a alguien como "bad coder" si comete varios errores y éstos son obvios. Al final es algo subjetivo.
Esta discusión se superó hace mucho tiempo. Es perfectamente factible y probable juntar varios trozos de código, todos ellos escritos cumpliendo una especficaciones correctas, incluso programados cuidadosamente para evitar cosas imprevistas, y que el resultado sea un agujero de seguridad del tamaño de Júpiter.
El artículo propone uno de estos casos totalmente imprevisibles. Hay miles y miles de casos distintos posibles con un resulltado similar. Los programadores necesitarían ser dioses para pillar esto, y ni así lo creo posible.
Por lo tanto el descubrir agujeros y poner parches sobre agujeros es el proceso normal que va a seguir en marcha para siempre.
#1 No. Un agujero de seguridad no necesita de un error para existir.
Coño. Y la mayoría de los accidentes de coche graves son a alta velocidad. ¿Vamos todos en triciclo?
Más nos valía una formación adecuada en la universidad, que se sale sin saber qué es fsanitize o cómo usar una herramienta de análisis estático. Y ya no hablemos de testing automatizado o de revisiones de código. Pero cuando los profesores no han desarrollado software en su vida y siguen creyendo que existen los "analistas" y que para programar ya están los de efepé, pues no avanzamos.
Comentarios
#4 Disiento, incluso juntar trozos de código correcto, puede generar estructuras incorrectas y esto es culpa de el que junta trozos sin comprender las cosas.
Errores típicos son overflows del stack o del heap y son por no falta de validación, como otros muchos errores tipo sqli o rce que aún no teniendo nada que ver, tienen orígenes comunes.
#5 ¿Fallta de validación de qué trozo de los varios? Cuando uno escribe una librería que asigna memoria, implementa (por qué no) la función de ampliar y reducir la memoria usada. Otro módulo que necesita asignar memoria va y muy correctamente usa esa librerría. Cuando amplia memoria, lógicamente borra la nueva antes de soltarla, solo por si acaso. Cuando reduce memoria esto no hace falta. Todo absolutamente correcto.
Entonces un usuario de la aplicación encuentra la manera de hacer que la aplicación reduzca memoria en un valor negativo a base de colar valores especialitos por algun sitio del frontend. El frontend desconoce que detrás haya asignadores de momoria pues eso no es su problema. Es incluso posible que los valores negativos tengan algún sentido. El módulo intermedio incluso los trata después de haber llamado al asignador. La librería va y lo "desasigna negativamente", como debe hacer ya que ese es su trabajo. Ya tienes memoria usable con datos precargados, bienvenido al stack overflow.
#6 Esa librería que describes está mal hecha. Lo primerísimo que tienes que hacer en una función encargada de gestionar memoria es validar que los parámetros son válidos.
De todas formas para tener "memoria usable con datos precargados" no necesitas tanta floritura. Simplemente espera a que la memoria sea liberada y listo. Si tú en un servidor (Menéame mismamente) subes una imagen que en vez de una imagen son datos binarios, es muy posible que esos datos binarios acaben en una zona de memoria libre.
El problema está en hacer que el programa salte a esa memoria, y que esa memoria sea ejecutable.
#7 Exactamente, tal y como cuenta #6 no se está validado correctamente un dato del FE.
#8 Este no es el tema. Por supuesto que es siempre1 posible añadir un control adicional que pare el exploit. El tema es si el programador que ha construido el sistema podía saberlo antes de que se reportara el exploit. Lo que defiende el artículo es que ni de coña.
1bueno, casi siempre
#9 El problema, desde mi punto de vista, es si el programador tiene los conocimientos para evitar el problema, trabajo con programadores muy buenos, pero con una formación nula o insuficiente en seguridad.
#10 Esto de las personas que no saben de seguridad tiene un problema muy insidioso. El caso es que cuanto menos sabes de seguridad más te crees capaz de hacerlo por tí solo. Así se creó el protocolo WiFi 802.11g, un auténtico desastre insalvable.
La realidad es que la seguridad es algo que se debe conocer muy bien. Los profesionales del tema se conocen la historia de los errores cometidos en el pasado, algo esencial.
Una segunda parte es que esas personas"novatas" son muy capaces de hacer las cosas al revés, es decir construir un sistema sin seguridad y añadirla después. Esto podría funcionar pero de forma cara e incompleta. La seguridad debe estar presente desde el diseño inicial y de esta manera se puede añdir sin coste adicional.
#11 Exactamente
Menuda tontería, no hay más que ver el owasp top ten para ver cuáles son los mayores problemas de seguridad y adivina, el problema si son los programadores.
El motivo por el que existen fallos de seguridad es el mismo por el que existen fallos, en general. Los humanos cometen errores. Puedes calificar a alguien como "bad coder" si comete varios errores y éstos son obvios. Al final es algo subjetivo.
Esta discusión se superó hace mucho tiempo. Es perfectamente factible y probable juntar varios trozos de código, todos ellos escritos cumpliendo una especficaciones correctas, incluso programados cuidadosamente para evitar cosas imprevistas, y que el resultado sea un agujero de seguridad del tamaño de Júpiter.
El artículo propone uno de estos casos totalmente imprevisibles. Hay miles y miles de casos distintos posibles con un resulltado similar. Los programadores necesitarían ser dioses para pillar esto, y ni así lo creo posible.
Por lo tanto el descubrir agujeros y poner parches sobre agujeros es el proceso normal que va a seguir en marcha para siempre.
#1 No. Un agujero de seguridad no necesita de un error para existir.
Coño. Y la mayoría de los accidentes de coche graves son a alta velocidad. ¿Vamos todos en triciclo?
Más nos valía una formación adecuada en la universidad, que se sale sin saber qué es fsanitize o cómo usar una herramienta de análisis estático. Y ya no hablemos de testing automatizado o de revisiones de código. Pero cuando los profesores no han desarrollado software en su vida y siguen creyendo que existen los "analistas" y que para programar ya están los de efepé, pues no avanzamos.