tracker issue : CF-4141711

https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3837342 https://bugbase.adobe.com/index.cfm?event=selectBug&CFGRIDKEY=CF-4130808 I am aware that the above issues point to the same problem thus this can be considered as a duplicate, however I disagree the issue is closed as no proper explanation is given, thus please address the below points which mainly reference to bug id: CF-3837342 answer. 1. What 'other service' are making use of this port? 2. According to the reply: 'in order to avoid confusion this port number information is removed from the Monitoring Settings Admin page' the port should have been removed from the Server Monitoring > Settings page but it is still visible, as can be seen in the screenshot, should this be the case? 3. If more than once ColdFusion instance is running on the application server, the port used is another, therefore if the 5500 is used by another instance, another port is used, is there a list which we can follow or set in order to set the available ports or is this completely dynamic and we have no control over?

Comment by External U.

Hi Godwin, 1. 5500 is used by Jetty server shipped with CF. It is been used by html to pdf feature. 2. That change has been done in CF2016 3. Yes the port picked up is completely dynamic and we have no control over it. Thanks, Dattanand Bhat

Comment by Dattanand M.

Hi Dattanand, Thanks for your reply. We use cfdocument for our pdf pages, we are not using cfhtmltopdf are we impacted should we opt to turn of the Getty Service? Are there any plans from Adobe to produce a hotfix containing the functionality to turn off the Getty service if not in use as per point 2 in the thread? Thanks again

Comment by External U.

Hi Dattanand, Was there any progress on this issue? Thanks.

Comment by External U.

Hi Godwin, We are not fixing this for now. We will reevaluate this if we get more request for the same. Thanks, Dattanand Bhat

Comment by Dattanand M.

