[ClusterLabs] jquery in pcs package
Tomas Jelinek
tojeline at redhat.com
Thu Jul 2 09:52:43 EDT 2020
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 <akostocker at gmail.com> 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/
>
More information about the Users
mailing list