Things are even worse
Today I have found that this vulnerability can be exploited not only when a select privilege granted on a table, but also if select has been granted to a view. The view must keep keys of table though, that is to be updateable.
Even if a view is not updateable, oracle passes DMLs through security control, then it says that view is not updateable.
Select on a view can be granted to user directly or via role, or via chain of roles, it does not make a difference.
I have granted SELECT_CATALOG_ROLE to a role that is granted to another role that is granted to an account ("hacker"). And the attack returned
HACKER>update (...censored code to access DBA_USERS...)
4 set password='xxx' where username='HACKER'
set password='xxx' where username='HACKER'
*ERROR at line 4:
ORA-01779: cannot modify a column which maps to a non key-preserved table
It means that if the view would preserve a key, that would be updateable.
And there are many views in SYS that are updatable.
Resume: be very careful when grant any access to dictionary views
Even if a view is not updateable, oracle passes DMLs through security control, then it says that view is not updateable.
Select on a view can be granted to user directly or via role, or via chain of roles, it does not make a difference.
I have granted SELECT_CATALOG_ROLE to a role that is granted to another role that is granted to an account ("hacker"). And the attack returned
HACKER>update (...censored code to access DBA_USERS...)
4 set password='xxx' where username='HACKER'
set password='xxx' where username='HACKER'
*ERROR at line 4:
ORA-01779: cannot modify a column which maps to a non key-preserved table
It means that if the view would preserve a key, that would be updateable.
And there are many views in SYS that are updatable.
Resume: be very careful when grant any access to dictionary views
0 Comments:
Post a Comment
<< Home