TechNet Home >  Security >  Bulletins

   Microsoft Security Bulletin MS02-040
                                                              [Print] Print

  Unchecked Buffer in MDAC Function Could Enable SQL Server Compromise
  (Q326573)

  Originally posted: July 31, 2002

  Summary

       Who should read this bulletin: Database administrators using
       Microsoft® SQL Server™ 7.0 or 2000.

       Impact of vulnerability: Run code of the attacker’s choice.

       Maximum Severity Rating: Moderate

       Recommendation: Database administrators should consider
       installing the patch.

       Affected Software:

          * Microsoft Data Access Components 2.5
          * Microsoft Data Access Components 2.6
          * Microsoft Data Access Components 2.7

  Technical details

       Technical description:

       The Microsoft Data Access Components (MDAC) provide a number of
       supporting technologies for accessing and using databases.
       Included among these functions is the underlying support for the
       T-SQL OpenRowSet command. A security vulnerability results
       because the MDAC functions underlying OpenRowSet contain an
       unchecked buffer.

       An attacker who submitted a database query containing a specially
       malformed parameter within a call to OpenRowSet could overrun the
       buffer, either for the purpose of causing the SQL Server to fail
       or causing the SQL Server service to take actions dictated by the
       attacker.

       Mitigating factors:

          * In order to exploit the vulnerability, the attacker would
            need the ability to load and execute a database query on the
            server. This is strongly discouraged by best practices, and
            servers that have been configured to prevent this (e.g.,
            through the use of the DisallowAdhocAccess registry setting,
            as discussed in the FAQ) would not be at risk from the
            vulnerability.
          * Under default conditions, the system-level privileges gained
            through a successful attack would be those of a Domain User.
          * Even though MDAC ships as part of all versions of Windows,
            the vulnerability can only be exploited on SQL Servers.
            Customers who are not using SQL Server do not need to take
            action, despite the fact that MDAC may be installed on their
            systems.

       Severity Rating:
                 Internet Servers  Intranet Servers Client Systems

        MDAC 2.5 Moderate          Moderate         None

        MDAC 2.6 Moderate          Moderate         None

        MDAC 2.7 Moderate          Moderate         None
       The above assessment is based on the types of systems affected by
       the vulnerability, their typical deployment patterns, and the
       effect that exploiting the vulnerability would have on them. The
       vulnerability could only be exploited by an attacker who already
       had gained the ability to submit and execute chosen database
       queries.

       Vulnerability identifier: CVE-CAN-2002-0695

       Tested Versions:
       Microsoft tested MDAC 2.5, 2.6 and 2.7 to assess whether they are
       affected by these vulnerabilities. Previous versions are no
       longer supported, and may or may not be affected by these
       vulnerabilities.

  Frequently asked questions

       What’s the scope of this vulnerability?

       This is a buffer overrun vulnerability. An attacker who
       successfully exploited it would be able to take action with all
       the privileges of an affected SQL Server. At a minimum, this
       would grant the attacker complete control over the database, and
       potentially could grant administrative privileges at the
       operating system level as well.

       Although the technology involved in the vulnerability does ship
       as part of Windows and other products, the vulnerability only
       poses a risk to SQL Servers – no other systems require the patch.
       Even in the case of SQL Server, the vulnerability could only be
       exploited by an attacker who had the ability to submit and
       execute database queries against an affected server. Best
       practices strongly recommend against ever allowing untrusted
       users to do this.

       What causes the vulnerability?

       The vulnerability results because a function in the Microsoft
       Data Access Components that provides some of the underlying
       functionality for the Transact-SQL OpenRowSet command contains an
       unchecked buffer. If a query called OpenRowSet using a specially
       malformed parameter, it could be possible to overrun the buffer
       in the underlying function.

       What is Microsoft Data Access Components?

       Microsoft Data Access Components (MDAC) is a collection of
       components used to provide database connectivity on Windows
       platforms. The components provide the underlying functionality
       for a number of database operations. (A good discussion of MDAC
       and the components it provides is available on MSDN).

       One point that’s especially important to understand for the
       purposes of this vulnerability is the fact that MDAC is a
       collective name for a number of technologies, some of which are
       used by database clients and others of which are used by database
       servers. In this case, the component containing the flaw is one
       that’s used only by SQL Server, and even then can only be
       exploited through the use of a single Transact-SQL command,
       called OpenRowSet.

       What is the Transact-SQL OpenRowSet command?

       Transact-SQL (also known at T-SQL) is the language that Microsoft
       SQL Server uses to query and manipulate the database information.
       This allows a broad variety of applications, from web-based
       applications to ones based on C++, Java or other language to
       interrogate SQL Server databases. Among the commands available in
       T-SQL is OpenRowSet, which allows a program to connect to a
       selected data source and potentially execute a query against it.

       What’s wrong with the OpenRowSet command?

       There’s nothing wrong with the OpenRowSet command per se.
       However, the underlying technology that MDAC provides to support
       the command has an unchecked buffer. If an application called
       OpenRowSet and provided an extremely long value for a particular
       one of the parameters, it could overrun the buffer.

       What could an attacker do via the vulnerability?

       It would depend on the specific way the attacker overran the
       buffer. If the attacker provided input data that overran the
       buffer with random data, it would cause the attacker’s connection
       to the SQL Server to be dropped; this would not pose a security
       risk to the server. On the other hand, if the attacker carefully
       selected the data, it would be possible to modify MDAC’s
       functionality to perform any task the attacker specified.

       What privileges would the attacker gain through the latter
       scenario?

       The attacker would gain the ability to do anything MDAC could do.
       At a minimum, this would enable the attacker to take any desired
       action on the database, including adding, deleting or modifying
       data. But it would likely not provide similar privileges over the
       system at larger. Both SQL Server 7.0 and 2000 run by default
       with Domain User privileges rather than as part of the operating
       system.

       Who could exploit the vulnerability?

       In order to exploit the vulnerability, the attacker would need
       the ability to create and submit data queries. Best practices
       strongly recommend against ever allowing untrusted users to do
       this. For instance, in this case, the administrator would need to
       have granted untrusted users the ability to open and work
       directly with databases on the server. Clearly, it’s unwise to do
       this, even in the absence of this vulnerability.

       Is there a way to ensure that users can’t submit OpenRowset
       queries?

       Yes. It’s often done by ensuring that users access the database
       only via a front-end application that limits what they can do.
       However, it’s also possible to simply block user-submitted
       queries containing the OpenRowset command by setting the
       DisallowAdhocAccess option to a non-zero value using the advanced
       sp_serveroption command.

       How do I know which version of the patch I need?

       There’s a patch for each supported version of MDAC. The following
       table shows which version of MDAC was supplied with various
       Microsoft products:
        Version of MDAC                     Shipped in...

           MDAC 2.5     Windows 2000, Office 2000 SR1 and later, SQL Server
                        7.0 Service Packs 2 and later

           MDAC 2.6     SQL Server 2000

           MDAC 2.7     Windows XP, Visual Studio .Net

       An alternative way to determine the version of MDAC you’re using
       is to consult the
       HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataAccess registry key.
       The FullInstallVer key provides a value of the form x.xx.yyyy.y,
       where x.xx is the version number (e.g., if the FullInstallVer
       value were 2.70.7713.0, it would mean that MDAC 2.7 is installed
       on the system).

       A final way to determine the version of MDAC is to right click on
       C:\Program Files\Common Files\System\ado\msado15.dll, select
       Properties, and then consult the Version information. The version
       information has the same format as that of the FullInstallVer
       value -- x.xx.yyyy.y, where x.xx is the version number.

       I see that MDAC shipped in various versions of Windows, as well
       as Office. Does this mean that anyone using those products needs
       the patch?

       No. MDAC ships with a number of products, but the function
       containing the vulnerability is only exposed on database servers.
       If you’re not operating a database server, you don’t need the
       patch, even if you’re using one of the products listed above.

       How does the patch eliminate the vulnerability?

       The patch institutes proper buffer handling in the function
       associated with the vulnerability.

  Patch availability

       Download locations for this patch

          * MDAC 2.5:
            http://www.microsoft.com/Downloads/Release.asp?ReleaseID=41076
          * MDAC 2.6:
            http://www.microsoft.com/Downloads/Release.asp?ReleaseID=41077
          * MDAC 2.7:
            http://www.microsoft.com/Downloads/Release.asp?ReleaseID=41072

  Additional information about this patch

       Installation platforms:

          * The MDAC 2.5 patch can be installed on systems using MDAC
            2.5 Service Pack 2.
          * The MDAC 2.6 patch can be installed on systems using MDAC
            2.6 Service Pack 2.
          * The MDAC 2.7 patch can be installed on systems using MDAC
            2.7 Gold.

       Inclusion in future service packs:
       The fix for this issue will be included in MDAC 2.5 Service Pack
       3, MDAC 2.6 Service Pack 3, and MDAC 2.7 Service Pack 1.

       Reboot needed: Yes

       Patch can be uninstalled: No

       Superseded patches: None.

       Verifying patch installation:
       MDAC 2.5:

          * To verify that the patch has been installed on the machine,
            confirm that the following registry key has been created on
            the machine:
            HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\DataAccess\Q323264.

       MDAC 2.6:

          * To verify that the patch has been installed on the machine,
            confirm that the following registry key has been created on
            the machine:
            HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\DataAccess\Q323266.

       MDAC 2.7:

          * To verify that the patch has been installed on the machine,
            confirm that the following registry key has been created on
            the machine:
            HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\DataAccess\Q323263.

       Caveats:
       None

       Localization:
       Localized versions of this patch are available at the locations
       discussed in “Patch Availability”.

       Obtaining other security patches:
       Patches for other security issues are available from the
       following locations:

          * Security patches are available from the Microsoft Download
            Center, and can be most easily found by doing a keyword
            search for "security_patch".
          * Patches for consumer platforms are available from the
            WindowsUpdate web site

  Other information:

       Acknowledgments

       Microsoft thanks  David Litchfield of Next Generation Security
       Software Ltd. for reporting this issue to us and working with us
       to protect customers.

       Support:

          * Microsoft Knowledge Base article Q326573 discusses this
            issue and will be available approximately 24 hours after the
            release of this bulletin. Knowledge Base articles can be
            found on the Microsoft Online Support web site.
          * Technical support is available from Microsoft Product
             Support Services. There is no charge for support calls
            associated with security patches.

       Security Resources: The Microsoft TechNet Security Web Site
       provides additional information about security in Microsoft
       products.

       Disclaimer:
       The information provided in the Microsoft Knowledge Base is
       provided "as is" without warranty of any kind. Microsoft
       disclaims all warranties, either express or implied, including
       the warranties of merchantability and fitness for a particular
       purpose. In no event shall Microsoft Corporation or its suppliers
       be liable for any damages whatsoever including direct, indirect,
       incidental, consequential, loss of business profits or special
       damages, even if Microsoft Corporation or its suppliers have been
       advised of the possibility of such damages. Some states do not
       allow the exclusion or limitation of liability for consequential
       or incidental damages so the foregoing limitation may not apply.

       Revisions:

          * V1.0 (July 31, 2002): Bulletin Created.

  Contact Us   |   E-mail this Page   |   TechNet Newsletter

  © 2002 Microsoft Corporation. All rights reserved.     Terms of Use    Privacy Statement    Accessibility