Re: [ClusterLabs] jquery in pcs package
Firewalld's add-service (without zone definition) will add it on the default zone which by default is public. If you have public and private zones , and the cluster is supposed to communicate over the private VLAN, you can open the port only there. Best Regards, Strahil Nikolov На 2 юли 2020 г. 13:40:02 GMT+03:00, Tony Stocker написа: >On Wed, Jul 1, 2020 at 1:44 PM Tony Stocker >wrote: >> >> So, first question: is this jquery something that is maintained, >> promulgated by/with the Pacemaker installation? Or is this something >> special that Red Hat is doing when they package it? > >So, investigating the source code in GitHub, the inclusion of this >jquery is part of Pacemaker/pcs and related to the Web UI. So this >should be the proper forum to address it. > >> Second, if this is Pacemaker-maintained (not Red Hat) part of code, >is >> there a reason that it's such an old version, given that the current >> version is 3.5.0, is used? > >Based on the GitHub check-in date, it appears that this section of >code hasn't been updated in 7 years. > >> Finally, if this is Pacemaker-maintained (not Red Hat) part of code, >> where can I find the documentation regarding the patching that's been >> done to address the various cross-site scripting vulnerabilities? I'm >> working under the assumption that the binary has been patched and the >> vulnerabilities are no longer present, in which case I have to >> document it with security. Obviously if the code has not been patched >> and it's still vulnerable, that's a whole different issue. > >So, one would assume since there haven't been any updates to the code >that this code is indeed vulnerable to all the XSS vulnerabilities, >which is not good. Regardless of anything else below, does anyone know >if there are any plans to update this part of the code to deal with >these security issues? > >What appears to be worse is that this Web UI interface is not >optional, and runs on the communication port (default=2224) across all >interfaces on a system. So, even though I set up a cluster using host >names/addresses which are on a private lan, the security scanner tool >is still finding the Web UI running on port 2224 on the public IP >interface of the system. This can't be the correct/intended behavior, >can it? I'm thinking that this has to do with the setup step that I >see in pretty much all how-to documents that looks like this one from >the Red Hat 8 "Configuring and Maintaining High Availability Clusters" >document, section 4.7: > >"If you are running the firewalld daemon, execute the following >commands to enable the ports that are required by the Red Hat High >Availability Add-On. ># firewall-cmd --permanent --add-service=high-availability ># firewall-cmd --add-service=high-availability" > >Here is the description in the same document for Port 2224/tcp: >"Default pcsd port required on all nodes (needed by the pcsd Web UI >and required for node-to-node communication). You can configure the >pcsd port by means of the PCSD_PORT parameter in the >/etc/sysconfig/pcsd file. > >It is crucial to open port 2224 in such a way that pcs from any node >can talk to all nodes in the cluster, including itself. When using the >Booth cluster ticket manager or a quorum device you must open port >2224 on all related hosts, such as Booth arbiters or the quorum device >host. " > >Executing this command appears to add the 'high-availability' >"service" to all zones in firewalld, which I don't believe is needed, >or am I wrong? If you have nodes with multiple network interfaces (in >my test case each node is attached to 3 networks,) do the nodes have >to have pcsd access across all the networks? > >Even if I can mitigate things by only allowing 'high-availability' >service ports on a single, private LAN, is there any way to DISABLE >the Web UI so that it doesn't run at all? I don't use it, nor have any >intention of doing so, and having a separate, unmaintained (as in >patched for vulnerabilities) http service running on a 'random' port >is not something our project management, and certainly the security >division approves of doing. > >Thanks. >___ >Manage your subscription: >https://lists.clusterlabs.org/mailman/listinfo/users > >ClusterLabs home: https://www.clusterlabs.org/ ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] jquery in pcs package
On Thu, Jul 2, 2020 at 9:52 AM Tomas Jelinek wrote: > problem. We have been working on a new version of the web UI which will > be compatible with the newest libraries and will allow upgrading them > continuously. This is good news. Thanks. > > As has been pointed out in this thread, security tools may base > reporting issues only on libraries' version numbers. Yes, I'm not a fan of security 'tools' that merely read a version number and declare one guilty of having vulnerabilities based on that alone, unfortunately though that enlightened view is not shared by the troglodytes that populate most security scanning teams. > Running pcsd web UI is optional. It is enabled by default but it can be > easily and safely turned off. There is no negative impact on other pcs / > pcsd functionalities. If you turn the web UI off, pcsd will still run > and listen to network connections (port 2224 by default). However, all > requests against the web UI will result in a simple page saying the web > UI is not enabled and no jQuery library will be served. > > To turn the web UI off, set: > PCSD_DISABLE_GUI=true > in /etc/sysconfig/pcsd (/etc/default/pcsd or other location depending on > Linux distribution you are running) and restart pcsd service. This is excellent news! I appreciate this a great deal! > > In newer versions of pcsd, you may also configure addresses pcsd binds > to by setting PCSD_BIND_ADDR in the same file. Also extraordinarily helpful! I knew that there had to be a way to do this, but the various instruction sets and how-tos about using Pacemaker usually completely ignore these type of elements, and there wasn't much coming up with web searches on the topic (or my seartch terms were simply inappropriate.) But having this flexibility is excellent! Again, thanks for the instructions on this! > Regards, > Tomas Thanks very much! Tony ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] jquery in pcs package
Hello, Pcs team understand your concerns about jQuery bundled in pcs / pcsd. Unfortunately, it is not possible to upgrade this jQuery library to a newer version right now. We are, however, very well aware this is a problem. We have been working on a new version of the web UI which will be compatible with the newest libraries and will allow upgrading them continuously. In the meantime, we are monitoring security issues reported against jQuery. The fact there is a security issue in jQuery does not automatically mean pcsd web UI is affected. The issue may be related to a code which is not used by the pcsd web UI. In another instance, an issue has been reported to be found in a jQuery function which is actually not present in all the jQuery versions marked as affected by that issue. As has been pointed out in this thread, security tools may base reporting issues only on libraries' version numbers. Running pcsd web UI is optional. It is enabled by default but it can be easily and safely turned off. There is no negative impact on other pcs / pcsd functionalities. If you turn the web UI off, pcsd will still run and listen to network connections (port 2224 by default). However, all requests against the web UI will result in a simple page saying the web UI is not enabled and no jQuery library will be served. To turn the web UI off, set: PCSD_DISABLE_GUI=true in /etc/sysconfig/pcsd (/etc/default/pcsd or other location depending on Linux distribution you are running) and restart pcsd service. In newer versions of pcsd, you may also configure addresses pcsd binds to by setting PCSD_BIND_ADDR in the same file. You are of course free to configure your firewall to block access to pcsd's port as you see fit, e.g. not allowing access from public networks. Regards, Tomas Dne 02. 07. 20 v 12:40 Tony Stocker napsal(a): On Wed, Jul 1, 2020 at 1:44 PM Tony Stocker wrote: So, first question: is this jquery something that is maintained, promulgated by/with the Pacemaker installation? Or is this something special that Red Hat is doing when they package it? So, investigating the source code in GitHub, the inclusion of this jquery is part of Pacemaker/pcs and related to the Web UI. So this should be the proper forum to address it. Second, if this is Pacemaker-maintained (not Red Hat) part of code, is there a reason that it's such an old version, given that the current version is 3.5.0, is used? Based on the GitHub check-in date, it appears that this section of code hasn't been updated in 7 years. Finally, if this is Pacemaker-maintained (not Red Hat) part of code, where can I find the documentation regarding the patching that's been done to address the various cross-site scripting vulnerabilities? I'm working under the assumption that the binary has been patched and the vulnerabilities are no longer present, in which case I have to document it with security. Obviously if the code has not been patched and it's still vulnerable, that's a whole different issue. So, one would assume since there haven't been any updates to the code that this code is indeed vulnerable to all the XSS vulnerabilities, which is not good. Regardless of anything else below, does anyone know if there are any plans to update this part of the code to deal with these security issues? What appears to be worse is that this Web UI interface is not optional, and runs on the communication port (default=2224) across all interfaces on a system. So, even though I set up a cluster using host names/addresses which are on a private lan, the security scanner tool is still finding the Web UI running on port 2224 on the public IP interface of the system. This can't be the correct/intended behavior, can it? I'm thinking that this has to do with the setup step that I see in pretty much all how-to documents that looks like this one from the Red Hat 8 "Configuring and Maintaining High Availability Clusters" document, section 4.7: "If you are running the firewalld daemon, execute the following commands to enable the ports that are required by the Red Hat High Availability Add-On. # firewall-cmd --permanent --add-service=high-availability # firewall-cmd --add-service=high-availability" Here is the description in the same document for Port 2224/tcp: "Default pcsd port required on all nodes (needed by the pcsd Web UI and required for node-to-node communication). You can configure the pcsd port by means of the PCSD_PORT parameter in the /etc/sysconfig/pcsd file. It is crucial to open port 2224 in such a way that pcs from any node can talk to all nodes in the cluster, including itself. When using the Booth cluster ticket manager or a quorum device you must open port 2224 on all related hosts, such as Booth arbiters or the quorum device host. " Executing this command appears to add the 'high-availability' "service" to all zones in firewalld, which I don't believe is needed, or am I wrong? If you have nodes with multiple network in
Re: [ClusterLabs] jquery in pcs package
On Wed, Jul 1, 2020 at 1:44 PM Tony Stocker wrote: > > So, first question: is this jquery something that is maintained, > promulgated by/with the Pacemaker installation? Or is this something > special that Red Hat is doing when they package it? So, investigating the source code in GitHub, the inclusion of this jquery is part of Pacemaker/pcs and related to the Web UI. So this should be the proper forum to address it. > Second, if this is Pacemaker-maintained (not Red Hat) part of code, is > there a reason that it's such an old version, given that the current > version is 3.5.0, is used? Based on the GitHub check-in date, it appears that this section of code hasn't been updated in 7 years. > Finally, if this is Pacemaker-maintained (not Red Hat) part of code, > where can I find the documentation regarding the patching that's been > done to address the various cross-site scripting vulnerabilities? I'm > working under the assumption that the binary has been patched and the > vulnerabilities are no longer present, in which case I have to > document it with security. Obviously if the code has not been patched > and it's still vulnerable, that's a whole different issue. So, one would assume since there haven't been any updates to the code that this code is indeed vulnerable to all the XSS vulnerabilities, which is not good. Regardless of anything else below, does anyone know if there are any plans to update this part of the code to deal with these security issues? What appears to be worse is that this Web UI interface is not optional, and runs on the communication port (default=2224) across all interfaces on a system. So, even though I set up a cluster using host names/addresses which are on a private lan, the security scanner tool is still finding the Web UI running on port 2224 on the public IP interface of the system. This can't be the correct/intended behavior, can it? I'm thinking that this has to do with the setup step that I see in pretty much all how-to documents that looks like this one from the Red Hat 8 "Configuring and Maintaining High Availability Clusters" document, section 4.7: "If you are running the firewalld daemon, execute the following commands to enable the ports that are required by the Red Hat High Availability Add-On. # firewall-cmd --permanent --add-service=high-availability # firewall-cmd --add-service=high-availability" Here is the description in the same document for Port 2224/tcp: "Default pcsd port required on all nodes (needed by the pcsd Web UI and required for node-to-node communication). You can configure the pcsd port by means of the PCSD_PORT parameter in the /etc/sysconfig/pcsd file. It is crucial to open port 2224 in such a way that pcs from any node can talk to all nodes in the cluster, including itself. When using the Booth cluster ticket manager or a quorum device you must open port 2224 on all related hosts, such as Booth arbiters or the quorum device host. " Executing this command appears to add the 'high-availability' "service" to all zones in firewalld, which I don't believe is needed, or am I wrong? If you have nodes with multiple network interfaces (in my test case each node is attached to 3 networks,) do the nodes have to have pcsd access across all the networks? Even if I can mitigate things by only allowing 'high-availability' service ports on a single, private LAN, is there any way to DISABLE the Web UI so that it doesn't run at all? I don't use it, nor have any intention of doing so, and having a separate, unmaintained (as in patched for vulnerabilities) http service running on a 'random' port is not something our project management, and certainly the security division approves of doing. Thanks. ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] jquery in pcs package
I don't know if this is properly discussed here, or if I need to address it with Red Hat specifically. So, please bear with me if it's the latter and not the former. Running pacemaker + pcs on CentOS-8, installed via yum from the 'High Availability' repository. Versions: pacemaker (2.0.3-5.el8_2), pcs (0.10.4-6.el8_2). Today the security scanner complained about the 'jquery' version installed as part of the pcs package, stating that due to the jquery version (1.9.1 and 1.10.1) it was vulnerable to multiple cross-site scripting vulnerabilities. The binaries in question live here: /usr/lib/pcsd/public/js/jquery-1.9.1.min.js /usr/lib/pcsd/public/js/jquery-ui-1.10.1.custom.min.js As with most security tools, I imagine it's complaining solely based on version number rather than checking if the binary actually contains the vulnerabilities. So, first question: is this jquery something that is maintained, promulgated by/with the Pacemaker installation? Or is this something special that Red Hat is doing when they package it? Second, if this is Pacemaker-maintained (not Red Hat) part of code, is there a reason that it's such an old version, given that the current version is 3.5.0, is used? Finally, if this is Pacemaker-maintained (not Red Hat) part of code, where can I find the documentation regarding the patching that's been done to address the various cross-site scripting vulnerabilities? I'm working under the assumption that the binary has been patched and the vulnerabilities are no longer present, in which case I have to document it with security. Obviously if the code has not been patched and it's still vulnerable, that's a whole different issue. Thanks. ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
