rmi/java serialization security fix

Classic Servoy
1

Java serialization has a security problem that in certain conditions an attacker can run stuff on the server.
It is found in various 3th party libs as described here in length:

http://foxglovesecurity.com/2015/11/06/ … erability/

also the apache reply for there commons lib (that servoy also ships)

https://blogs.apache.org/foundation/ent … widespread

We fixed it by making a whitelister for all the classes that are coming through the rmi protocol
Because just fixing/patching commons-lib (the lib we ship) isn’t really good enough, because there could be 3th party plugins contributing other libs that has the same problem into servoy

To configure this:

For servoy_server:
add rmi-whitelist-1.0.jar to the classpath in servoy_server.sh or servoy_server.bat
add ‘-Drmi.whitelist.config=com.servoy.:com.sebster.’ to the java main, maybe more packages needed

For war-deployment (under tomcat)
create /path/to/tomcat/bin/setenv.sh (linux/mac) or Z:\path\to\tomcat\bin\setenv.bat (windows) and in this file:
set CLASSPATH variable to rmi-whitelist-1.0.jar
set JAVA_OPTS to ‘-Drmi.whitelist.config=com.servoy.:com.sebster.’, maybe more packages needed

sample setenv.bat file for tomcat under windows: (classpath separator is a ; under windows and : under unix)

SET CLASSPATH=%CLASSPATH%;%CATALINA_BASE%/bin/rmi-whitelist.jar
set JAVA_OPTS=-Drmi.whitelist.config=com.servoy.:com.sebster.

For war-deployment on other web containers consult your web container documentation for similar configuration.

For deployment using Java Service Wrapper, edit the wrapper.conf file:
add rmi-whitelist-1.0.jar to the wrapper.java.classpath list
add ‘-Drmi.whitelist.config=com.servoy.:com.sebster.’ to the wrapper.java.additional list, maybe more packages needed

All this is only needed if you use the Smart client, if you only use Web or NGClient you can turn of rmi with this property:

servoy.server.start.rmi=false

in the servoy.properties file (WAR export has that option in the war export wizard)

Or make sure that the rmi port (mostly 1099) isn’t open to the public internet

If you would use 3th party plugins that have also client and a server side portion and use there own classes in there remove functions that wil be called then you will get in your log file:

2015-11-14 14:39:06,237 WARN [RMI TCP Connection(2)-127.0.0.1] com.servoy.rmi.whitelist.WhitelistingRMIClassLoaderSpi - Class not whitelisted for RMI: a.package.that.you.expect.Class

then you have to add that package to the -Drmi.whitelist.config=com.servoy.:com.sebster.:a.package.that.you.expect.

so that it will allow classes to be de serialized from that package.

If you want to test if the white lister works then just don’t set the -D property and a smart client shouldn’t be able to connect and you will get all those warnings on the server side about servoy classes which are not in the whitelist

rmi-whitelist-1.0.1.jar (10.1 KB)

2

Hi Johan,

This whitelister works on which versions of Servoy?

3

Hi Johan,

Can you give an whitelist example for let’s say the servoy stuff and the jasperreport plugin ?

Regards,

4

For those of you that make use of the below Plug-ins and/or Beans you should/can add ‘com.it2be.’ to the whitelist…

  • Calendar Bean

  • Data Plug-in

  • DataStream Plug-in

  • DDE Plug-in

  • Exchange Plug-in

  • ExchangeWS Plug-in

  • HTMLeditor Plug-in

  • LDAPclient Plug-in

  • Barcode Plug-in and Bean

  • Fax Plug-in

  • Tools Plug-in

I hope this helps.

We will soon release our new website with this information included as well :)

5

the whitelister works on all version of servoy
The code is quite independent of servoy itself, can be used by any other also using rmi

JasperReporst will work just fine because that uses a package com.servoy.xxxx (and that is by default already added)

many other stuff of servoy forge is i think “net.stuff.servoy.”

But to get one thing straight, this is only needed for a small portion of the plugins
And beans is very very unlikely the problem

This is only needed for plugins that have a server and a client side part, and the client talks through rmi/remote calls to the server
(like for example the mail plugin of servoy that has a client api sendEmail that redirects this to the server that actually sends the email)

Does for example the barcode plugin uses a server part?

6

For all the plugins and beans that I did and that you can find on ServoyForge, you can simply use “net.stuff.servoy.”

7

This is only needed for plugins that have a server and a client side part

How does an intruder gets his malicious server side part installed and running on the server ?
And if an intruder can do this he can also adjust the whitelist ?

8

jcompagner:
All this is only needed if you use the Smart client, if you only use Web or NGClient you can turn of rmi with this property:

servoy.server.start.rmi=false

I wouldn’t recommend setting it to false if you use 3rd party plugins because even in web or headless client, the client plugin might still use RMI to access server properties and methods provided in a server plugin.

9

lwjwillemsen:
How does an intruder gets his malicious server side part installed and running on the server ?
And if an intruder can do this he can also adjust the whitelist ?

this is quite technical, it is explained in the urls above, but it doesn’t “install” code on the server it used code on the server (commons lib of apache is one example)
to execute stuff on the server

And we ship and use commons collections by default, so that is already on the classpath. So that one can be abused to send an “instance” of that object to our rmi interface
That will then deserialize an execute code.

So if there is a whitelist then the intruder doesn’t get that fare to adjust the whitelist…

10

ptalbot:

jcompagner:
All this is only needed if you use the Smart client, if you only use Web or NGClient you can turn of rmi with this property:

servoy.server.start.rmi=false

I wouldn’t recommend setting it to false if you use 3rd party plugins because even in web or headless client, the client plugin might still use RMI to access server properties and methods provided in a server plugin.

that can be killed just fine

Server side (so in the same vm) shouldn’t communicate through the rmi interface, those have access to the object itself directly.

rmi is only used by the smart client to connect to the server and talk to the server. All other clients (with client/server plugins) even the once that have "server’ part are talking directly to the object instance.

So yes the best thing is to just switch it off if you don’t use the smart client.

11

jcompagner:
that can be killed just fine.

That ‘can’ be killed through a rewrite of the internal code of the plugin, unless when on in a client plugin when you make a call to a server plugin’s exposed as a service via IClientPluginAccess.getService(nameOfTheService) Servoy’s getServerService() method returns the actual server object without going through RMI?
Is that the case?

12

ptalbot:
Servoy’s getServerService() method returns the actual server object without going through RMI?
Is that the case?

yes that does not go through rmi, you are just in the same vm, you talk directly to the object

13

That’s good news and in that case, what you said makes more sense. Thanks for clarifying!