Welcome to our website
To take full advantage of all features you need to login or register. Registration is completely free and takes only a few seconds.
SQL Extended Procedure Functions Contain Unchecked Buffers
Posted by Philipp Esselbach on: 04/18/2002 12:26 PM [ Print | 0 comment(s) ]
Microsoft has released a new security patch for SQL server
SQL Server 7.0 and 2000 provide for extended stored procedures, which are external routines written in a programming language such as C. These procedures appear to users as normal stored procedures and are executed in the same way. SQL Server 7.0 and 2000 include a number of extended stored procedures which are used for various helper functions
Several of the Microsoft-provided extended stored procedures have a flaw in common - namely, they fail to perform input validation correctly, and are susceptible to buffer overruns as a result exploiting the flaw could enable an attacker to either cause the SQL Server service to fail, or to cause code to run in the security context in which SQL Server is running. SQL Server can be configured to run in various security contexts, and by default runs as a domain user. The precise privileges the attacker could gain would depend on the specific security context that the service runs in.
An attacker could exploit this vulnerability in one of two ways. Firstly, the attacker could attempt to load and execute a database query that calls one of the affected functions. Secondly, if a web-site or other database front-end were configured to access and process arbitrary queries, it could be possible for the attacker to provide inputs that would cause the query to call one of the functions in question with the appropriate malformed parameters.
Several of the Microsoft-provided extended stored procedures have a flaw in common - namely, they fail to perform input validation correctly, and are susceptible to buffer overruns as a result exploiting the flaw could enable an attacker to either cause the SQL Server service to fail, or to cause code to run in the security context in which SQL Server is running. SQL Server can be configured to run in various security contexts, and by default runs as a domain user. The precise privileges the attacker could gain would depend on the specific security context that the service runs in.
An attacker could exploit this vulnerability in one of two ways. Firstly, the attacker could attempt to load and execute a database query that calls one of the affected functions. Secondly, if a web-site or other database front-end were configured to access and process arbitrary queries, it could be possible for the attacker to provide inputs that would cause the query to call one of the functions in question with the appropriate malformed parameters.
Read more
