C2.3 CVE Entries

These are the entries released since October 2005. Earlier vulnerabilities can be found in previous editions of the SANS vulnerabilities lists. In many cases reported issues are not flaws in the databases themselves but in applications build around them, e.g. SQL injection into web interfaces; these have not been included here.

Oracle

CVE-2005-3641, CVE-2006-0256, CVE-2006-0257, CVE-2006-0258, CVE-2006-0259, CVE-2006-0260, CVE-2006-0261, CVE-2006-0262, CVE-2006-0263, CVE-2006-0265, CVE-2006-0266, CVE-2006-0267, CVE-2006-0268, CVE-2006-0269, CVE-2006-0270, CVE-2006-0271, CVE-2006-0272, CVE-2006-0282, CVE-2006-0283, CVE-2006-0285, CVE-2006-0286, CVE-2006-0287, CVE-2006-0290, CVE-2006-0291, CVE-2006-0435, CVE-2006-0547, CVE-2006-0548, CVE-2006-0549, CVE-2006-0551, CVE-2006-0552, CVE-2006-0586, CVE-2006-1868, CVE-2006-1871, CVE-2006-1872, CVE-2006-1873, CVE-2006-1874, CVE-2006-3698.

Note: This list concentrates on the core Oracle database programs. There are vulnerabilities in other applications that form part of the Oracle suite. Oracle releases quarterly Critical Patch Updates (CPU) covering large numbers of issues in the databases and associated applications. The general advice is to work through these CPUs. Due to the way Oracle released information during this reporting period multiple CVE entries may be reporting a single issue.

MySQL

CVE-2006-2753.

PostgreSQL

CVE-2006-2313, CVE-2006-2314.

IBM DB2

CVE-2005-3643, CVE-2005-4737.

IBM Informix

CVE-2005-3642, CVE-2006-3854, CVE-2006-3860, CVE-2006-3862.

Microsoft SQL Server

None during this reporting period.

Sybase

None during this reporting period.

C2.4 How to Determine If You Are Vulnerable

It is not sufficient to check a simple, manually maintained list of the applications that have been installed! Because databases are often distributed as components of other applications, it is possible for a database to have been installed without administrators realizing it. Databases may therefore remain unpatched or in vulnerable default configurations. This was graphically demonstrated when the SQL Slammer worm attacked the Microsoft Data Access Component (MDAC), which is included in many applications.

Perform a vulnerability scan on systems to determine whether DBMS software is available, accessible and vulnerable. You can use general vulnerability scanners or tools from database vendors such as MySQL Network Scanner, Microsoft SQL server tool. The Microsoft Baseline Security Analyzer is also of use for Microsoft SQL Server

C2.5 How to Protect Against Database Vulnerabilities

• Ensure that all DBMS are patched up to date. Unpatched or outdated versions are likely include vulnerabilities. Check vendor sites for patch information. Remain up to date with the vulnerabilities and alerts announced by the vendors:
  
  
  
  • Oracle Security Alerts (http://www.oracle.com/technology/deploy/security/alerts.htm )
  
  
  • MySQL (http://lists.mysql.com/)
  
  
  • PostgreSQL (http://www.postgresql.org/community/)
  
  
  • Microsoft SQL (http://www.microsoft.com/technet/security/bulletin/notify.mspx)
  
  
  • IBM DB2 (http://www-306.ibm.com/software/data/db2/udb/support/)
  
  
  • IBM Informix (http://www-1.ibm.com/support/docview.wss?rs=0&uid=swg24009130)
  
  



• 
  Ensure that the DBMS and applications have been secured:
  
  • Remove/change default passwords on the database's privileged and system accounts before deploying the system on the network. Lists of default accounts are readily available on the Internet.
  
  
  • Use minimal privileges.
  
  
  • Use stored procedures where possible.
  
  
  • Remove/disable unnecessary stored procedures.
  
  
  • Set length limits on any form fields.
  
  
  • See the references section below for several useful resources to help secure DBMS.
  
  
  
  


• Use firewalls or other network security devices to restrict network access to the ports associated with database services.



• Do not trust user input! Ensure that the applications linked to databases clean all user input at the server side to avoid attacks such as SQL injection (see http://www.sans.org/rr/whitepapers/securecode/23.php)