Wednesday, August 24, 2011

Remote unauthenticated DoS attack in Oracle

About 3 years ago, I had reported a possible remote DoS attack in Oracle. Oracle addressed the issue and acknowledged me for the discovery in its Critical Patch Update CPU April 2009 . Specifically it is the CVE-2009-0991 entry in the Oracle Database Risk Matrix. We never created any formal public advisory for this, but I was looking for something to post on my blog and writing about it seemed like a good idea :)

There is some flaw in the way Oracle handles user authentication. The authentication process seems to involve an initial TNS CONNECT from the client to which the server responds with an ACCEPT assuming correct server IP and port (1521 is the default LISTENER port) and SID/service name is specified. After which is negotiation of security services and exchange of a couple more packets. At one point, the client seems to send a login packet with username to which the server responds with a key (AUTH_SSKEY) indicating that some sort of a session initiation has begun.  This is done whether the username specified in the packet is valid or not. If the client then abruptly terminates the connection as soon as the session key packet is received, the database seems to still keep track of that session internally. On Oracle 10g, sending such multiple login packets with invalid/arbitrary usernames and abruptly terminating connections after the AUTH_SSKEY is received, will very soon exhaust the 'maximum concurrent allowed sessions' limit and thus cause a DoS for other users. On Oracle 9i R2, I could get same results, but the login packet needs a valid username, because in 9i R2 the session key is only generated for valid users. Nevertheless, one can always use known usernames like 'sys', 'dbsnmp' etc

Oracle later confirmed this to be an issue in 11gR1 as well. To resolve the issue, Oracle enhanced the INBOUND_CONNECT_TIMEOUT configuration parameter in CPU April 2009.  This parameter allows one to specify a timeout value in seconds to wait until the initiated login process is completed. So, using a small enough value for this parameter, an attacker will not be able to create too many such half-open logon sessions in order to cause the DoS. The default  timeout is 60 sec, but it should be less IMHO, although it would really depend on many factors specific to each setup.

New error codes ORA-3135 and ORA-3136 were also added to indicate when the timeout is exceeded, in addition to the existing codes.

Rights to this research belong to my company Application Security, Inc.

Wednesday, August 3, 2011

Revoke in Sybase

I learned something new today about how Sybase's  revoke SQL statement works. In Sybase a database user can be granted a privilege directly or indirectly (via role and/or group membership). In case of a direct grant, revoking the privilege will take the privilege out. But in case of an indirect grant its a little different.

If the indirect grant comes via a role, then revoke  doesn't do anything (actually throws an error), but if the grant comes from the group to which the user belongs, then the user would be denied  the privilege. Everyone else belonging to the group would continue to have the privilege except this user. A row is added to the sysprotects table to this effect.  Also note it should be noted that this applies to object privileges only - revoking an indirectly granted system privilege (either via role or group) does not have any effect.

Also, its worth nothing here that role privileges trump any privilege grants and revokes at the group or direct user level.

To explain this by an example, lets assume user user1 belongs to group group1 and is also granted a role role1.

grant select on table table1 to group1

This gives user1  a select privilege on table1 via group group1.

revoke select on table1 from user1

This denies user1 select on table1

grant select on table1 to role1

This gives the select privilege back to user1 because the role privilege trumps any group and user level grants/revokes

 

System-reserved roles in DB2 version 9.7

DB2 9.7 added a few built-in roles like SYSROLE_AUTH_DBADM, SYSROLE_AUTH_SECADM.  These roles show up in the syscat.roles and syscat.roleauth catalog views as regular roles, but DB2 treats them as   special roles reserved exclusively for certain database authorities. For example, SYSROLE_AUTH_DBADM is granted automatically whenever DBADM is granted to someone. And it is revoked automatically when DBADM is revoked. These  roles can not be granted/revoked manually (using grant/revoke statement for example). These roles hold system chosen object privileges. For example, SYSROLE_AUTH_DBADM role hold EXECUTE privilege over many (all?) procedures/functions under the SYSPROC, SYSIBMADM, SYSIBMINTERNAL schemas.