Most organizations are familiar with the risk posed by SQL injection in web applications, but fewer are aware of the implications of SQL injection in stored procedures. Any component that dynamically creates and executes a SQL query could in theory be subject to SQL injection. In those databases where mechanisms exist to dynamically compose and execute strings, SQL injection in stored procedures can pose a risk.
In Oracle, for example, stored procedures can execute with either the privilege of the invoker of the procedure, or the definer of the procedure. If the definer was a high-privileged account, and the procedure contains a SQL injection flaw, attackers can use the flaw to execute statements at a higher level of privilege than they should be able to. The following procedures all allow privilege elevation in one form or another:
The DRILOAD.VALIDATE_STMT procedure is especially interesting since no “SQL injection” is really necessary; the procedure simply executes the specified statement with DBA privileges, and the procedure can be called by anyone,for example the default user “SCOTT” can execute the following:
exec CTXSYS.DRILOAD.VALIDATE_STMT(‘GRANT DBA TO PUBLIC’);
This will grant the “public” role DBA privileges.
In most other databases the effect of SQL injection in stored procedures is less dramatic — in Sybase, for example, “definer rights” immediately back down to “invoker rights” as soon as a stored procedure attempts to execute a dynamically created SQL statement. The same is true of Microsoft SQL Server.
It isn’t true to say that SQL injection in stored procedures has no effect in SQL Server, however — if an attacker can inject SQL into a stored procedure,he can directly modify the system catalog — but only if he already had permissions that would enable him to do so. The additional risk posed by this is slight, since the attacker would already have to be an administrator in order to take advantage of any SQL injection flaw in this way — and if he is a database administrator, there are many other, far more serious things he can do to the system.
One privilege elevation issue in SQL Server is related to the mechanism used to add jobs to be executed by the SQL Server Agent (#NISR15002002B).Essentially, all users were permitted to add jobs, and those jobs would then be executed with the privileges of the SQL Agent itself (by getting the SQL Agent to re-authenticate after it had dropped its privileges).
In general, patching is the answer to this class of problem. In the specific case of Oracle, it might be worth investigating which sets of default stored procedures you actually need in your environment and revoking access to“public” — but as we previously noted, this can cause permission problems that are hard to debug.