@Godwin, turning this off might affect multiple other features (imaging, graphs,content-based PDF's, cfpresentation, cfreport etc), hence, we will not be fixing this. Let us know if you still have some concerns.

Comment by Vamseekrishna N.

@Vamseekrishna / @Dattanand - the PDF service, solr service use port 8987 by default, and is configured in the jetty sub folder of the CF instance. The jetty server that runs on port 5500 is not started by the ColdFusion Add on Service is it started by the main CF process. It is configured in the cfusion/lib/jetty.xml file. So there are two different jetty servers. The imaging, graphs, cfpresentation and cfreport utilize the /CFFileServlet/ to serve dynamically generated assets, which is mapped to the main web.xml I don't think your answer is correct about what the server on port 5500 is doing. Please look into this further! Also how can it not be a bug to have a setting in ColdFusion Administrator that says "Enable Monitoring Server" and does not do anything? If you are really correct that it is a requirement to run the monitoring server to use other features (which I am skeptical is actually the case) then you need to remove the setting to avoid confusion.

Comment by Peter F.

It is a bug to have a setting in ColdFusion Administrator that says "Enable Monitoring Server" and does not do anything? If you are really correct that it is a requirement to run the monitoring server to use other features (which I am skeptical is actually the case) then you need to remove the setting to avoid confusion.

Vote by Peter F.

@vamseekrishna / @dattanand - Pete is doing the diligence for you that your team should be doing. I have confirmed the same on all my CF11 servers. The main CF service is responsible for jetty running on 5500, even though Enable Monitoring Server is disabled. Secondly, I see no new jetty server on any other port if I DO enable Monitoring Server. I would really like to hear a more detailed answer to Pete's question above, as he has clarified why your previous answer was not correct. Unknown servers running on undefined ports does not speak well of your security posture...

Comment by Nikolas S.

Won't Fix is an unacceptable answer to this bug.

Vote by Nikolas S.

@Peter - By default the monitoring service uses 8500, by enabling "Enable Monitoring Server" option from CF admin monitoring service uses 5500. However, PDFg service also uses the same jetty server to serve temporarily generated HTML files. We are evaluating how we can decouple these services.

Comment by Dattanand M.

Dattanand, you keep saying that port 5500 is used by the PDFG service. As Pete has explained, it is not. It's understandable how someone could fear that it may be related, since both are indeed based on Jetty, but again as Pete has pointed out, they are TWO DIFFERENT JETTY IMPLEMENTATIONS. For those interested in the history, CF9.0 had added Solr, enabled by way of the then "jetty service" (since renamed "add-on service", and used also now by the PDFG featrure), and that was implemented as a separate service/jvm to separate such operations off of the CF JVM. Then in CF 9.0.1, the new "monitoring server" option was added to the Server Monitor (along with the new "monitoring settings" page in the admin), to enable requests to the Server Monitor to be able to be talked to by other than the external web server or CF's built-in web server. Since that had to be enabled WITHIN the CF JVM, that was implemented as this second jetty implementation. But as has been reported here, the exposure of that jetty web server (and port 5500) has been a problem. Still another problem is that it's set by default to listen with a "host" value of 0.0.0.0, so it listens to requests from any IP. That has been a problem when people have nessus and other security scans that blast away at that port and lead to CF itself locking up (since again, THAT port is indeed setup WITHIN the JVM underlying CF). There are still more reasons why this must be addressed. For one, this jetty web server (inside of CF) is enabled even in CF Standard implementations, which DO NOT EVEN HAVE the CF Server Monitor feature in CF2016 and below. Furthermore, this port (and the same cfusion/lib/jetty.xml and its port and host values) REMAIN enabled even in CF2018 which (for Std AND Enterprise) NO LONGER HAS the CF Server Monitor anymore. For all these reasons, this should be addressed. This jetty web server should certainly be disabled if the CFSM "monitoring server" feature is turned off. And it should NOT be enabled by default on CF Standard (2016 and below), or in CF2018 at all. Indeed, it should not even be enabled by default in CF2016 Enterprise and below UNLESS someone turns on the "monitoring server" feature. It seems somehow someone decided to enable it always, regardless of any of these circumstances, which is a problem for all the reasons above.

Comment by Charlie A.

We had the Nessus port 5500 security scan problem locking up CF that Charlie mentioned in his comment. It was a big problem well beyond what average users should have to encounter. We felt lucky that Charlie was able to identify the problem and tell us how to work around it.

Vote by John D.

Adobe folks, I see this indicating fixed in cf2018, which is great. But why didn't anyone respond to it to clarify things? Are there corrections to info you shared previously? It would help for all concerned to know the situation. Also, the info here says it was fixed in 2018.0.0.313895, which implies it was in the base release. But then the bugs fixed list for its update 2 points to this bug, so what's the difference between what was done per the first release and the second update, if anything?

Comment by Charlie A.

Great news to share on this. I can confirm that CF2018 update 2 DID indeed address this problem, as did CF2016 update 8 (which both came out in Feb 2019). After those updates, CF now no longer listens on port 5500 (this jetty port, controlled by the cfusion\lib\jetty.xml). One can use any of various tools, such as netstat, to confirm that. And clearly, it did NOT have anything to do with the PDFG/addon service/HTMLtoPDF tag, as Pete and I and others tried to clarify (which still has its own cfusion/jetty/etc/jetty.xml, for use with that add-on service, for those who install it. And FWIW, that other jetty.xml DID presume to set the host to 127.0.0.1, unlike this older jetty.xml issue, now resolved. Bottom line: no more nessus scan issues after these updates! But those still on older CF versions should still change the host element in that cfusion/lib/jetty.xml, as discussed above.

Comment by Charlie A.

Slight correction: I should have clarified that YES, if one is running CF2016 Enterprise (or Trial or Developer), and DOES enable the "enable monitoring server" option (on the Server Monitor>Monitoring Settings page in the CFadmin, then even CF 2016 after that update WILL listen on that port 500. I meant to say that it doesn't listen to that port by default (which was indeed the point of this bug fix). And so also, if one DOES enable that monitoring setting (to have the CFSM listen on that alternative port, which defaults to 5500), then one STILL would want to consider that modification to the jetty.xml for its HOST element.

Comment by Charlie A.

Ugh: two typos in that first paragraph. Rinsing and repeating: Slight correction: I should have clarified that YES, if one is running CF2016 Enterprise (or Trial or Developer), and DOES enable the "enable monitoring server" option (on the Server Monitor>Monitoring Settings page in the CFadmin), then even CF 2016 after that update WILL listen on that port 5500.

Comment by Charlie A.