RMI and untrusted clients...

[Daniel Pitts]

I have a game which I'm hoping to use RMI as the transport between the
client/server.

Obviously we don't want people cheating or otherwise hacking the
server... Is RMI a good choice? My remote interface only exposes
hardened methods, so if clients can only call those methods, things
are safe enough.

Although, I'm not sure how to get the remote reference to the client
side of things. I guess I don't know enough about the rmiregistry
program. I don't want just anybody to be able to bind to the registry,
but I want our untrusted clients to retrieve an object from the
registry. Is this easy/possible?

 

[Esmond Pitt]

Is RMI a good choice? My remote interface only exposes
hardened methods, so if clients can only call those methods, things
are safe enough.

There's no way for them to call anything else via RMI. They could try at
the TCP/IP level, but they'd have to implement both the RMI *and* the
Serialization protocols themselves, and know the current target object
IDs too. I would say if you use secureRandomIDs for the objects you can
pretty much forget about that too.

Although, I'm not sure how to get the remote reference to the client
side of things. I guess I don't know enough about the rmiregistry
program. I don't want just anybody to be able to bind to the registry,
but I want our untrusted clients to retrieve an object from the
registry. Is this easy/possible?

The Registry can only be bound to by processes running in the same host
as the registry, so it is safe from any remote client. Any client can
lookup the registry if it can communicate with it.

There are firewall and port issues which you need to address at your
server end - you need to export your remote objects on specific port
number(s) and open those ports in the firewall, also port 1099 for the
Registry.

If you need more security than that, see my RMIProxy product at
http://www.telekinesis.com.au - you can define which clients can access
which remote interfaces, and within that which clients can perform which
methods: very fine-grained access control. I also have a subset of that
product which is just a Registry with access control on a similar basis.

EJP

 

[Chris Uppal]

There's no way for them to call anything else via RMI. They could try at
the TCP/IP level, but they'd have to implement both the RMI *and* the
Serialization protocols themselves

They could save themselves a little effort by using Java for their nefarious
intrusion attempts.

Another thing that I'd be concerned about (that's to say, something that I'd
want to look into before deciding /whether/ it was a serious issue) would be
the possibility of DoS attacks on the game server. While it might be difficult
to send non-garbage data to the server; garbage, or semi-garbage, is sometimes
sufficient if all you want to do is disrupt service. E.g. if a malicious
client opens 1000s of TCP connections then doesn't send anything over them, or
opens connections and sends megabytes of garbage, or repeatedly resends
near-valid byte sequences obtained by sniffing a previous session. I repeat
that I'm not saying that RMI (or any particular RMI implementation) /is/
susceptible to that kind of attack, but only that it's something I'd want to
explore.

-- chris

 

[Daniel Pitts]

They could save themselves a little effort by using Java for their nefarious
intrusion attempts.

Another thing that I'd be concerned about (that's to say, something that I'd
want to look into before deciding /whether/ it was a serious issue) would be
the possibility of DoS attacks on the game server. While it might be difficult
to send non-garbage data to the server; garbage, or semi-garbage, is sometimes
sufficient if all you want to do is disrupt service. E.g. if a malicious
client opens 1000s of TCP connections then doesn't send anything over them, or
opens connections and sends megabytes of garbage, or repeatedly resends
near-valid byte sequences obtained by sniffing a previous session. I repeat
that I'm not saying that RMI (or any particular RMI implementation) /is/
susceptible to that kind of attack, but only that it's something I'd want to
explore.

-- chris

This also doesn't seem localized to RMI. It might be easier to detect
such an attack if you are working directly at the socket level, but it
wouldn't necessarily go away.

 

[Esmond Pitt]

Another thing that I'd be concerned about (that's to say, something that I'd
want to look into before deciding /whether/ it was a serious issue) would be
the possibility of DoS attacks on the game server. While it might be difficult
to send non-garbage data to the server; garbage, or semi-garbage, is sometimes
sufficient if all you want to do is disrupt service. E.g. if a malicious
client opens 1000s of TCP connections then doesn't send anything over them, or
opens connections and sends megabytes of garbage, or repeatedly resends
near-valid byte sequences obtained by sniffing a previous session. I repeat
that I'm not saying that RMI (or any particular RMI implementation) /is/
susceptible to that kind of attack, but only that it's something I'd want to
explore.

Just to address those two concerns, if an RMI server doesn't recognize
the first 4 bytes of the communication (as 'JRMP') or gets any kind of
protocol error or deserialization problem deserializing the RemoteCall,
it will close the socket immediately, so it almost certainly won't read
gigabytes of garbage. It will close an idle socket after two hours, or
less if you configure it (sun.rmi.transport.tcp.readTimeout).

And you can always add SSL, or use a SecurityManager and
java.net.SocketPermissions to exclude untrusted hosts before *anything*
is read.