This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Glassfish is bundled with the J2EE version of Netbeans 6.8. By default, the admin panel is started on port 4848 and runs with privileges of the person who started the process and the Security Manager is disabled. This poses a serious security risk - it makes it easy for anybody on the user's network to upload a J2EE Application and have it run on the user's machine with their rights! If the developer has a direct connection to the internet, then the whole world has access to their machine. Imagine how trivial it is to write an application that could give a malicious user full read/write access of all the user's files. I recommend that Glassfish be set up to only listen to the loopback device (on OS X and Linux), and therefore only be accessible locally. An alternative solution includes turning the Security Manager on by default (although, that will most likely irritate most developers), or running Glassfish in a jailed environment (or with reduced user rights) so that it does not have carte-blanche access to the developer's files. Another alternative solution would be to have a randomly generated admin password, similar to how Tomcat is set up. Although I would prefer this to be to augment the above solutions. On Linux it should be possible to block all incoming connections with iptables. On OS X Snow Leopard it is not possible to easily block all incoming connections on a given port - I would welcome a firewall-based workaround.
The ide does nothing special to alter the install configuration that we get from the glassfish server team. I think any of the downloads that you get from glassfish.dev.java.net are equally vulnerable. Have you opened an issue there? https://glassfish.dev.java.net/servlets/ProjectIssues It is probably the more appropriate place for raising this type of issue. I am marking this issue as invalid, since there is a better 'target' for it.
RFE to bind the admin panel to localhost by default has been created on the Glassfish issue tracker. https://glassfish.dev.java.net/issues/show_bug.cgi?id=11626 Note that implementing a workaround in NetBeans is trivial - all NetBeans needs to do is add address="127.0.0.1" to the definition of the line beginning network-listener port="4848" protocol="admin-listener" in the file sges-v3/glassfish/domains/domain1/config/domain.xml Although, NetBeans may wish to make further precautions such as installing an admin password, or locking all listeners to localhost.
Vince, what do you think about this tiny change in the GlassFish configuration? Thanks for your input!
I think the work-around is probably a good idea... but it should be implemented in the bits that we get from glassfish... not by the nb installer.
OK, thanks. So, let's hope the GlassFish issue will be fixed soon!
This horrendous security hole has reopened with the glassfish-3.1.1 bundled with NetBeans 7.1. I just got a colleague to install NB7.1 and run any J2EE application (one of the samples). The result is that I could log in to their computer on port 4848 without a password and can do whatever I want - turn off the security manager, install my own J2EE application and essentially have the run of their computer running as their user. I don't know which versions of Netbeans have been affected. It is possible to fix this by issuing 'asadmin' commands or by editing the domain.xml file of the bundled files. If the bundled glassfish is going to change when the upstream version is updated. I STRONGLY recommend that NB checks to see if a password has been installed and if the admin listener is on localhost. If not, then tell the user about this security hole and offer to fix it up. This security hole is so serious that I am contemplating creating a proof of concept WAR file.
Created attachment 115130 [details] POC exploit
Created attachment 115131 [details] POC exploit source code
OK, I have attached a proof of concept SECURITY EXPLOIT for this bug. In the following instructions, HOST is used to denote the hostname/IP address of the machine which is running a default configured Glassfish installation: 1. navigate to HOST:4343 2. select "Applications" from the list on the left 3. select "deploy" and upload the attached WAR file 4. navigate to HOST:8080/issue181080-1.0-SNAPSHOT/?command=echo+hello+world ((I have crippled the exploit to only execute '/bin/ls /' no matter what the command is)) This means you have just installed an arbitrary J2EE application on a machine which you should not have permission to, and the application can run arbitrary commands as the user who started the application server (i.e. the unknowing J2EE Netbeans user). I have also attached the source code so that malicious users can remove the restraint. (Note that NB7.1 has a bug in understanding the JSP file, although it is valid)
(In reply to comment #6) > This horrendous security hole has reopened with the glassfish-3.1.1 bundled > with NetBeans 7.1. I just got a colleague to install NB7.1 and run any J2EE > application (one of the samples). What OS is your colleague running?
This exploit works for any OS. If they have a firewall up to drop connections to port 4343, then they will be protected.
(In reply to comment #11) > This exploit works for any OS. > > If they have a firewall up to drop connections to port 4343, then they will be > protected. I understand that a user on any os could access the web console, but I would still like to know what OS the server is running on. What OS is your colleague running the GlassFish server on?
The person running the glassfish server is on any OS - this exploit will work against Windows, Linux and OS X. As long as port 4343 is open, this exploit will work. Try it. Apparently the glassfish people have fixed this for 3.1.2. I understand that they don't consider the default settings to be distributed "as is" and that some customisation should be made, especially with regards to security.
(In reply to comment #13) > The person running the glassfish server is on any OS - this exploit will work > against Windows, Linux and OS X. As long as port 4343 is open, this exploit > will work. Try it. > > Apparently the glassfish people have fixed this for 3.1.2. I understand that > they don't consider the default settings to be distributed "as is" and that > some customisation should be made, especially with regards to security. Are you saying that you/your colleague have verified this for GF servers running on all OSes by actually testing it on the various 'supported' OS platforms?
Vince, the default configuration for glassfish puts the admin listener on address 0.0.0.0 with no password. This is a cross-platform configuration. If connections to port 4343 are allowed, then the security hole exists regardless of the OS. I have tested an OS X Netbeans 7.1 J2EE, but it should work on any OS. For the purposes of Netbeans development, you really only want Glassfish listening on 127.0.0.1. I strongly recommend a dialogue between Netbeans J2EE developers and Glassfish experts to agree on a sensible default configuration. Netbeans is making huge assumptions in the suitability of the Glassfish default configuration to development environments. I understand that Glassfish 3.1.2 changes the default configuration to avoid these kinds of distribution blunders. However, it would make sense for Netbeans to detect poorly configured glass fish instances and offer to fix them - it's a one line 'asadmin' command (or a 1 line change to the XML file when glass fish is not running).
I just reread http://java.net/jira/browse/GLASSFISH-11626 and it looks like they meant to prevent remote administration through asadmin and not through the admin console. I had assumed that they locked both doors to remote administration at the same time. I just tested 3.1.2 and it behaves better. a user cannot administer 3.1.2 remotely with asadmin or admin console until they enable secure admin and set a password for the admin user.
gf 3.1.2 is bundled with the dev builds and is also going to be bundled with nb 7.1.1... I am going to mark this as fixed. finally.