Comillas en la orden START del intérprete de comandos de Windows

Hace unos días me llamó la atención una consulta en el grupos de noticias de Windows XP sobre cómo ejecutar varios programas secuencialmente desde un archivo .BAT (procesamiento por lotes), de forma que la ejecución de cada programa se produzca sólo cuando termine el anterior. Otro compañero de los foros sugirió usar la orden START con el parámetro /WAIT, que es perfectamente válida para ese propósito.


Ejemplo:

start /wait programa1.exe
start /wait programa2.exe
start /wait programa3.exe

El usuario que inició aquel hilo agradeció la respuesta y la puso en práctica. Expuso en el grupo una posible solución que había desarrollado y se le hizo un comentario acerca de unas comillas sin texto entre el parámetro /WAIT y el programa a ejecutar, similares a las que se ven aquí:

start /wait “” “programa.exe”

Puesto que aún no encuentro inspiración para completar el desarrollo de otros asuntos que quiero tratar aquí y no deseo tener una sola entrada en este mes de julio de 2007 que ahora termina, reproduzco a continuación mi respuesta en el foro sobre el propósito de esas comillas. He unido los dos mensajes originales, he modificado el texto ligeramente y he añadido un poco de formato (negrita, ancho fijo, etc.).


Las primeras comillas son necesarias si también se encierra entre comillas la ubicación del archivo que se va a ejecutar. START interpreta el primer parámetro entrecomillado, excluyendo el que pueda suceder a la opción /D, como el título que va a asignar a la ventana de consola, no como la ubicación del archivo a ejecutar. Es obligatorio incluso si el programa no es de tipo consola (en ese caso carecerá de efecto). Si se elimina ese parámetro entrecomillado, el resultado no será el esperado.


Por tanto, estos ejemplos no son equivalentes:

START /WAIT “bah” “%programfiles%internet exploreriexplore.exe” -nohome
START /WAIT “%programfiles%internet exploreriexplore.exe” -nohome

La primera línea ejecuta Internet Explorer sin abrir la página de inicio. El texto entrecomillado “bah” es irrelevante, puesto que Iexplore.exe no es un programa de consola.


En la segunda línea, START interpreta “%programfiles%internet exploreriexplore.exe” como título de ventana y -nohome como archivo a ejecutar. Podéis imaginar el resultado. :-)


En cambio, estos ejemplos son equivalentes:

START “bah” /WAIT “%programfiles%internet exploreriexplore.exe” -nohome
START /WAIT “bah” “%programfiles%internet exploreriexplore.exe” -nohome

El orden del parámetro de título con respecto a las demás opciones no tiene importancia, teniendo cuidado en un caso: la opción /D y el argumento que le acompaña forman un todo (la opción /D, que no se usa habitualmente, permite definir el directorio inicial de la aplicación).


Finalmente, estos ejemplos tendrían el resultado esperado suponiendo que los archivos existieran:

START cmd.exe
START f:rutasinespaciosprogramasinespacios.exe
START “” cmd.exe
START “” f:rutasinespaciosprogramasinespacios.exe

Moraleja: si se pasa a START un parámetro de archivo que va entrecomillado, necesario si la ubicación o el nombre del archivo pueden contener espacios, hay que anteponer otro parámetro entrecomillado aunque sólo sean las comillas vacías.


Este asunto de las comillas puede acarrear problemas de interoperabilidad con plataformas basadas en Windows 9x (Windows 95/98/Millennium), ya que START está mucho más limitado. Si se utiliza START en un archivo .BAT destinado tanto a sistemas Windows NT (Windows NT/2000/XP/2003/Vista…) como a sistemas Windows 9x, conviene separar la ejecución en dos ramas según la variable de entorno OS: en sistemas Windows 9x no está definida, mientras que en sistemas NT vale Windows_NT.


Ejemplo:

if “%OS%” == “Windows_NT” goto nt
rem código específico para Windows 95/98/ME

goto :fin
:nt
rem código específico para Windows NT/2000/etc.

:fin

Otra solución consiste crear dos archivos .BAT, uno para los Windows 9x y el otro para los Windows NT, y mantener ambos por separado. Por supuesto, sería muy aconsejable comprobar al principio el valor de la variable OS para evitar problemas si se ejecuta accidentalmente alguno de los archivos .BAT en una plataforma distinta a la deseada.

Michael Howard acerca de la vulnerabilidad MS07-029

Acabo de leer una entrada interesante de Michael Howard en el blog del Security Development Lifecycle de Microsoft sobre la vulnerabilidad MS07-029, relativa al servidor DNS de las plataformas basadas en Windows Server. En ella se exponen los pormenores de la vulnerabilidad, cómo afecta a las distintas versiones de Windows Server, las defensas dispuestas para mitigar el problema y por qué los análisis del código y las pruebas de software no llegaron a descubrirlo.


Michael Howard es un experto de Microsoft en seguridad del software y coautor de varios libros sobre esta especialidad, como Writing Secure Code, Second Edition (Microsoft Press), 19 Deadly Sins of Software Security (McGraw Hill Professional), The Security Development Lifecycle (Microsoft Press) y Writing Secure Code for Windows Vista™ (Microsoft Press).


El artículo de Michael, cuyo título se podría traducir como “Lecciones aprendidas del boletín MS07-029: el desbordamiento de buffer en la interfaz RPC de DNS”, comienza describiendo los productos afectados. La vulnerabilidad se encuentra en el código del servidor DNS de Windows 2000 Server, Windows Server 2003 y compilaciones de Windows Server 2008, la próxima versión de Windows Server, anteriores a la Beta 3. Este problema no afecta, por tanto, a ediciones clientes como Windows 2000 Professional, Windows XP o Windows Vista, que incorporan únicamente funciones de cliente DNS.


El servidor DNS de las plataformas Windows Server no viene instalado de forma predeterminada, excepto en sistemas promocionados a controladores de dominio de Active Directory y sistemas basados en Small Business Server (que requieren ser configurados como controladores de dominio). Michael explica que el código vulnerable pertenece a una interfaz RPC destinada a la administración del servidor DNS, no al procesamiento general de peticiones DNS a través de los puertos 53 de TCP y UDP, y que la vulnerabilidad consiste en un desbordamiento de buffer sobre una estructura de tamaño fijo alojada en la pila.


Para más detalles véase la fuente, en inglés:
Lessons Learned from MS07-029: The DNS RPC Interface Buffer Overrun


Más información sobre el SDL:
El ciclo de vida de desarrollo de seguridad de Trustworthy Computing