"[RESOLVED] Java Security Problem?"

srt19170

I was a little alarmed to see that the Rapidminer script files by default use the JRE that is distributed with RapidMiner.  Since this JRE doesn't seem to get updated (at least in my experience) this is a significant security risk.  Does the Rapidminer executable also use the Rapidminer JRE?  Is there a process for updating the Rapidminer JRE?

Marco_Boeck

Hi,

there is no need to be concerned, as the shipped JRE is only used by RapidMiner Studio. The security scare regarding the Java JRE comes from the usage of Java in your browser, which can be exploited because your browser connects to all sorts of things. Quite literally the only way the shipped JRE of RapidMiner Studio theoretically could be exploited is when using the web extension, connecting to some obscure webservice with it, the webservice recognizing that you are connecting via Java which it is outdated and the webservice creating some sort of buffer overflow.
The likelihood of that happening is extremely slim
However you can still update the shipped JRE outside of our own updates if you so desire. Just copy the contents of your local, up to date Java JRE installation folder into the RapidMiner/jre folder and overwrite everything. Just make sure to use the 32bit JRE for 32bit RapidMiner and 64bit JRE for 64bit RapidMiner.

Regards,
Marco

srt19170

Thanks for the reply, Marco.

I'm not sure what you mean when you say only RapidMiner Studio.  All of the scripts in the scripts subfolder will use the shipped JRE.  Are you saying the shipped RapidMiner.exe finds and uses an installed JRE?

Can a malicious extension also exploit a security hole?  I agree that the security risk is slim, but shipping your own JRE is still not a good practice.

Of more immediate concern to me is that on a 64 bit Windows, if you try to up your Java memory usage by editing RapidMinerGUI.bat (as many of us do) you'll unwittingly get the shipped JRE, which is 32 bit, rather than the installed 64 bit JRE.  So the memory available is limited to the 32 bit addressing. 

It would make more sense (in my mind) if the JRE tests in the scripts were reversed, so that RapidMiner used an installed JRE if one was available and only fell back to using the shipped JRE if that was not found.

srt19170

On my machine, RapidMiner.exe fails to start if I remove the shipped JRE.

Marco_Boeck

Hi,

1) the shell scripts in the scripts folder are startup scripts only which basically do nothing except start a RapidMiner launcher jar and afterwards the rapidminer jar itself.
2) Yes, RapidMiner Studio.exe should locate the installed JRE if the shipped one cannot be found. However there were some problems with RM 5, RM 6 should be able to. But you can just swap them with your local JRE folder contents if you so desire.
3) What do you mean? When you run a Java program locally, there is no security hole required to do nasty stuff, just like any other program or even shell script. A java program, an .exe or a shell script all could go ahead and delete your files from any partition your user has write access to, if that's what you are concerned about.
4) The shipped JRE is equivalent to the version you downloaded. 64bit RM has 64bit JRE shipped and vice versa.

Regards,
Marco

srt19170

Thanks for the clarification.  You're right that since Java is running locally, any security risks are moot!