0
Shares
0
0
0

Ayer día 8 de Julio y como segundo martes de cada mes, Microsoft publicó una serie de actualizaciones para sus productos. Entre ellos se encontraba una actualización de seguridad de un producto que pocas veces estamos acostumbrados a encontrar, SQL Server.

Dicha actualización se aplica no solo a SQL Server 2005 SP2, sino incluso a SQL Server 7 SP4 y SQL Server 2000 SP4. Corrige errores calificados como “importantes” dado que permiten la elevación de privilegios en función de la edición de SQL Server y el tipo de ataque entre estos:

  • Memory Page Reuse Vulnerability – CVE-2008-0085
  • Convert Buffer Overrun – CVE-2008-0086
  • SQL Server Memory Corruption Vulnerability – CVE-2008-0107
  • SQL Server Buffer Overrun Vulnerability – CVE-2008-0106

En el caso de SQL Server 2005, la actualización nos dejará el motor en el nº de versión 9.0.3068

El boletín oficial donde podéis encontrar la descripción técnica lo podéis leer aquí.

0 Shares:
Share 0
Tweet 0
Share 0

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

— Previous article

T-SQL de SQL Server 2008

Next article —

Cómo instalar Integration Services en un entorno cluster (Capítulo 1).

You May Also Like
AArtículos de Data
Leer más
  • 11 minute read

Data Masking de datos sensibles… piénsalo dos veces

Dynamic data masking (enmascaramiento) es una técnica que busca limitar/ocultar información sensible sin requerir cambios en las aplicaciones. Los datos en la base de datos realmente no se modifican, se alteran “al vuelo” de forma que cuando las consultas devuelven resultados se aplican las máscaras apropiadas. Esto hace que esta funcionalidad sea sencilla de implementar ya que no requiere cambios sustanciales y sea bastante transparente para las aplicaciones que utilizan los datos enmascarados.
AArtículos de Data
Leer más
  • 5 minute read

Lidiando con Power BI y los límites de Google Analytics

A la hora de realizar informes tirando consultas contra el API de Google Analytics nos encontramos que normalmente, ya sea por prisa o por límites presupuestarios, se hacen informes adhoc en Power BI en modo import, evitando una arquitectura de ETL más canónica, que implicaría por ejemplo, llevar los datos a tablas en SQL Server y realizar cargas incrementales para tener un repositorio centralizado de información. Esta arquitectura podría ser o en la nube o en hardware on-premise. Detallamos algunos problemas comunes al trabajar con Power BI y Google Analytics y algunas soluciones.