OpenSSL vulnerability in versions 3.0.0-3.0.6

On November 1st 2022, the OpenSSL project released version 3.0.7 to address two high severity vulnerabilities. For reference, see the OpenSSL Security Advisory.

OpenSSL is essentially the de-facto standard for implementing secure communications over the Internet. These vulnerabilities must be taken seriously, and this topic has received significant attention in the media resulting in our customers reaching out to us looking for guidance - and rightfully so.

This page contains our assessment of the impact to our customers and internal operations in the form of frequently asked questions.

We will update this page as new information is discovered.

Am I affected?

Possibly, please read on.

What should I do?

Ensure your bots are not running with a vulnerable version of OpenSSL. We'll do our best to take care of the rest.

Our product includes detection of the vulnerability starting from the following versions:

• Workforce Agent v1.2.54 / Agent Core v6.20.9
• Assistant v1.8.3
• Visual Studio Code extension v0.39.0
• RCC v11.30.0

If the Python environment contains a vulnerable version, RCC will print the following line:

How do I fix the vulnerability in practice?

In most cases, the vulnerable OpenSSL comes as a transitive dependency of dependencies specified in conda.yaml, for example, Python itself. The fixed OpenSSL version has already been published to upstream package repositories, and in most cases, environment rebuilds will resolve to the fixed version.

• Clear the local environment cache to get updated dependencies for the following runs.
• Run your robot or just rebuild the environment to get the new environment build
• If RCC output still contains the warning for a vulnerable version of OpenSSL, you need to update the dependencies in your conda.yaml
  • Most common libraries have already gotten needed updates
  • If you have private packages, post-install or pre-run scripts, you might still have dependencies that ultimately load a bad version of OpenSSL.
• If you want to ensure whether invalid versions are present when the robot runs, we have a helper keyword in rpaframework v19.1.0 under RPA.HTTP.Check Vulnerabilities.
  • You can add this at the beginning of your robot and decide what you want the robot to do in these cases.

What if I can not upgrade to OpenSSL v3.0.7?

This is a serious vulnerability and we strongly recommend everyone to upgrade. That being said, we understand and acknowledge it is not always practical to do so immediately.

If choosing not to upgrade for any reason, we recommend carefully evaluating the associated risks. Per our current assessment, this vulnerability does not immediately render typical well-designed automation deployments unsafe due to the following:

• Bots are almost exclusively acting as TLS clients, and therefore the primary concern is around the vulnerability of the client operation.
• For a vulnerable client to be exploited, it must connect to a malicious server. Most automation deployments are configured to connect to known, trusted servers. To exploit this vulnerability, the server or the network infrastructure would first need to be compromised to enable the attacker to place a maliciously crafted certificate for the client to see. However, it must be noted that having this vulnerability out there does make such attacks more appealing.
• In practice, even if a vulnerable client would connect to a malicious server, many operating systems have built-in protections for stack overflows and creating a practical exploit beyond denial of service (crash) may be very difficult. Due to this reason, the OpenSSL team reduced the severity from Critical to High as discussed on their blog.

On the other hand, if your bot is acting as a server or you are allowing end-users to pass in URLs the bot will connect to, the attack surface will be significantly broader and postponing the upgrade will significantly increase the risk posture.

What has Robocorp done so far?

• Assessed the impact to our product. See the bottom of the page for details per component.
• Updated RCC to issue a warning if the resulting Python environment has known vulnerabilities. This feature is present in v11.30.0 and later, see changelog for reference.
• We released updates to all our components with the updated RCC having the ability to warn about vulnerable environments.
• We released rpaframework v19.1.0 with the capability to detect and notify if the environment where the robot is running has a vulnerability.
• We initiated a rebuild of python environment caches used in Robocorp-Hosted Cloud Workers. Rebuild will result in the fixed version being installed into environments where OpenSSL dependency has not been explicitly pinned to one of the vulnerable versions via the dependency tree.

What is Robocorp going to do next?

• We are looking into possibilities to provide additional tooling to analyze the impact on customer deployments.
• We will continue to assess & monitor the situation.

Impact within Robocorp products

We have assessed each component of our product and concluded as follows:

• Robocorp Control Room
  • Control Room runs exclusively on AWS (mostly serverless), and per their statement AWS services are not affected apart from a couple of exceptions.
  • Robocorp-Hosted Cloud Containers run on ECS, which falls under one of the exceptions requiring specific action. All instances have been updated per instructions provided by AWS during November 2.
• RCC
  • RCC is implemented in Go language, which has its own TLS library and is thus not affected.
    • Golang team did publish a security update on Nov 1, but per their statement the fixes are unrelated.
  • Under the hood, most of the critical communications in our other applications are implemented via RCC.
• Workforce Agent
  • Workforce Agent is running on NodeJS 16, which has OpenSSL v1.1.x without the vulnerability.
• Assistant
  • Assistant is running on NodeJS 16, which has OpenSSL v1.1.x without the vulnerability.
• Visual Studio Code extension
  • The static Python environment used by the extensions contained vulnerable OpenSSL v3.0.5.
  • Version v0.39.0 released on November 2 fixes the issue.