[Noticia] Sobre el SP2...

Básicamente NX permitirá al sistema operativo separar código de programa

con los datos de los mismos, estableciendo una >clara separación desde el
hardware que pretende en lo posible impedir los cada día más frecuentes
problemas de seguridad y >virus de Windows.

huh!!!,
Me ha dejado tan iluminado que me quede en blanco



Saludos
Mr Big Dragon


"Ille Corvus" wrote in message
news:

http://www.hispamp3.com/noticias/no...hp?noticia 031104122708

A mi me suena a Palladium...


Ille Corvus. Res, non verba.
"Cave canem..."

La noticia correcta y completa la publicó Fran Arreciado
[MS] hace unos dias y no esa mala e incompleta traduccion.


http://msdn.microsoft.com/library/en-
us/dnwxp/html/securityinxpsp2.asp?frame=true

http://www.hispamp3.com/noticias/noticia.php?

noticia 031104122708

A mi me suena a Palladium...


Ille Corvus. Res, non verba.
"Cave canem..."
.

Muy fiables los de HispaMP3... pero me quedo con la **oficial**

http://msdn.microsoft.com/library/e...frame=true




Saludos,

Marc
MS MVP - Windows Shell/User

NOTA. Por favor, las preguntas y comentarios en los grupos, así nos beneficiamos todos.

Reglas de conducta de los grupos de noticias: http://support.microsoft.com/defaul...newsreglas

"Ille Corvus" escribió en el mensaje news:

http://www.hispamp3.com/noticias/no...hp?noticia 031104122708

A mi me suena a Palladium...


Ille Corvus. Res, non verba.
"Cave canem..."

"Ille Corvus" wrote in message
news:

http://www.hispamp3.com/noticias/no...hp?noticia 031104122708

A mi me suena a Palladium...

Pues a mi me suena más bien a algo tipo esto:

http://barrapunto.com/comments.pl?s...730#232770

Es decir, intentar que la sección de "datos" no sea ejecutable, con ello
impides - o dificultas - los buffers overflow. Lo que pasa que esta
caractaristica tal cual es muy dificil de implementar con un hardware que
ayuda tan poco a tal fin como el de Intel, por eso lo de la ayuda de Intel y
AMD.

Que alguien me corrija si me equivoco, pero vamos, que de Palladium nada
de nada de hecho el OpenBSD ha hecho lo mismo...

El Wed, 5 Nov 2003 08:30:23 +0100, "Tako" escribio:

Es decir, intentar que la sección de "datos" no sea ejecutable, con ello
impides - o dificultas - los buffers overflow. Lo que pasa que esta
caractaristica tal cual es muy dificil de implementar con un hardware que
ayuda tan poco a tal fin como el de Intel, por eso lo de la ayuda de Intel y
AMD.

Antes de nada habra que decir que es el "stack buffer overflow"
(creo que esto es mas correcto que buffer overflow), pondre un ejemplo
lo mas sencillo posible para que todos lo entendamos:

Un programador hace un programa y crea un campo llamado [Nombre] y
reserva 10 caracteres como maximo, se pone el mismo a probarlo y
funciona perfectamente, pero cuando se lo da a los usuarios para que
trabajen con el hay nombres mas largo de 10, al intentar introducir
los datos (en el momento de pulsar Enter o confirmar con el raton), en
el "buffer" hay mas de 10 caracteres y booommm!!! error de buffer
overflow (es decir desbordamiento del buffer).

Para los no programadores decir que un "buffer" es un espacio en
memoria donde se almacenan temporalmente los datos.

Ejemplo en 'C'

int main(int argc, char *argv[])
{
char array1[5] = "aaaa\0";
char array2[5];

puts (array1);
strcpy (array2, "BUFFER_OVERFLOW"); //<-- ***OJO A ESTO***
puts (array1);

exit(0);
}
-

Si ejecutamos esto veremos que el segundo (puts(array1)) la salida
es "BUFF", en el (strcpy) el texto origen es mas largo que el destino
(array2), por lo que hemos empezado a sobreescribir posiciones de
memoria (array1), y solo es cuestion de tiempo que haga booommm!!!
(otra vez).

Porque ocurre esto, normalmente es responsabilidad del programador
comprobar todo esto, pero las prisas, presiones del Jefe, etc hacen
que no se prueben debidamente, entre otras cuestiones.

Como solucionarlo, bueno existen soluciones como por ejemplo hacer
que los compiladores añadieran instrucciones adicionales para
comprobar que la escritura en la memoria es la adecuada, pero esto
tiene un problema seria demasiado lento.

Otra solucion es que el sistema operativo no permita la ejecucion de
datos en la pila (mas tecnicismos), y que el compilador pudiera
incluir un dato especial llamado "canario" (argot tecnico) revisando
la integridad del mismo antes de salir de la rutina/subrutina/etc, si
el canario "canta" (es decir se ha modificado) se deberia detener la
ejecucion de esa rutina/subrutina/etc...

Todos estos problemas tienen relacion con la arquitectura donde esta
alojado el sistema operativo en este caso Intel (Pentium, i386, etc),
y tambien de los compiladores...aunque existen alternativas muy
validas como Cyclone y Eiffel, que evitan dentro de lo posible estos
errores tan prehistoricos (desde el inicio de la informatica mas o
menos).

En sistemas como Unix/Linux/BSD existe un comando llamado "chroot",
el cual crea una especie de zona reservada para la ejecucion de un
programa concreto le asigna un directorio, y un espacio de memoria,
por lo que si un usuario/hacker/cracker explota el programa solo
tendra acceso a esa zona de memoria y/o directorio...siempre y cuando
el programa en ejecucion lo permita, por ejemplo Apache para que
funcionara de esa manera habria que introducir "pequeñas"
modificaciones en el codigo...

Que alguien me corrija si me equivoco, pero vamos, que de Palladium nada
de nada de hecho el OpenBSD ha hecho lo mismo...

Digo Palladium como DRM (me parece que se escribe asi), con la
excusa de "..." lo van a implantar, y como no tenemos el codigo
fuente, habra que esperar la "implantacion" del software+hardware,
para poder verlo.

Para mas informacion en castellano sobre el OpenBSD en este enlace
http://www.openbsd.org/es/.




Ille Corvus. Res, non verba.
"Cave canem..."