¿Cuál es el
alcance de esta vulnerabilidad?
¿Qué vulnerabilidades corrige esta revisión de
seguridad?
Una vez aplicada, esta revisión
acumulativa soluciona todas las vulnerabilidades previamente identificadas en
SQL Server. Además, elimina tres nuevas vulnerabilidades.
Una vulnerabilidad a través de la
cual un usuario autenticado con acceso físico a SQL Server podría obtener
privilegios adicionales en el sistema.
Una vulnerabilidad que permitiría
a un atacante producir una situación de denegación de servicio en el sistema.
Una
vulnerabilidad a través de la cual un usuario autenticado con privilegios de
acceso al sistema podría potencialmente ejecutar un programa o elevar sus
privilegios en el sistema hasta el mismo nivel que los de la cuenta de SQL
Service.
¿Se trata de una revisión acumulativa?
Esta revisión reemplaza todas las
revisiones de seguridad publicadas hasta la fecha que afectaban a los motores de
base de datos de SQL Server 7.0 y SQL Server 2000. No obstante, la aplicación de
esta revisión de seguridad no basta para proteger totalmente a SQL Server:
Una corrección de seguridad para
SQL Server 2000, que se describe en el boletín de seguridad
MS02-035 de Microsoft,
requiere una solución por medio de una herramienta en lugar de una revisión.
La herramienta sólo debe ejecutarse una vez. Así pues, los clientes que ya la
han ejecutado no deberán realizar ningún acción más. Sin embargo, la
instalación de esta revisión no implica que la herramienta se ejecute.
La revisión de seguridad no
incluye ninguna corrección para las vulnerabilidades de seguridad que afectan
a las tecnologías Microsoft Data Access Components (MDAC) u Online Analytic
Processing (OLAP) de SQL Server. Las revisiones de seguridad para estos
problemas (que se listan en la sección Advertencias) deben aplicarse por
separado.
La sección Versiones afectadas indica que Microsoft
Desktop Engine (MSDE) también está afectado por estas vulnerabilidades. ¿Qué es
MSDE?
Microsoft Desktop Engine (MSDE) es un motor de base de datos desarrollado y
basado en la tecnología SQL Server que se suministra como parte de varios
productos de Microsoft, incluidos Microsoft Visual Studio y Microsoft Office
Developer Edition. Existe una conexión directa entre las versiones de MSDE y las
versiones de SQL Server. MSDE 1.0 se basa en SQL Server 7.0; MSDE 2000 se basa
en SQL Server 2000. Para ver una lista completa de los productos que se
suministran con MSDE, consulte
www.microsoft.com/technet/security/MSDEapps.asp
¿Se suministra Microsoft Desktop
Engine con alguna versión de Windows?
Sí.
Microsoft Desktop Engine (MSDE) se incluye en Windows Server 2003 para
proporcionar compatibilidad con
Universal Description, Discovery, and Integration
(UDDI). Se denomina SQL Server 2000 Desktop Engine
(Windows).
Ninguna versión más de Windows incorpora MSDE.
¿Está instalado SQL Server 2000
Desktop Engine (Windows) de forma predeterminada en Windows Server 2003?
No. Solamente está presente en las
instalaciones de Windows Server 2003 que están configuradas para admitir UDDI.
¿Qué es UDDI?
Universal Description, Discovery, and Integration (UDDI) es un registro
basado en XML para que las empresas de todo el mundo puedan listarse en
Internet. Su objetivo final consiste en agilizar las transacciones en línea para
permitir que las empresas se encuentren unas a otras en el Web y para que sus
sistemas sean interoperativos para el comercio electrónico.
¿Está disponible esta revisión de
seguridad en Windows Update para todas las plataformas compatibles aparte de
Windows Server 2003?
No. SQL Server 2000 Desktop Engine
(Windows) no se incluye con ninguna otra versión de Microsoft Windows aparte de
Windows Server 2003. Así pues, esta actualización sólo estará disponible en
Windows Update para las instalaciones de Windows Server 2003 que están
configuradas para admitir UDDI.
¿Cómo puedo saber si MSDE o SQL Server 2000 están
instalados en mi sistema?
Vaya a "Inicio", seleccione "Buscar"
y busque el archivo "sqlservr.exe" en el sistema local. Si este archivo está
presente en el sistema, significa que MSDE o SQL Server está instalado.
La revisión de seguridad de SQL
Server 2000 sólo puede instalarse en SP3a. ¿Qué debo hacer si estoy utilizando
SP2 o una versión anterior?
Puesto que los service packs de SQL Server son
acumulativos, SP3a incluye todas las
correcciones de los Service Pack 1 (SP1),
Service Pack 2 (SP2) y Service Pack 3
(SP3) publicados previamente. SP3a
puede aplicarse a una instalación original o a una instalación en la que SP1,
SP2 o SP3 haya sido aplicado. Las versiones anteriores de Service Pack ya no
están admitidas. Para obtener más información acerca de los ciclos de
compatibilidad, consulte {Arvind is
getting this info as approved by LCA right now}
SP3 ya está instalado en mi máquina.
¿Significa esto que debo actualizar a SP3a?
Si ya ha aplicado SP3, no es
necesario que instale SP3a. SP3a va dirigido únicamente a los usuarios de SQL
Server que no han aplicado ninguna versión de SP3. Sin embargo, es preferible
que a partir de ahora utilice SP3a en lugar de SP3. Para obtener más información
acerca de SP3a, consulte
www.microsoft.com/sql/downloads/2000/sp3.asp
¿Incluye esta revisión alguna corrección más?
Sí. Esta revisión incluye un cambio
de comportamiento en la configuración de la contraseña de la cuenta SA. Tras
aplicar esta revisión de seguridad, un usuario que deliberadamente intente
establecer la contraseña de la cuenta SA en “vacía” recibirá una advertencia de
seguridad. Además, si el protocolo de canalizaciones con nombre se ha
deshabilitado antes de aplicar esta revisión de seguridad, los usuarios
observarán los siguientes tres cambios:
Console.exe
no podrá conectarse a SQL Server.
Se producirá un error en todos los
trabajos de SQL Agent que requieran el montaje de una cinta.
Se producirán errores en las
copias de seguridad a la canalización antes de intentar conectarse a la
canalización.
El artículo
818806 publicado por
Microsoft en Knowledge Base contiene más información acerca de este cambio.
Secuestro de la canalización con nombre:
¿Cuál es el alcance de esta vulnerabilidad?
Se trata una vulnerabilidad de
elevación de
privilegio. Esto permitiría a un atacante obtener el control de la
canalización con nombre en el mismo nivel de privilegios que el usuario que
intenta la conexión.
Si los derechos de acceso del
usuario que se conecta remotamente son más elevados que los del atacante, éste
último podría hacer uso de estos derechos cuando la canalización con nombre
estuviera en peligro.
Para poder aprovechar esta
vulnerabilidad, un atacante debería iniciar la sesión de forma local en el
sistema SQL Server en el momento en que la canalización con nombre intentara la
conexión.
¿Cuál es la causa de esta
vulnerabilidad?
Esta vulnerabilidad se produce
porque existe un defecto en el método de comprobación que SQL Server utiliza
cuando un cliente establece un inicio de sesión autenticado por medio de una
canalización con nombre.
Este defecto podría permitir a un
atacante “secuestrar” u controlar la canalización y adquirir el mismo nivel de
acceso que el usuario autenticado.
¿Qué es una canalización con nombre?
Una canalización es un
área de la memoria compartida por dos o más procesos que permite la comunicación
entre estos procesos. Cuando el Proceso A quiere comunicarse con el Proceso B
coloca los datos en la memoria compartida y establece un indicador de semáforo
indicando al Proceso B que lea los datos.
Existen dos tipos de canalizaciones:
Canalizaciones anónimas, que
permiten la comunicación unidireccional desde un proceso superior a uno
subordinado. Sólo existen localmente.
Canalizaciones con nombre, que
permiten la comunicación bidireccional entre múltiples procesos. Los procesos
pueden residir en distintos sistemas.
¿Qué problema existe en la forma en
que SQL Server valida las canalizaciones con nombre?
SQL Server crea una canalización con
nombre y la escucha durante el inicio. Cualquier usuario puede conectarse a esta
canalización y el servidor determina los intentos de conexión que pueden o no
iniciar sesión.
¿Qué podría hacer un atacante que
aprovechara esta vulnerabilidad?
Si un atacante consigue aprovechar
con éxito esta vulnerabilidad obtendría acceso a la información y a los datos en
el mismo nivel de privilegio que el usuario autenticado que se conecta a través
de la canalización. Si el usuario tiene privilegios administrativos, el atacante
también adquiriría los mismos privilegios en la base de datos.
¿Cómo podría aprovechar un atacante
esta vulnerabilidad?
Un atacante (un usuario con pocos
privilegios) que iniciara la sesión en un sistema SQL Server podría aprovechar
esta vulnerabilidad creando la misma canalización con nombre utilizada por SQL
Server.
Si un cliente está conectado a SQL
Server a través de una canalización con nombre y utiliza la Autenticación de
Windows, el atacante podría secuestrar la canalización con nombre y adquirir el
mismo nivel de privilegios sobre la base de datos que el usuario conectado.
¿Los atacantes están supeditados a
algún tipo de limitación cuando efectúan este ataque?
Sí. Los atacantes deberían iniciar
la sesión
interactivamente en el sistema SQL Server para poder aprovechar esta
vulnerabilidad.
¿Cómo funciona esta revisión de
seguridad?
La revisión de seguridad corrige
esta vulnerabilidad limitando la creación de canalizaciones con nombre sólo para
el proceso de SQL Server
Denegación de
servicio de la canalización con nombre:
¿Cuál es el alcance de esta
vulnerabilidad?
Se trata de una vulnerabilidad de
denegación de servicio que podría hacer que SQL Server se
colgara o dejara de responder.
Para aprovechar con éxito este
defecto, un atacante debería tener acceso a la intranet local, aunque no es
necesario que se autentique en el domino.
No existe forma alguna de que un
atacante malintencionado utilice esta vulnerabilidad para conseguir el control
del sistema u obtener acceso a cualquier información del servidor. Para
recuperar el funcionamiento normal basta con reiniciar SQL Service.
¿Cuál es la causa de esta
vulnerabilidad?
Esta vulnerabilidad existe debido a
un defecto en la forma en que SQL interpreta un código de retorno de una
operación específica de las canalizaciones con nombre. Si se reciben más datos
de los esperados, SQL interpreta incorrectamente el código de retorno válido
como un error, lo que provoca que el sistema deje de responder.
¿Qué podría hacer un atacante que
aprovechara esta vulnerabilidad?
Si un atacante consiguiera explotar
con éxito este punto vulnerable, podría interrumpir el funcionamiento normal de
SQL Server haciendo que se colgara o dejara de responder.
Este comportamiento sólo afectaría
al sistema temporalmente y desaparecería al reiniciar SQL Service.
¿Cómo podría aprovechar un atacante
esta vulnerabilidad?
Un atacante con acceso a la intranet
local podría aprovechar este punto vulnerable creando un paquete muy grande
especialmente diseñado y enviándolo a la canalización con nombre en la que SQL
Server está escuchando.
Esto provocaría que el servidor se
colgara o dejara de responder y sería preciso reiniciarlo para recuperar el
funcionamiento normal.
¿Por qué necesitaría un atacante
obtener acceso a la Intranet local para aprovechar este punto vulnerable?
Un atacante tendría que obtener
acceso a un dominio que contara con la confianza del dominio de SQL Server. A
continuación, debería abrir una canalización con nombre de un SQL Server
determinado para crear una conexión y, seguidamente, enviar el paquete
especialmente diseñado a través de la conexión establecida.
¿Cómo funciona esta revisión de
seguridad?
La revisión de seguridad limita la
cantidad de datos que SQL Server puede leer a la cantidad establecida por el
búfer.
Saturación del
búfer de SQL Server:
¿Cuál es el alcance de esta
vulnerabilidad?
Se trata de una vulnerabilidad de
saturación del búfer. Un atacante que aprovechase con éxito esta
vulnerabilidad podría provocar un fallo en el sistema o podría ejecutar el
código que quisiera con los mismos privilegios que los de la cuenta de SQL
Service.
El código que se ejecuta con
privilegios de cuenta de servicio permitiría a un atacante tomar el control
total de una base de datos y de los datos contenidos en ella.
Solamente los atacantes con las
credenciales válidas para iniciar la sesión interactivamente en el sistema
pueden aprovechar este punto vulnerable.
¿Cuál es la causa de esta
vulnerabilidad?
Existe una vulnerabilidad debido a
un defecto en la forma en que SQL Server valida las solicitudes enviadas al
puerto LPC en el que escucha.
Puesto que LPC solamente se puede
utilizar en la máquina local, esta vulnerabilidad no puede aprovecharse
remotamente. Así pues, un atacante sólo puede aprovechar este punto vulnerable
en las máquinas en las que pudiera iniciar la sesión interactivamente. Por lo
general, este problema afecta directamente a las estaciones de trabajo y a los
servidores de terminal ya que, si se han puesto en práctica las medidas de
seguridad normales, los usuarios no tienen permiso para iniciar la sesión
remotamente en los servidores más importantes.
¿Qué es LPC?
LPC (Llamada a procedimiento local)
es un servicio de mensajería suministrado por Windows NT 4.0, Windows 2000 y
Windows Server 2003 que permite a los subprocesos y procesos comunicarse entre
sí. Cada vez que un proceso cliente debe solicitar los servicios de un proceso
del servidor, debe existir un medio para que los dos procesos se comuniquen
entre sí, es decir, debe existir un mecanismo para que el proceso cliente pueda
realizar las solicitudes al servidor, para que el servidor envíe las respuestas
al cliente y para que ambos puedan determinar su estado. Cuando los procesos
cliente y servidor se encuentran en distintas máquinas, se utiliza RPC (Llamada
a procedimiento remoto). Cuando residen en la misma máquina puede utilizarse LPC
.
La ventaja de utilizar LPC es su
rapidez. Puesto que los procesos están en la misma máquina es posible
incrementar el rendimiento para acelerar la velocidad de las comunicaciones. Por
ejemplo, en LPC los dos procesos pueden comunicarse por medio de un segmento de
memoria compartido. En lugar de pasarse los mensajes entre sí, un proceso coloca
un mensaje en el segmento compartido y envía una señal al otro proceso, que lee
el mensaje desde el segmento compartido.
¿Qué son los puertos LPC?
Cada LPC dispone de un conjunto de
canales de comunicación denominados puertos LPC. Por cada puerto fluye un tipo
de comunicación. Por ejemplo, un LPC siempre tiene un puerto que se utiliza para
permitir que un cliente envíe mensajes al servidor, otro puerto para que el
servidor pueda enviar los mensajes a cada cliente, así como otros puertos que,
por ejemplo, permiten que los subprocesos de un proceso coordinen sus
solicitudes.
¿Qué problema existe en la forma en
que SQL Server valida las solicitudes LPC?
SQL Server no valida correctamente
ciertos tipos de solicitudes realizadas al puerto LPC en el que escucha. En
consecuencia, sería posible enviar un paquete especialmente diseñado a un puerto
LPC y provocar una saturación del búfer.
¿Qué podría hacer un atacante que
aprovechara esta vulnerabilidad?
Si un atacante consigue aprovechar
con éxito esta vulnerabilidad, podría ejecutar código en el sistema con los
privilegios de la cuenta del servicio SQL.
El código que se ejecuta con
privilegios de cuenta de servicio permitiría a un atacante tomar el control
total de una base de datos y de los datos contenidos en ella.
¿Cómo podría aprovechar un atacante
esta vulnerabilidad?
Un atacante con privilegios para
iniciar la sesión interactivamente en el sistema SQL podría aprovechar esta
vulnerabilidad creando un paquete especialmente grande que, una vez enviado al
puerto de escucha del sistema, podría provocar un desbordamiento del búfer.
¿Cómo funciona esta revisión de
seguridad?
La revisión de seguridad limita la cantidad de
datos que SQL Server puede leer a la cantidad establecida por el búfer.
