Alexandr Polyakov posted a note to the bugtraq mailing list showing some example code (repeated here):
"create or replace procedure sh2kerr_num_proc is
stmt varchar2(2000);
n number:=dbms_random.value;
begin
stmt:='select object_name from all_objects where object_id = ' || n;
execute immediate stmt;
end;
/
--------------
TEST:
SQL> ALTER SESSION SET NLS_NUMERIC_CHARACTERS = '''.' ;
Session altered.
SQL> select dbms_random.value from dual;
VALUE
----------
'763871688
SQL> exec sh2kerr_num_proc
BEGIN sh2kerr_num_proc; END;
*
ERROR at line 1:
ORA-01756: quoted string not properly terminated"
David responded in the same thread to say that he did cover NLS_NUMERIC_CHARACTERS which he did, as i remember from reading it at the time but points out here that Alexandr has identified a specific attack vector in DBMS_RANDOM. I do check for use of this package in my security audits already so pick up its use anyway but its useful to have more "ammunition" in terms of why its use is an issue in addition to my existing arguments against its use.
Then David has posted another post to the bugtraq list showing that to exploit lateral SQL injection you do not need the ALTER SESSION privilege. here is the example from the mailing list email:
"C:\>sqlplus /nolog
SQL*Plus: Release 11.1.0.6.0 - Production on Fri Jul 18 14:47:17 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
SQL> connect testuser1/testuser1
Connected.
SQL> select * from session_privs;
PRIVILEGE
----------------------------------------
CREATE SESSION
SQL> alter session set sql_trace = true;
alter session set sql_trace = true
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> alter session set nls_date_format='"'' and myfunc()=1--"';
Session altered.
SQL> select sysdate from dual;
SYSDATE
------------------
' and myfunc()=1--
SQL>"
I was of course aware of this for many years but didn't connect this to David's paper at the time. I also just did a check search on google to see if I have mentioned this before but I haven't. I am surprised as I regularly have to actually demonstrate this to clients (not the exploit David mentions but the fact that the system privilege is not necessary). There are many things, many bad things you can do with the ALTER SESSION privilege, one such example is stealing data without access to the actual table. I always recommend to clients that they revoke ALTER SESSION from database accounts, they normally respond that they cannot because of x, y and z. I then need to demonstrate in SQL*Plus that ALTER SESSION is not actually needed to run most ALTER SESSION commands. It is needed to set SQL_TRACE and also to issue events. These are particular things we don't want people to do in normal production databases for security reasons. On the same veign as a corresponding example the ALTER USER command also works without the ALTER USER system privilege. A user can issue this command against their own account without the system privilege but not against another account.
I always mention these inconsistencies in my training class. A system privilege such as ALTER SESSION can be used for many things but control cannot be applied to the individual things allowed for that privilege if the system privilege is granted unless its exposed via a PL/SQL procedure but then the privilege would not be granted directly to the end user anyway so its not restricted at the "end user"/"privilege" level but via an interface level. Oracle would argue that the privilege is exposing elements of session settings which is fine but from a security perspective at least different things (elements of syntax) expose different risks.
The second level of inconsistency is the silent use of privileges such as ALTER SESSION and ALTER USER in controlled circumstances. This area needs to be better controlled, this functionallity may have been added to allow use of commands without the need to expose the dangerous parts (setting trace) but there is inconsistency there now and certainly from my experience over many years people are often not aware of this as I have to explain this in customer audit reports or even demo to the DBA's that ALTER SESSION does work without the privilege or connect role.
