[omniORB] Bi-directional (BiDir) GIOP on basis of IOR obtained from Naming Service?

Sun Apr 24 14:26:51 UTC 2022

Bi-directional GIOP as specified has a security problem, in that the
way it works is the client sends a service context containing a
sequence of ListenPoints:

struct ListenPoint {
  string host;
  unsigned short port;
};
typedef sequence<ListenPoint> ListenPointList;

struct BiDirIIOPServiceContext {
  ListenPointList listen_points;
};

Then the specification says:

   "... If a host and port pair in a listen_points list matches a host and
   port, which the ORB intends to open a connection to, rather than open a
   new connection to that listen_point, the server may re-use any of the
   connections that were initiated by the client on which the listen point
   data was received."

What that means is that a client can send a service context that
hijacks any outgoing calls that the server makes, just by claiming to
be a suitable bi-directional target for the host and port!

To prevent that, omniORB only allows bi-directional calls to be made on
object references that were received through the connection in
question, in the assumption that if a client sent the object reference
itself, it's fair to call it bidirectionally. In your case, getting the
object references from the naming service, that clearly does not work.

There was an initiative to revise the bi-directional GIOP specification
to address that, which is what is referred to in the code comment, but
it was not accepted into the CORBA spec. The latest 3.4 / 3.3 CORBA
spec still has the unchanged original mechanism. The document referred
to in the source is only available to OMG members (which I currently am
not), but I think a slightly later version of it is this, which is
public:

https://www.omg.org/cgi-bin/doc?orbos/01-08-03

That includes a pretty complex cryptographic approach to avoid the
problem. Not only is it complex, but it is now hopelessly obsolete
because it requires the use of 1024-bit RSA and SHA-1 hashes, both of
which are now considered weak. Regardless, that proposal was not
adopted into the CORBA spec.

None of that helps you of course. I can think of two things you could
do, one which is simple but requires changing your application, the
other that might be more tricky.

The more tricky option is to modify omniORB to change the way it
handles bi-directional, perhaps to relax the restriction that it only
applies to object references received on the incoming connection. I
think that will be tricky because it's quite deep-seated that the
object reference matching is based on incoming connections.

The simpler thing would be for your client to expose an object that is
a "lookup" object. Then when the server wants to look for a callback
object, it calls into the client's lookup object (using bidirectional
GIOP!), and that returns whichever object reference is required. The
implementation of the lookup method could use the naming service, or
look things up locally. The point of that design is that then the
callback object reference would be received on the client's
bidirectional connection, so the bidirectional logic would work.

Regards,

Duncan.

On Wed, 2022-04-20 at 12:39 +0000, Stefan Schweitzer via omniORB-list
wrote:
> Hello everybody,
> 
> I am trying to get my server application to pick up an existing rope
> from the client, and I am failing.
> 
> I have set up both my client and my server applications to support
> bidirectional GIOP. After debugging into omniORB, I am confident that
> all requirements regarding configuration have been met.
> 
> The problem seems to be of a different nature:
> - Client invokes a server method but does NOT pass any object
> references. (This gets a TCP connection from client to server into
> existence.)
> - Server wants do make callback to client.
> - Server gets client IOR from COS Naming Service (!).
> - omniObjRef::_unMarshal() unmarshals the string on the basis of a
> cdrMemoryStream passed by the calling method (which is
> omniObjRef::_fromString()).
> - Since the stream is NOT a giopStream (but a cdrMemoryStream),
> _unMarshal() does NOT put TAG_OMNIORB_BIDIR into the IOR.
> - This later leads to createObjRef() failing to select the existing
> bidir rope for the callback.
> 
> Why use the COS naming service to obtain the callback reference? -
> Because the receiver of the callback is one of hundreds of objects
> existing in the client, and the server is to decide who gets the
> callback, and we are reluctant to put hundreds of object references
> into any Server IDL interface method.
> 
> In the omniORB source code, I can see the following comment:
> 
>   // Provide interim BiDir GIOP support. Check the stream where this
> IOR
>   // comes from. If it is a giopStream and this is the server side of
>   // a bidirectional stream, add the component tag TAG_OMNIORB_BIDIR
> to the
>   // ior's IOP profile list. The component will be decoded in
> createObjRef.
>   //
>   // In the next revision to bidir giop, as documented in OMG doc.
> 2001-06-04 
>   // and if it ever gets adopted in a future GIOP version, the tag
> component
>   // TAG_BI_DIR_GIOP will be embedded in the IOR and this step will
> be
>   // redundent.
> 
> So, what does "interim BiDir GIOP support" mean here? Does it mean
> that server -> client rope selection works only in the scope of an
> upcall containing the client object reference (so the server
> unmarshals any object reference from a giopStream rather than a
> cdrMemoryStream)?
> 
> The CORBA standard says: " The client creates an object for exporting
> to a server, and arranges that the server receive an IOR for the
> object. The most common use case would be for the client to pass the
> IOR as a parameter in a GIOP request, but other mechanisms are
> possible, such as the use of a Name Service."
> 
> What about the TAG_BI_DIR_GIOP embedded in IORs; has it ever become
> part of the standard? I have not been able to find a lot of
> information about this.
> 
> Any hint is greatly appreciated. If I should be on the wrong track
> altogether, I would be glad to be told as well ;-). Thank you.
> 
> omniORB version 4.2.3
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> https://www.omniorb-support.com/mailman/listinfo/omniorb-list

-- 
Duncan Grisby <duncan at grisby.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.omniorb-support.com/pipermail/omniorb-list/attachments/20220424/2902cb68/attachment.html>