Buffer Overflow in UDP broadcasts for Microsoft S

  • forwarded for your information !

    --------------------------------

    Buffer Overflow in UDP broadcasts for Microsoft SQL Server client

    utilities

    Risk level: High

    Summary:

    A Unicode buffer overflow exists in MDAC which is used by the SQL Server

    SQL-DMO library that could allow a remote user to execute malicious code

    on the target computer. The vulnerability does not occur when accepting

    incoming connections, but rather in the response to broadcast queries.

    Details:

    One of the features of the SQL Server network libraries is the ability

    to query a list of SQL Servers on the local network. This is

    accomplished by sending a UDP broadcast on port 1434 which will reach

    all applications on the local subnet. This function is a component of

    SQL-DMO which is used by the SQL Server Service Manager (whenever it is

    started), Enterprise Manager (when registering a server), Query Analyzer

    and SQL Profiler (when clicking "..." button), DTS (when selecting a SQL

    Server), etc...

    All SQL Servers receiving the broadcast request respond with a standard

    UDP packet. If a malicious machine responds to this broadcast with an

    overlong packet a stack buffer overflow occur. The overflow occurs in a

    UNICODE string, so the Venetian method of performing a buffer overflow

    would

    need to be used to exploit this vulnerability. There is a white paper

    from Chris Ansley on how this is done, as well as a presentation from

    Dave Aitel.

    Any SQL Server utilities that use the SQL-DMO function to retrieve a

    list of SQL Servers will be vulnerable to this attack. An attack is not

    mounted directly against the target. Instead an attacker could attempt

    several methods of exploiting the vulnerability:

    1) Setup a service listening for data on UDP port 1434 and responding

    with the attack payload whenever data is received. This network would

    require being on the same subnet.

    2) Bombarding a remote subnet with UDP attack packets waiting for

    someone to query the network. For example, send the attack packet every

    2 seconds to 192.168.3.255 will reach all machines on the 192.168.3.x

    subnet. When someone finally does send a UDP broadcast, they will accept

    this packet and be exploited. This method would take a bit of luck,

    persistence, or some social engineering.

    3) It may also be possible for a non-privileged login in MS SQL to cause

    the SQL Server to send out a query request directly to an IP Address on

    the network. The following SQL statement causes the SQL Server to query

    a host named SERVER with a UDP packet:

    SELECT * FROM openrowset( 'SQLOLEDB', 'server=SERVER\instance

    name;uid=sa;pwd=', '')

    However, on our systems, we were unable to trigger the overflow from the

    response. There may be other methods to cause the SQL Server to send the

    UDP query and trigger the overflow.

    One of the features of SQL Server which makes this vulnerability simpler

    to exploit is that the SQL Server Service Manager queries the network

    using SQL-DMO every time it starts which happens when a user with the

    SQL Server client utilities logs into Windows. This would occur anytime

    someone logged into the Windows server on which SQL Server is installed,

    or anytime a database administrator logs into his or her machine.

    Links:

    http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0353

    http://www.microsoft.com/ technet/security/bulletin/MS03-033.asp

    Fix:

    This vulnerability affects the following packages:

    Microsoft Data Access Components 2.7 SP1

    Microsoft Data Access Components 2.7

    Microsoft Data Access Components 2.6 SP2

    Microsoft Data Access Components 2.5 SP3

    Microsoft Data Access Components 2.5 SP2

    If you have one of these packages installed, apply the hot fix from

    http://support.microsoft.com/default.aspx?scid=kb;en-us;823718.

    Acknowledgement:

    Thanks to Cesar Cerrudo for researching this vulnerability!

    Thank you,

    support@appsecinc.com

    Application Security, Inc.

    phone: 212-420-9270

    fax: 212-420-9680

    Cheers,

    Frank

    --
    Frank Kalis
    Microsoft SQL Server MVP
    Webmaster: http://www.insidesql.org/blogs
    My blog: http://www.insidesql.org/blogs/frankkalis/[/url]

  • http://support.microsoft.com/default.aspx?scid=kb;en-us;823718

    without the trailing period will get you there. Thx.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply