Barrapunto

. . . estoy harto de tener que hacer estos cambios cada vez que me bajo un service pack, estoy harto de tener que actualizar el antivirus constántemente para que no me revienten el ordenador (y lo mismo pasa con el firewall), estoy harto de las incompatibilidades entre las versiones de Ms Office, estoy harto de . . .

Ah no mentira!! Si ya hace AÑOS que me pasé a Linux, no uso windows ;-)

Moriano

"Determinados programas de Windows podrían dejar de funcionar", mmm, eso depende de lo que se consideré funcionar en winblows.

Este es el encabezado de un mensaje en Slashdot que habia en el hilo sobre este tema.

Las modificaciones vienen de quitar el permiso de ejecución a las páginas de datos y la pila para dificultar los buffer overflow.

Los programas que necesitan este comportamiento son fundamentalmente JIT ( ej, Java, .NET y otros) y puede solucionarse con una simple llamada esta [slashdot.org].

La beta del SP2 está ya circulando por cualquiera que tenga una subscripción de la MSDN, y no se espera a que salga la versión definitiva hasta dentro de unos meses. Se han sacado multitud de papers en el site de Microsoft sobre estos temas, precisamente para que se puedan corregir estos fallos.

Al menos esa noticia corría por ahí: sin Java en Service Pack 2 para XP [error500.net].

No hay ninguna razón por la que no se puedan tener aplicaciones al estilo antiguo y nuevas simultáneamente.
Podría ponerse en el SO una opción para no permitir programas con datos+ejecución, así como permitir algún flag en la llamada de ejecución para que un programa en concreto se ejecutase obligatoriamente de dicha manera.

De esa forma, los programas ya preparados de serie podrían ser (más) seguros e incluso si alguien va a instalar un ordenador crítico forzar a que todo programa fuera de este tipo.

No van a implementar esa mejora para w2k?

Solo los programas mal construidos tendran problemas.

Os contaré una historia:

Yo trabaja como AP en el desarrollo de un programa que hace uso intensivo de DCOM. DCOM es una de las técnologias que sufre remodelaciones en este SP. Se que esta apliación ampliamente extendida va a tener problemas con el SP.

DCOM tiene un coplejo, probado y excelente sistema de seguridad que permite autentificar y autenticar cada llamada que se hace al servidor.

El problema es que el programador puede decidir desactivar este sistema, de manera que no se use esta seguridad y el servidor DCOM atienda peticiones vengan de quien vengan. Si añadimos que los servidores DCOM corren habitualmente como servicios con privilegios altos, el coctel es explosivo.

Os preguntareis por que yo como desarrollodor de ese programa y conocedor a priori de las pegas que esto tenia puse la linea que desactiva la seguridad. La respuesta es simple:

Mi jefe era un chapucero!!! No atendio a mis ruegos sobre la seguridad (y se trata de una empresa que hace productos de seguridad!!!) solo a que el tiempo de desarrollo seria mayor si se atendia a los requisitos de seguridad de DCOM.

Su solución fue... pues desactivamos la seguridad de DCOM y nos implementamos un sistema propio!!!! Y lo peor del caso es que sabiendo que era una chapuza me impuso esa solución.

Harto de cuestiones como esta cambie de empresa. Lo peor es que esto ocurra en empresas de seguridad!!!!!!!! ¿Que pasara en las otras!!!?

CONCLUSION: Ante cuestiones como estas MS ha decidido imponer la seguridad, algo que en mi opinion deberia haber ocurrido antes.

En primer lugar, dicen que las aplicaciones que dejen de funcionar serán aquellas en que los desarrolladores no hayan empleado "best practices" y aquellas que no se hayan diseñado con un modelo de seguridad robusto en mente, y que es responsabilidad de los desarrolladores hacer programas seguros.
Y luego admiten que dos productos de la casa, Visual Studio y el framework .NET necesitan parches.

Ergo, segun Microsoft, Visual Studio y el framework .NET no se han programado siguiendo best practices y son inseguros

Y ole!

#define WINVER 0x0400
#define _WIN32_WINNT 0x0400


#include <windows.h>

Con ese par de líneas cualquier programa que compile debería funcionar a partir de Windows 95.

Aunque lógicamente no se podrán usar las nuevas funcionalidades que han añadido a partir de esa versión.

Esto ha ocurrido en otras ocasiones con determinadas actualizaciones, seguro que no algo tan importante como en este caso pero ocurrir ha ocurrido. Por ejemplo, sé que el ACDSEE y algún otro programa como alguna aplicación del Powerquest Drive Image daban errores en la librería MPR.DLL tras instalar un parche de actualización, concretamente el KB824141. Esto dejaba dos opciones: o actualizabas la versión del programa, suponiendo que lo hubieran solucionado (en el caso del ACDSEE sí), o desinstalabas la actualización, con lo cual los programas volvían a funcionar.

saludos