A recent Scala vulnerability emerges

Last month a new vulnerability was discovered that affects several versions of http4s, a prominent Scala HTTP library for client and server applications. The vulnerability is of a high severity nature hence it poses substantial risks.  Therefore be sure to read on and find out what these risks are and how to safely resolve them.

CVE-2020-5280

Vulnerability Score: 7.5

Platform: Scala

Component: http4s versions

  • 0.8.0 – 0.18.25
  • 0.19.0
  • 0.20.0 – 0.20.19
  • 0.21.0 – 0.21.1

Http4s allows Scala developers to create native client and server applications while favouring the pure functional side of the programming language.

In versions prior to 0.18.26, 0.20.20 and 0.21.2, the library has been found to be prone to local file inclusion (LFI) vulnerabilities caused by an erroneous URI normalization process that takes place when requests are performed. URI normalization is a very common process.  For example, browsers and web crawlers use it to modify and standardise URIs in order to determine whether two syntactically different ones are equivalent.

In vulnerable http4s versions, a malicious request could allow a potential attacker to gain access to resources on the server filesystem. This is known as a local file inclusion attack and it can lead to remote code execution (RCE) vulnerabilities.

File inclusions are part of every advanced server side scripting language on the web. In addition to keeping web application’s code tidy and maintainable, they are also used to parse files (e.g. configuration files) from the file system to be evaluated in the application’s code. Issues arise when these are not properly implemented, thus making the system vulnerable to exploits.

A typical exploit scenario could be the following. Assume you modularise your app so that required modules are defined in separate files, which are included and interpreted through a function that allows to specify the path to said modules. If the appropriate security checks are not present, the attacker could specify the path to sensitive files (e.g. the passwd file which stores passwords on Unix systems) or even worse, inject malicious code on the server and specify the path to successfully perform arbitrary remote code execution. A relatively trivial way to do so could be by abusing the web app’s upload functionality to upload an image containing this malicious code in its source.

How to fix this issue?

The recommended course is to upgrade:

  • v0.18.26 (compatible with the 0.18.x series)
  • v0.20.20 (compatible with the 0.20.x series)
  • v0.21.2 (compatible with the 0.21.x series)

If you can not perform an upgrade due to compatibility issues, it is advised to temporarily replace FileService.scala, ResourceService.scala and WebjarService.scala in your project with their non-vulnerable versions from the appropriate release series specified above.

As they say, prevention is better than cure. Don’t delay! Take remedial actions as specified above now. Integrate your system with Meterian to be informed when similar vulnerabilities arise and eliminate possible threats!

A recent Scala vulnerability emerges

jQuery, Javascript vulnerability of the month

Artwork by Marco Sciortino

Here we are! Guess what’s vulnerable again?
On April 10th 2020 it was made public that a vulnerability has been exploited in the most popular Javascript library ever implemented: jQuery 3.4.1.

Why is jQuery 3.4.1 vulnerable?

Vulnerability score: 5
Platform: Javascript
Components: jQuery, all versions before 3.5.0

When jQuery is invoked, it reads the HTML document and returns requested fragments of it.
Now, while reading the document it might find that the one or more requested fragments are not in the correct format, so it tries to translate them. Although most of the times the translation is correctly performed, it’s been demonstrated that in particular cases the conversion (or parsing) could lead to an XSS cross-site scripting vulnerability.

An XSS cross-site scripting is a type of code vulnerability that allows attackers to insert malicious code into the web pages viewed by other users. It might be exploited to steal information such as access tokens or other sensitive information. This is what a criminal or Black Hat hacker would do.

This is what a criminal or Black Hat hacker would do. White Hat hackers, on the other hand, would behave ethically and use their software White Hat hackers, on the other hand, would behave ethically. Using their software engineering knowledge, White Hat hackers would show how to exploit a vulnerability: publish useful information about it to make sure both users and owners of the vulnerable library could take actions to prevent attacks.

What actions are required to safely update?

The first thing to know is that all the old versions of jQuery have some sort of vulnerability.  Up until April 10th, version 3.4.1 was the only safe version available.  Fortunately, the new minor release 3.5.0 has been published to fix the XSS security vulnerability.

As suggested in the jQuery release note, updating to this latest version might break your code as, to prevent the abuse of this vulnerability, the HTML element phrase is no longer converted.
Therefore, a code review might be in order.

There is a lot of time-consuming effort involved in staying on track with all the latest code vulnerabilities as they are discovered but, fortunately, Meterian can help you with that.

When added to the CI/CD pipeline of any application, Meterian will automatically detect such vulnerabilities, or even fix them for you, and it will help you avoid the risk of an attack before it becomes a problem.

Beat open source vulnerabilities with Meterian.

jQuery, Javascript vulnerability of the month