Hide Forgot
Affects: Release Notes Date of First Response: 2007-12-13 00:16:26 project_key: SOA The service on port 8083 serves all internal classfiles, which is not be desired. This should be limited to classes that are neccessary for external use (such as RMI/IIOP stubs), some class may not be served due to their usage license, some may contain confidential information about a deployed application. Seems to be related to http://jira.jboss.com/jira/browse/JBAS-4540 but does not show a 404 as stated there. You can test this as follows: [mschoene@mschoene soates20071112]$ more getclassin.txt GET .org/jboss/web/WebServer.class HTTP/1.1 [mschoene@mschoene soates20071112]$ more getclassfile.sh nc 127.0.0.1 8083 <getclassin.txt >getclasstxtout.bin xxd getclasstxtout.bin [mschoene@mschoene soates20071112]$ sh getclassfile.sh 0000000: 4854 5450 2f31 2e30 2032 3030 204f 4b0d HTTP/1.0 200 OK. 0000010: 0a43 6f6e 7465 6e74 2d4c 656e 6774 683a .Content-Length: 0000020: 2031 3038 3434 0d0a 436f 6e74 656e 742d 10844..Content- 0000030: 5479 7065 3a20 6170 706c 6963 6174 696f Type: applicatio 0000040: 6e2f 6a61 7661 0d0a 0d0a cafe babe 0000 n/java.......... 0000050: 0031 01ff 0a00 9401 0b09 0090 010c 0900 .1.............. 0000060: 9001 0d07 010e 0a00 0401 0b09 0090 010f ................ 0000070: 0900 9001 1009 0090 0111 0900 9001 1209 ................ 0000080: 0090 0113 0900 9001 1409 0090 0115 0a00 ................ 0000090: 9201 1607 0117 0801 180a 000e 0119 0701 ................ 00000a0: 1a0a 0011 011b 0900 9001 1c07 011d 0a00 ................ 00000b0: 1401 0b08 011e 0a00 1401 1f0a 0014 0120 ............... 00000c0: 0a00 1401 210a 0122 0123 0a00 9001 2407 ....!..".#....$. 00000d0: 0125 0701 2608 0127 0a00 1401 2808 0129 .%..&..'....(..) 00000e0: 0a00 1d01 2a07 012b 0a00 1101 2c07 012d ....*..+....,..-
Link: Added: This issue is related to JBAS-4540
This is ultimately a non-issue, because the server does not respond to non-local requests, regardless of the binding address.
Link: Added: This issue is a dependency of SOA-101
I'm just not sure we can possibly secure this out of the box. Certainly, RMI is one of ESB's supported endpoint protocols, and I don't see how we can possibly automatically limit serving the classes across the wire, just based on whatever business classes are present. That would seem to me, to be something that could only be accomplished programmatically from ESB itself (if possible at all). It would seem to me that this would have to be something that is documented in the platform documentation, for informing the client on how to secure the server after deploying their projects.
This is fixed in the production config. Port 8083 still listens, but will only serve deployed EJB remote interfaces by default. However, this webserver does not throw 404 errors, but rather returns blank content for requests where there is no class found, and this should be understood in testing.
Link: Added: This issue is related to SOA-406
Link: Added: This issue is a dependency of SOA-406
Link: Removed: This issue is a dependency of SOA-406
Link: Removed: This issue is related to SOA-406
documented.
Affects: Added: [Release Notes]
Same results with CP01 build.
Attachment: Added: CP01.txt
email from Marc: Hi Joshua, the only reliable workaround is fixing it. A fix is available since 20070724, see http://jira.jboss.com/jira/browse/JBAS-4540 For a temporary fix there are some flags in the the config for org.jboss.web.WebService mbean that promise to disable non-EJB class download. <attribute name="Port">8083</attribute> <!-- Should resources and non-EJB classes be downloadable --> <attribute name="DownloadServerClasses">false</attribute> <attribute name="DownloadResources">false</attribute> Thanks Marc
Link: Added: This issue depends JBPAPP-245
I see no reason why the standalone server does not behave in the same way. I suspect that when data and jars have been stripped out during its creation that we lost something.
See last comment, this is a documentation issue. The setting to serve the classes is needed for some of the RMI quick starts. The user needs to know that with the standalone server it is necessary to change this setting to false in order to secure the environment for production.
Release noted: 3.5.2. Preventing download of non-RMI classes on Port 8083 in the standalone version of the server If you use RMI (Remote Method Invocation) you will want to make Port 8083 of your server accessible to clients. The EAP version of the server is configured out of the box to restrict the classes that it serves on this port. The standalone server, however, is configured out of the box to serve all deployable classes via this port. This has been done to allow the quickstarts to function correctly by default. To change this behaviour you need to modify the following line in default/conf/jboss-service.xml: <!-- Should non-EJB .class files be downloadable --> <attribute name="DownloadServerClasses">false</attribute> The value for this attribute is set as true out of the box, and it should be set to false in actual production deployment to prevent the server from serving all deployable classes on Port 8083.
Verified in the release notes here: https://svn.corp.jboss.com/repos/soa/trunk/build-tools/docs/SOA_Release_Notes.txt
It's in the CR3 release note too: 3.5.2. Preventing download of non-RMI classes on Port 8083 in the standalone version of the server If you use RMI (Remote Method Invocation) you will want to make Port 8083 of your server accessible to clients. The EAP version of the server is configured out of the box to restrict the classes that it serves on this port. The standalone server, however, is configured out of the box to serve all deployable classes via this port. This has been done to allow the quickstarts to function correctly by default. To change this behaviour you need to modify the following line in default/conf/jboss-service.xml: <!-- Should non-EJB .class files be downloadable --> <attribute name="DownloadServerClasses">false</attribute> The value for this attribute is set as true out of the box, and it should be set to false in actual production deployment to prevent the server from serving all deployable classes on Port 8083.