4.4.6 Can a client implementation circumvent administrative security policies?

Extended Question

(Christoph Haenle³⁰): From the CORBA security spec, I see that administrators can enforce policies such as "whether this client can use this operation on this target object, whether the invocation should be audited, [...]" (section 15.6.1 of CORBA Spec).

This part of security is enforced in the ORB, for example, through the "client access control interceptor" (Figure 15-53).

My question is: Can't the client circumvent the restrictions? Assume we use C++ for the application and the stubs objects. Now, does the ORB run in a different address space than the application

(incl. stubs)? Or is the client part of the ORB linked to the application at compile time (and thus running in the same address space)? If the ORB were in the same address space, then the client could just modify the ORB code to circumvent the policies that the administrator has imposed. Even if the ORB were running in a different address space, the client could still write a piece of software which behaves like the ORB, but leaves out the routines where administrative restrictions are enforced. The client could then his "custom ORB implementation" rather than the "real" ORB for communication, hereby circumventing administrative security policies.

Rudolf Schreiner

(November, 1998)³¹ : Security enforcement on the client side is always a bad idea. CORBASEC enforces authentication and authorization on the server side. The client passes a kind of ticket to the server (Kerberos!!). Without the right ticket the server refuses to talk to the fake client. On the client side you can do whatever you want, without the right ticket (credentials) you can't do nothing on the server side.

In my Kerberos 5 based implementation I use GSS-API to get a ticket from outside the CORBA system. Then I use GSS-API to establish a security context between client and server. This is done at a very low level during the bind, before any IIOP messages are sent. If the server can't authenticate the client the connection is dropped. All IIOP messages are encrypted/decrypted using GSS function.

In theory such a system is quite bullet proof. In the real life an attacher might be able to exploit a buffer overrun on the server ORB and execute arbitrary code. There are some other possible attacks, too.