Docker azul/zulu-openjdk-debian:7u154-7.20.0.3

Vulnerabilities

319 via 509 paths

Dependencies

129

Source

Group 6 Copy Created with Sketch. Docker

Target OS

debian:9
Test your Docker Hub image against our market leading vulnerability database Sign up for free
Severity
  • 114
  • 103
  • 102
Status
  • 319
  • 0
  • 0
OS binaries
  • 215
  • 104

high severity

Arbitrary Code Injection

  • Vulnerable module: apt
  • Introduced through: apt@1.4.8 and apt/libapt-pkg5.0@1.4.8
  • Fixed in: 1.4.9

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* apt@1.4.8
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* apt/libapt-pkg5.0@1.4.8

Overview

Incorrect sanitation of the 302 redirect field in HTTP transport method of apt versions 1.4.8 and earlier can lead to content injection by a MITM attacker, potentially leading to remote code execution on the target machine.

References

high severity

Out-of-bounds Write

  • Vulnerable module: bzip2/libbz2-1.0
  • Introduced through: bzip2/libbz2-1.0@1.0.6-8.1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* bzip2/libbz2-1.0@1.0.6-8.1

Overview

BZ2_decompress in decompress.c in bzip2 through 1.0.6 has an out-of-bounds write when there are many selectors.

References

high severity

Out-of-bounds Write

  • Vulnerable module: cyrus-sasl2/libsasl2-2
  • Introduced through: cyrus-sasl2/libsasl2-2@2.1.27~101-g0780600+dfsg-3, cyrus-sasl2/libsasl2-modules@2.1.27~101-g0780600+dfsg-3 and others
  • Fixed in: 2.1.27~101-g0780600+dfsg-3+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* cyrus-sasl2/libsasl2-2@2.1.27~101-g0780600+dfsg-3
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* cyrus-sasl2/libsasl2-modules@2.1.27~101-g0780600+dfsg-3
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* cyrus-sasl2/libsasl2-modules-db@2.1.27~101-g0780600+dfsg-3

Overview

cyrus-sasl (aka Cyrus SASL) 2.1.27 has an out-of-bounds write leading to unauthenticated remote denial-of-service in OpenLDAP via a malformed LDAP packet. The OpenLDAP crash is ultimately caused by an off-by-one error in _sasl_add_string in common.c in cyrus-sasl.

References

high severity

Out-of-bounds Read

  • Vulnerable module: expat/libexpat1
  • Introduced through: expat/libexpat1@2.2.0-2+deb9u1
  • Fixed in: 2.2.0-2+deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* expat/libexpat1@2.2.0-2+deb9u1

Overview

In libexpat before 2.2.8, crafted XML input could fool the parser into changing from DTD parsing to document parsing too early; a consecutive call to XML_GetCurrentLineNumber (or XML_GetCurrentColumnNumber) then resulted in a heap-based buffer over-read.

References

high severity

XML External Entity (XXE) Injection

  • Vulnerable module: expat/libexpat1
  • Introduced through: expat/libexpat1@2.2.0-2+deb9u1
  • Fixed in: 2.2.0-2+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* expat/libexpat1@2.2.0-2+deb9u1

Overview

In libexpat in Expat before 2.2.7, XML input including XML names that contain a large number of colons could make the XML parser consume a high amount of RAM and CPU resources while processing (enough to be usable for denial-of-service attacks).

References

high severity

Information Exposure

  • Vulnerable module: gcc-6/gcc-6-base
  • Introduced through: gcc-6/gcc-6-base@6.3.0-18, gcc-6/libgcc1@1:6.3.0-18 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gcc-6/gcc-6-base@6.3.0-18
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gcc-6/libgcc1@1:6.3.0-18
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gcc-6/libstdc++6@6.3.0-18

Overview

stack_protect_prologue in cfgexpand.c and stack_protect_epilogue in function.c in GNU Compiler Collection (GCC) 4.1 through 8 (under certain circumstances) generate instruction sequences when targeting ARM targets that spill the address of the stack protector guard, which allows an attacker to bypass the protection of -fstack-protector, -fstack-protector-all, -fstack-protector-strong, and -fstack-protector-explicit against stack overflow by controlling what the stack canary is compared against.

References

high severity

Improper Data Handling

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

In the GNU C Library (aka glibc or libc6) before 2.28, parse_reg_exp in posix/regcomp.c misparses alternatives, which allows attackers to cause a denial of service (assertion failure and application exit) or trigger an incorrect result by attempting a regular-expression match.

References

high severity

Missing Release of Resource after Effective Lifetime

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others
  • Fixed in: 2.24-11+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

A memory leak in glibc 2.1.1 (released on May 24, 1999) can be reached and amplified through the LD_HWCAP_MASK environment variable. Please note that many versions of glibc are not vulnerable to this issue if patched for CVE-2017-1000366.

References

high severity

Out-of-Bounds

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others
  • Fixed in: 2.24-11+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

The glob function in glob.c in the GNU C Library (aka glibc or libc6) before 2.27 contains a buffer overflow during unescaping of user names with the ~ operator.

References

high severity

Out-of-Bounds

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others
  • Fixed in: 2.24-11+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

A buffer overflow in glibc 2.5 (released on September 29, 2006) and can be triggered through the LD_LIBRARY_PATH environment variable. Please note that many versions of glibc are not vulnerable to this issue if patched for CVE-2017-1000366.

References

high severity

Out-of-Bounds

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others
  • Fixed in: 2.24-11+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

The GNU C Library (aka glibc or libc6) before 2.27 contains an off-by-one error leading to a heap-based buffer overflow in the glob function in glob.c, related to the processing of home directories using the ~ operator followed by a long string.

References

high severity

Out-of-Bounds

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others
  • Fixed in: 2.24-11+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

An SSE2-optimized memmove implementation for i386 in sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S in the GNU C Library (aka glibc or libc6) 2.21 through 2.27 does not correctly perform the overlapping memory check if the source memory range spans the middle of the address space, resulting in corrupt data being produced by the copy operation. This may disclose information to context-dependent attackers, or result in a denial of service, or, possibly, code execution.

References

high severity

Out-of-bounds Read

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

In the GNU C Library (aka glibc or libc6) through 2.29, proceed_next_node in posix/regexec.c has a heap-based buffer over-read via an attempted case-insensitive regular-expression match.

References

high severity

Out-of-bounds Write

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

An integer overflow in the implementation of the posix_memalign in memalign functions in the GNU C Library (aka glibc or libc6) 2.26 and earlier could cause these functions to return a pointer to a heap area that is too small, potentially leading to heap corruption.

References

high severity

Out-of-bounds Write

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others
  • Fixed in: 2.24-11+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

stdlib/canonicalize.c in the GNU C Library (aka glibc or libc6) 2.27 and earlier, when processing very long pathname arguments to the realpath function, could encounter an integer overflow on 32-bit architectures, leading to a stack-based buffer overflow and, potentially, arbitrary code execution.

References

high severity

Out-of-bounds Write

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

In glibc 2.26 and earlier there is confusion in the usage of getcwd() by realpath() which can be used to write before the destination buffer leading to a buffer underflow and potential code execution.

References

high severity

Out-of-bounds Write

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

The malloc implementation in the GNU C Library (aka glibc or libc6), from version 2.24 to 2.26 on powerpc, and only in version 2.26 on i386, did not properly handle malloc calls with arguments close to SIZE_MAX and could return a pointer to a heap region that is smaller than requested, eventually leading to heap corruption.

References

high severity

Out-of-bounds Write

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others
  • Fixed in: 2.24-11+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

An AVX-512-optimized implementation of the mempcpy function in the GNU C Library (aka glibc or libc6) 2.27 and earlier may write data beyond the target buffer, leading to a buffer overflow in __mempcpy_avx512_no_vzeroupper.

References

high severity

Out-of-bounds Write

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

An out-of-bounds write vulnerability was found in glibc before 2.31 when handling signal trampolines on PowerPC. Specifically, the backtrace function did not properly check the array bounds when storing the frame address, resulting in a denial of service or potential code execution. The highest threat from this vulnerability is to system availability.

References

high severity

Reachable Assertion

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

Affected versions of this package are vulnerable to Reachable Assertion. The iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid input sequences in the ISO-2022-JP-3 encoding, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.

Remediation

There is no fixed version for glibc.

References

high severity

Untrusted Search Path

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others
  • Fixed in: 2.24-11+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

elf/dl-load.c in the GNU C Library (aka glibc or libc6) 2.19 through 2.26 mishandles RPATH and RUNPATH containing $ORIGIN for a privileged (setuid or AT_SECURE) program, which allows local users to gain privileges via a Trojan horse library in the current working directory, related to the fillin_rpath and decompose_rpath functions. This is associated with misinterpretion of an empty RPATH/RUNPATH token as the "./" directory. NOTE: this configuration of RPATH/RUNPATH for a privileged program is apparently very uncommon; most likely, no such program is shipped with any common Linux distribution.

References

high severity

Use After Free

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

A use-after-free vulnerability introduced in glibc upstream version 2.14 was found in the way the tilde expansion was carried out. Directory paths containing an initial tilde followed by a valid username were affected by this issue. A local attacker could exploit this flaw by creating a specially crafted path that, when processed by the glob function, would potentially lead to arbitrary code execution. This was fixed in version 2.32.

References

high severity

Cross-site Request Forgery (CSRF)

  • Vulnerable module: gnupg2/dirmngr
  • Introduced through: gnupg2/dirmngr@2.1.18-8~deb9u1, gnupg2/gnupg@2.1.18-8~deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnupg2/dirmngr@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnupg2/gnupg@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnupg2/gnupg-agent@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnupg2/gnupg-l10n@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnupg2/gpgv@2.1.18-8~deb9u1

Overview

GnuPG version 2.1.12 - 2.2.11 contains a Cross ite Request Forgery (CSRF) vulnerability in dirmngr that can result in Attacker controlled CSRF, Information Disclosure, DoS. This attack appear to be exploitable via Victim must perform a WKD request, e.g. enter an email address in the composer window of Thunderbird/Enigmail. This vulnerability appears to have been fixed in after commit 4a4bb874f63741026bd26264c43bb32b1099f060.

References

high severity

Use of Incorrectly-Resolved Name or Reference

  • Vulnerable module: gnupg2/dirmngr
  • Introduced through: gnupg2/dirmngr@2.1.18-8~deb9u1, gnupg2/gnupg@2.1.18-8~deb9u1 and others
  • Fixed in: 2.1.18-8~deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnupg2/dirmngr@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnupg2/gnupg@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnupg2/gnupg-agent@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnupg2/gnupg-l10n@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnupg2/gpgv@2.1.18-8~deb9u1

Overview

mainproc.c in GnuPG before 2.2.8 mishandles the original filename during decryption and verification actions, which allows remote attackers to spoof the output that GnuPG sends on file descriptor 2 to other programs that use the "--status-fd 2" option. For example, the OpenPGP data might represent an original filename that contains line feed characters in conjunction with GOODSIG or VALIDSIG status codes.

References

high severity

Double Free

  • Vulnerable module: gnutls28/libgnutls30
  • Introduced through: gnutls28/libgnutls30@3.5.8-5+deb9u3
  • Fixed in: 3.5.8-5+deb9u5

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnutls28/libgnutls30@3.5.8-5+deb9u3

Overview

A vulnerability was found in gnutls versions from 3.5.8 before 3.6.7. A memory corruption (double free) vulnerability in the certificate verification API. Any client or server application that verifies X.509 certificates with GnuTLS 3.5.8 or later is affected.

References

high severity

Buffer Overflow

  • Vulnerable module: inetutils/inetutils-ping
  • Introduced through: inetutils/inetutils-ping@2:1.9.4-2+b1
  • Fixed in: 2:1.9.4-2+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* inetutils/inetutils-ping@2:1.9.4-2+b1

Overview

utility.c in telnetd in netkit telnet through 0.17 allows remote attackers to execute arbitrary code via short writes or urgent data, because of a buffer overflow involving the netclear and nextitem functions.

References

high severity

Out-of-bounds Read

  • Vulnerable module: libbsd/libbsd0
  • Introduced through: libbsd/libbsd0@0.8.3-1
  • Fixed in: 0.8.3-1+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libbsd/libbsd0@0.8.3-1

Overview

nlist.c in libbsd before 0.10.0 has an out-of-bounds read during a comparison for a symbol name from the string table (strtab).

References

high severity

Integer Overflow or Wraparound

  • Vulnerable module: libidn/libidn11
  • Introduced through: libidn/libidn11@1.33-1
  • Fixed in: 1.33-1+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libidn/libidn11@1.33-1

Overview

Integer overflow in the decode_digit function in puny_decode.c in Libidn2 before 2.0.4 allows remote attackers to cause a denial of service or possibly have unspecified other impact.

References

high severity

Improper Input Validation

  • Vulnerable module: libpng1.6/libpng16-16
  • Introduced through: libpng1.6/libpng16-16@1.6.28-1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libpng1.6/libpng16-16@1.6.28-1

Overview

libpng before 1.6.32 does not properly check the length of chunks against the user limit.

References

high severity

NULL Pointer Dereference

  • Vulnerable module: libtasn1-6
  • Introduced through: libtasn1-6@4.10-1.1
  • Fixed in: 4.10-1.1+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libtasn1-6@4.10-1.1

Overview

The _asn1_check_identifier function in GNU Libtasn1 through 4.12 causes a NULL pointer dereference and crash when reading crafted input that triggers assignment of a NULL value within an asn1_node structure. It may lead to a remote denial of service attack.

References

high severity

Uncontrolled Recursion

  • Vulnerable module: libtasn1-6
  • Introduced through: libtasn1-6@4.10-1.1
  • Fixed in: 4.10-1.1+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libtasn1-6@4.10-1.1

Overview

An issue was discovered in the _asn1_decode_simple_ber function in decoding.c in GNU Libtasn1 before 4.13. Unlimited recursion in the BER decoder leads to stack exhaustion and DoS.

References

high severity

Improper Input Validation

  • Vulnerable module: libx11/libx11-6
  • Introduced through: libx11/libx11-6@2:1.6.4-3 and libx11/libx11-data@2:1.6.4-3
  • Fixed in: 2:1.6.4-3+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libx11/libx11-data@2:1.6.4-3

Overview

An issue was discovered in XListExtensions in ListExt.c in libX11 through 1.6.5. A malicious server can send a reply in which the first string overflows, causing a variable to be set to NULL that will be freed later on, leading to DoS (segmentation fault).

References

high severity

Integer Overflow or Wraparound

  • Vulnerable module: libx11/libx11-6
  • Introduced through: libx11/libx11-6@2:1.6.4-3 and libx11/libx11-data@2:1.6.4-3
  • Fixed in: 2:1.6.4-3+deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libx11/libx11-data@2:1.6.4-3

Overview

Affected versions of this package are vulnerable to Integer Overflow or Wraparound. An integer overflow vulnerability leading to a double-free was found in libX11. This flaw allows a local privileged attacker to cause an application compiled with libX11 to crash, or in some cases, result in arbitrary code execution. The highest threat from this flaw is to confidentiality, integrity as well as system availability.

Remediation

Upgrade libx11 to version or higher.

References

high severity

Off-by-one Error

  • Vulnerable module: libx11/libx11-6
  • Introduced through: libx11/libx11-6@2:1.6.4-3 and libx11/libx11-data@2:1.6.4-3
  • Fixed in: 2:1.6.4-3+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libx11/libx11-data@2:1.6.4-3

Overview

An issue was discovered in libX11 through 1.6.5. The function XListExtensions in ListExt.c is vulnerable to an off-by-one error caused by malicious server responses, leading to DoS or possibly unspecified other impact.

References

high severity

Out-of-bounds Write

  • Vulnerable module: libx11/libx11-6
  • Introduced through: libx11/libx11-6@2:1.6.4-3 and libx11/libx11-data@2:1.6.4-3
  • Fixed in: 2:1.6.4-3+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libx11/libx11-data@2:1.6.4-3

Overview

An issue was discovered in libX11 through 1.6.5. The function XListExtensions in ListExt.c interprets a variable as signed instead of unsigned, resulting in an out-of-bounds write (of up to 128 bytes), leading to DoS or remote code execution.

References

high severity

CVE-2018-10754

  • Vulnerable module: ncurses/libncursesw5
  • Introduced through: ncurses/libncursesw5@6.0+20161126-1+deb9u1, ncurses/libtinfo5@6.0+20161126-1+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* ncurses/libncursesw5@6.0+20161126-1+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* ncurses/libtinfo5@6.0+20161126-1+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* ncurses/ncurses-base@6.0+20161126-1+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* ncurses/ncurses-bin@6.0+20161126-1+deb9u1

Overview

In ncurses before 6.1.20180414, there is a NULL Pointer Dereference in the _nc_parse_entry function of tinfo/parse_entry.c. It could lead to a remote denial of service if the terminfo library code is used to process untrusted terminfo data in which a use-name is invalid syntax. The product proceeds to the dereference code path even after a "dubious character `[' in name or alias field" detection.

References

high severity

Out-of-Bounds

  • Vulnerable module: ncurses/libncursesw5
  • Introduced through: ncurses/libncursesw5@6.0+20161126-1+deb9u1, ncurses/libtinfo5@6.0+20161126-1+deb9u1 and others
  • Fixed in: 6.0+20161126-1+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* ncurses/libncursesw5@6.0+20161126-1+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* ncurses/libtinfo5@6.0+20161126-1+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* ncurses/ncurses-base@6.0+20161126-1+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* ncurses/ncurses-bin@6.0+20161126-1+deb9u1

Overview

Stack-based buffer overflow in the _nc_write_entry function in tinfo/write_entry.c in ncurses 6.0 allows attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted terminfo file, as demonstrated by tic.

References

high severity

Buffer Overflow

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Buffer Overflow. A flaw was found in the boundary checks in the java.nio buffer classes in the Libraries component of OpenJDK, where it is bypassed in certain cases. This flaw allows an untrusted Java application or applet o bypass Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: RMI). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Hotspot). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Libraries). Difficult to exploit vulnerability allows unauthenticated attacker with network access via Kerberos to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded. Note: Applies to the Java SE Kerberos client.

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: JNDI). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, JRockit, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded, JRockit. Note: This vulnerability applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: JMX). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java SE Embedded, JRockit accessible data as well as unauthorized access to critical data or complete access to all Java SE, Java SE Embedded, JRockit accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Security). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java SE Embedded, JRockit accessible data as well as unauthorized access to critical data or complete access to all Java SE, Java SE Embedded, JRockit accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, JRockit component of Oracle Java SE (subcomponent: Security). Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Java SE, JRockit executes to compromise Java SE, JRockit. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, JRockit, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE, JRockit. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.181, 8.0.171 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Hotspot). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.181, 8.0.171 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE component of Oracle Java SE (subcomponent: Java DB). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. While the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVE-2018-2938 addresses CVE-2018-1313.

Remediation

Upgrade openjdk-jre to version 7.0.191, 8.0.181 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE component of Oracle Java SE (subcomponent: JavaFX). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.191, 8.0.181 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE component of Oracle Java SE (subcomponent: Windows DLL). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.191, 8.0.181 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_201

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: JNDI). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, JRockit, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded, JRockit. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g. code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g. through a web service which supplies data to the APIs.

Remediation

Upgrade openjdk-jre to version 7.0.201, 8.0.191, 11.0.1 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_201

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Hotspot). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g. code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g. code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.201, 8.0.191 or higher.

References

high severity

Improper Input Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Input Validation in the way the readObject() method of the MethodType class in the Libraries component of OpenJDK checked argument types. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

high severity

Improper Security Check

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Security Check in the TLS/SSL implementation in the JSSE component of OpenJDK, where it did not properly handle application data packets received before the handshake completion. This flaw allowed unauthorized injection of data at the beginning of a TLS session.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

high severity

Modification of Assumed-Immutable Data (MAID)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Modification of Assumed-Immutable Data (MAID) via serialization filter changes via jdk.serialFilter property modification.

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

high severity

NULL pointer dereference

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to NULL pointer dereference via the DrawGlyphList class in the 2D component in OpenJDK. A specially crafted font file could use this flaw to cause a Java application to crash.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

high severity

Sandbox Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Sandbox Bypass. It was discovered that the boundary checks in the java.nio.Buffer class in the Libraries component of OpenJDK could have been bypassed when class instance was accessed concurrently. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

high severity

Sandbox Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Sandbox Bypass. A flaw was found in the way the imaging library in the 2D component of OpenJDK performed affine transformations of images. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

high severity

Access of Resource Using Incompatible Type ('Type Confusion')

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to Access of Resource Using Incompatible Type ('Type Confusion'). A flaw was discovered in ldap_X509dn2bv in OpenLDAP before 2.4.57 leading to a slapd crash in the X.509 DN parsing in ad_keystring, resulting in denial of service.

Remediation

Upgrade openldap to version or higher.

References

high severity

CVE-2020-36226

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to CVE-2020-36226. A flaw was discovered in OpenLDAP before 2.4.57 leading to a memch->bv_len miscalculation and slapd crash in the saslAuthzTo processing, resulting in denial of service.

Remediation

Upgrade openldap to version or higher.

References

high severity

Double Free

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to Double Free. A flaw was discovered in OpenLDAP before 2.4.57 leading to a double free and slapd crash in the saslAuthzTo processing, resulting in denial of service.

Remediation

Upgrade openldap to version or higher.

References

high severity

Improper Authentication

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

An issue was discovered in OpenLDAP 2.x before 2.4.48. When using SASL authentication and session encryption, and relying on the SASL security layers in slapd access controls, it is possible to obtain access that would otherwise be denied via a simple bind for any identity covered in those ACLs. After the first SASL bind is completed, the sasl_ssf value is retained for all new non-SASL connections. Depending on the ACL configuration, this can affect different types of operations (searches, modifications, etc.). In other words, a successful authorization step completed by one user affects the authorization requirement for a different user.

References

high severity

Integer Underflow

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to Integer Underflow. An integer underflow was discovered in OpenLDAP before 2.4.57 leading to slapd crashes in the Certificate Exact Assertion processing, resulting in denial of service (schema_init.c serialNumberAndIssuerCheck).

Remediation

Upgrade openldap to version or higher.

References

high severity

Integer Underflow

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to Integer Underflow. An integer underflow was discovered in OpenLDAP before 2.4.57 leading to a slapd crash in the Certificate List Exact Assertion processing, resulting in denial of service.

Remediation

Upgrade openldap to version or higher.

References

high severity

Loop with Unreachable Exit Condition ('Infinite Loop')

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to Loop with Unreachable Exit Condition ('Infinite Loop'). A flaw was discovered in OpenLDAP before 2.4.57 leading to an infinite loop in slapd with the cancel_extop Cancel operation, resulting in denial of service.

Remediation

Upgrade openldap to version or higher.

References

high severity

NULL Pointer Dereference

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u5

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to NULL Pointer Dereference. A NULL pointer dereference was found in OpenLDAP server and was fixed in openldap 2.4.55, during a request for renaming RDNs. An unauthenticated attacker could remotely crash the slapd process by sending a specially crafted request, causing a Denial of Service.

Remediation

Upgrade openldap to version or higher.

References

high severity

Out-of-bounds Read

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to Out-of-bounds Read. A flaw was discovered in OpenLDAP before 2.4.57 leading to a slapd crash in the Values Return Filter control handling, resulting in denial of service (double free and out-of-bounds read).

Remediation

Upgrade openldap to version or higher.

References

high severity

Reachable Assertion

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to Reachable Assertion. A flaw was discovered in OpenLDAP before 2.4.57 leading to an assertion failure in slapd in the saslAuthzTo validation, resulting in denial of service.

Remediation

Upgrade openldap to version or higher.

References

high severity

Reachable Assertion

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to Reachable Assertion. A flaw was discovered in OpenLDAP before 2.4.57 leading in an assertion failure in slapd in the X.509 DN parsing in decode.c ber_next_element, resulting in denial of service.

Remediation

Upgrade openldap to version or higher.

References

high severity
new

Reachable Assertion

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u8

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to Reachable Assertion. In OpenLDAP through 2.4.57 and 2.5.x through 2.5.1alpha, an assertion failure in slapd can occur in the issuerAndThisUpdateCheck function via a crafted packet, resulting in a denial of service (daemon exit) via a short timestamp. This is related to schema_init.c and checkTime.

Remediation

Upgrade openldap to version or higher.

References

high severity

Release of Invalid Pointer or Reference

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

Affected versions of this package are vulnerable to Release of Invalid Pointer or Reference. A flaw was discovered in OpenLDAP before 2.4.57 leading to an invalid pointer free and slapd crash in the saslAuthzTo processing, resulting in denial of service.

Remediation

Upgrade openldap to version or higher.

References

high severity

Resource Exhaustion

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

In filter.c in slapd in OpenLDAP before 2.4.50, LDAP search filters with nested boolean expressions can result in denial of service (daemon crash).

References

high severity

Cryptographic Issues

  • Vulnerable module: openssl/libssl1.1
  • Introduced through: openssl/libssl1.1@1.1.0f-3+deb9u1
  • Fixed in: 1.1.0k-1~deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openssl/libssl1.1@1.1.0f-3+deb9u1

Overview

ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for every encryption operation. RFC 7539 specifies that the nonce value (IV) should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and front pads the nonce with 0 bytes if it is less than 12 bytes. However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored. It is a requirement of using this cipher that nonce values are unique. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. If an application changes the default nonce length to be longer than 12 bytes and then makes a change to the leading bytes of the nonce expecting the new value to be a new unique nonce then such an application could inadvertently encrypt messages with a reused nonce. Additionally the ignored bytes in a long nonce are not covered by the integrity guarantee of this cipher. Any application that relies on the integrity of these ignored leading bytes of a long nonce may be further affected. Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe because no such use sets such a long nonce value. However user applications that use this cipher directly and set a non-default nonce length to be longer than 12 bytes may be vulnerable. OpenSSL versions 1.1.1 and 1.1.0 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. Fixed in OpenSSL 1.1.1c (Affected 1.1.1-1.1.1b). Fixed in OpenSSL 1.1.0k (Affected 1.1.0-1.1.0j).

References

high severity
new

Integer Overflow or Wraparound

  • Vulnerable module: openssl/libssl1.1
  • Introduced through: openssl/libssl1.1@1.1.0f-3+deb9u1
  • Fixed in: 1.1.0l-1~deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openssl/libssl1.1@1.1.0f-3+deb9u1

Overview

Affected versions of this package are vulnerable to Integer Overflow or Wraparound. Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).

Remediation

Upgrade openssl to version or higher.

References

high severity
new

Integer Overflow or Wraparound

  • Vulnerable module: openssl/libssl1.1
  • Introduced through: openssl/libssl1.1@1.1.0f-3+deb9u1
  • Fixed in: 1.1.0l-1~deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openssl/libssl1.1@1.1.0f-3+deb9u1

Overview

Affected versions of this package are vulnerable to Integer Overflow or Wraparound. The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).

Remediation

Upgrade openssl to version or higher.

References

high severity

Key Management Errors

  • Vulnerable module: openssl/libssl1.1
  • Introduced through: openssl/libssl1.1@1.1.0f-3+deb9u1
  • Fixed in: 1.1.0j-1~deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openssl/libssl1.1@1.1.0f-3+deb9u1

Overview

During key agreement in a TLS handshake using a DH(E) based ciphersuite a malicious server can send a very large prime value to the client. This will cause the client to spend an unreasonably long period of time generating a key for this prime resulting in a hang until the client has finished. This could be exploited in a Denial Of Service attack. Fixed in OpenSSL 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev (Affected 1.0.2-1.0.2o).

References

high severity

Integer Overflow or Wraparound

  • Vulnerable module: p11-kit/libp11-kit0
  • Introduced through: p11-kit/libp11-kit0@0.23.3-2
  • Fixed in: 0.23.3-2+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* p11-kit/libp11-kit0@0.23.3-2

Overview

Affected versions of this package are vulnerable to Integer Overflow or Wraparound. An issue was discovered in p11-kit 0.21.1 through 0.23.21. Multiple integer overflows have been discovered in the array allocations in the p11-kit library and the p11-kit list command, where overflow checks are missing before calling realloc or calloc.

Remediation

Upgrade p11-kit to version or higher.

References

high severity

Buffer Overflow

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* perl/perl-base@5.24.1-3+deb9u2

Overview

Affected versions of this package are vulnerable to Buffer Overflow regcomp.c in Perl before 5.30.3 allows a buffer overflow via a crafted regular expression because of recursive S_study_chunk calls.

Remediation

Upgrade perl to version or higher.

References

high severity

Integer Overflow or Wraparound

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* perl/perl-base@5.24.1-3+deb9u2

Overview

Affected versions of this package are vulnerable to Integer Overflow or Wraparound. Perl before 5.30.3 has an integer overflow related to mishandling of a "PL_regkind[OP(n)] == NOTHING" situation. A crafted regular expression could lead to malformed bytecode with a possibility of instruction injection.

Remediation

Upgrade perl to version or higher.

References

high severity

Link Following

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* perl/perl-base@5.24.1-3+deb9u2

Overview

In Perl through 5.26.2, the Archive::Tar module allows remote attackers to bypass a directory-traversal protection mechanism, and overwrite arbitrary files, via an archive file containing a symlink and a regular file with the same name.

References

high severity

Out-of-Bounds

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u5

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* perl/perl-base@5.24.1-3+deb9u2

high severity

Out-of-Bounds

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u5

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* perl/perl-base@5.24.1-3+deb9u2

high severity

Out-of-bounds Read

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u5

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* perl/perl-base@5.24.1-3+deb9u2

high severity

Out-of-bounds Read

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* perl/perl-base@5.24.1-3+deb9u2

Overview

An issue was discovered in Perl 5.22 through 5.26. Matching a crafted locale dependent regular expression can cause a heap-based buffer over-read and potentially information disclosure.

References

high severity

Out-of-bounds Write

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u5

high severity

Out-of-bounds Write

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* perl/perl-base@5.24.1-3+deb9u2

Overview

Heap-based buffer overflow in the pack function in Perl before 5.26.2 allows context-dependent attackers to execute arbitrary code via a large item count.

References

high severity

Out-of-bounds Write

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* perl/perl-base@5.24.1-3+deb9u2

Overview

An issue was discovered in Perl 5.18 through 5.26. A crafted regular expression can cause a heap-based buffer overflow, with control over the bytes written.

References

high severity

Out-of-bounds Write

  • Vulnerable module: perl/perl-base
  • Introduced through: perl/perl-base@5.24.1-3+deb9u2
  • Fixed in: 5.24.1-3+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* perl/perl-base@5.24.1-3+deb9u2

Overview

Affected versions of this package are vulnerable to Out-of-bounds Write. Perl before 5.30.3 on 32-bit platforms allows a heap-based buffer overflow because nested regular expression quantifiers have an integer overflow.

Remediation

Upgrade perl to version or higher.

References

high severity

Arbitrary Code Injection

  • Vulnerable module: sensible-utils
  • Introduced through: sensible-utils@0.0.9
  • Fixed in: 0.0.9+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sensible-utils@0.0.9

Overview

sensible-browser in sensible-utils before 0.0.11 does not validate strings before launching the program specified by the BROWSER environment variable, which allows remote attackers to conduct argument-injection attacks via a crafted URL, as demonstrated by a --proxy-pac-file argument.

References

high severity

Out-of-Bounds

  • Vulnerable module: shadow/login
  • Introduced through: shadow/login@1:4.4-4.1 and shadow/passwd@1:4.4-4.1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* shadow/login@1:4.4-4.1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* shadow/passwd@1:4.4-4.1

Overview

In shadow before 4.5, the newusers tool could be made to manipulate internal data structures in ways unintended by the authors. Malformed input may lead to crashes (with a buffer overflow or other memory corruption) or other unspecified behaviors. This crosses a privilege boundary in, for example, certain web-hosting environments in which a Control Panel allows an unprivileged user account to create subaccounts.

References

high severity

Improper Handling of Exceptional Conditions

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

selectExpander in select.c in SQLite 3.30.1 proceeds with WITH stack unwinding even after a parsing error.

References

high severity

Improper Input Validation

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

SQLite through 3.31.1 allows attackers to cause a denial of service (segmentation fault) via a malformed window-function query because the AggInfo object's initialization is mishandled.

References

high severity

Integer Overflow or Wraparound

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

SQLite before 3.25.3, when the FTS3 extension is enabled, encounters an integer overflow (and resultant buffer overflow) for FTS3 queries that occur after crafted changes to FTS3 shadow tables, allowing remote attackers to execute arbitrary code by leveraging the ability to run arbitrary SQL statements (such as in certain WebSQL use cases), aka Magellan.

References

high severity

Integer Overflow or Wraparound

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

SQLite before 3.25.3, when the FTS3 extension is enabled, encounters an integer overflow (and resultant buffer overflow) for FTS3 queries in a "merge" operation that occurs after crafted changes to FTS3 shadow tables, allowing remote attackers to execute arbitrary code by leveraging the ability to run arbitrary SQL statements (such as in certain WebSQL use cases). This is a different vulnerability than CVE-2018-20346.

References

high severity

NULL Pointer Dereference

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

In SQLite through 3.22.0, databases whose schema is corrupted using a CREATE TABLE AS statement could cause a NULL pointer dereference, related to build.c and prepare.c.

References

high severity

NULL Pointer Dereference

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

In SQLite 3.27.2, interleaving reads and writes in a single transaction with an fts5 virtual table will lead to a NULL Pointer Dereference in fts5ChunkIterate in sqlite3.c. This is related to ext/fts5/fts5_hash.c and ext/fts5/fts5_index.c.

References

high severity

Out-of-bounds Read

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

The getNodeSize function in ext/rtree/rtree.c in SQLite through 3.19.3, as used in GDAL and other products, mishandles undersized RTree blobs in a crafted database, leading to a heap-based buffer over-read or possibly unspecified other impact.

References

high severity

Out-of-bounds Read

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

In SQLite 3.27.2, running fts5 prefix queries inside a transaction could trigger a heap-based buffer over-read in fts5HashEntrySort in sqlite3.c, which may lead to an information leak. This is related to ext/fts5/fts5_hash.c.

References

high severity

Out-of-bounds Read

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

high severity

Out-of-bounds Read

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

Affected versions of this package are vulnerable to Out-of-bounds Read. An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 13.5 and iPadOS 13.5, macOS Catalina 10.15.5, tvOS 13.4.5, watchOS 6.2.5, iTunes 12.10.7 for Windows, iCloud for Windows 11.2, iCloud for Windows 7.19. A malicious application may cause a denial of service or potentially disclose memory contents.

Remediation

There is no fixed version for sqlite3.

References

high severity

Out-of-bounds Write

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

Integer overflow in SQLite via WebSQL in Google Chrome prior to 74.0.3729.131 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

References

high severity

Use After Free

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

Affected versions of this package are vulnerable to Use After Free ext/fts3/fts3.c in SQLite before 3.32.0 has a use-after-free in fts3EvalNextRow, related to the snippet feature.

Remediation

Upgrade sqlite3 to version or higher.

References

high severity

Use After Free

  • Vulnerable module: sqlite3/libsqlite3-0
  • Introduced through: sqlite3/libsqlite3-0@3.16.2-5
  • Fixed in: 3.16.2-5+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* sqlite3/libsqlite3-0@3.16.2-5

Overview

Affected versions of this package are vulnerable to Use After Free. SQLite 3.32.2 has a use-after-free in resetAccumulator in select.c because the parse tree rewrite for window functions is too late.

Remediation

Upgrade sqlite3 to version or higher.

References

high severity

Access Restriction Bypass

  • Vulnerable module: systemd/libsystemd0
  • Introduced through: systemd/libsystemd0@232-25+deb9u1 and systemd/libudev1@232-25+deb9u1
  • Fixed in: 232-25+deb9u11

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libudev1@232-25+deb9u1

Overview

In systemd before v242-rc4, it was discovered that pam_systemd does not properly sanitize the environment before using the XDG_SEAT variable. It is possible for an attacker, in some particular configurations, to set a XDG_SEAT environment variable which allows for commands to be checked against polkit policies using the "allow_active" element rather than "allow_any".

References

high severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: systemd/libsystemd0
  • Introduced through: systemd/libsystemd0@232-25+deb9u1 and systemd/libudev1@232-25+deb9u1
  • Fixed in: 232-25+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libudev1@232-25+deb9u1

Overview

An allocation of memory without limits, that could result in the stack clashing with another memory region, was discovered in systemd-journald when a program with long command line arguments calls syslog. A local attacker may use this flaw to crash systemd-journald or escalate his privileges. Versions through v240 are vulnerable.

References

high severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: systemd/libsystemd0
  • Introduced through: systemd/libsystemd0@232-25+deb9u1 and systemd/libudev1@232-25+deb9u1
  • Fixed in: 232-25+deb9u7

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libudev1@232-25+deb9u1

Overview

An allocation of memory without limits, that could result in the stack clashing with another memory region, was discovered in systemd-journald when many entries are sent to the journal socket. A local attacker, or a remote one if systemd-journal-remote is used, may use this flaw to crash systemd-journald or execute code with journald privileges. Versions through v240 are vulnerable.

References

high severity

Deserialization of Untrusted Data

  • Vulnerable module: systemd/libsystemd0
  • Introduced through: systemd/libsystemd0@232-25+deb9u1 and systemd/libudev1@232-25+deb9u1
  • Fixed in: 232-25+deb9u10

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libudev1@232-25+deb9u1

Overview

A vulnerability in unit_deserialize of systemd allows an attacker to supply arbitrary state across systemd re-execution via NotifyAccess. This can be used to improperly influence systemd execution and possibly lead to root privilege escalation. Affected releases are systemd versions up to and including 239.

References

high severity

Incorrect Privilege Assignment

  • Vulnerable module: systemd/libsystemd0
  • Introduced through: systemd/libsystemd0@232-25+deb9u1 and systemd/libudev1@232-25+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libudev1@232-25+deb9u1

Overview

It was discovered that a systemd service that uses DynamicUser property can create a SUID/SGID binary that would be allowed to run as the transient service UID/GID even after the service is terminated. A local attacker may use this flaw to access resources that will be owned by a potentially different service in the future, when the UID/GID will be recycled.

References

high severity

Information Exposure

  • Vulnerable module: systemd/libsystemd0
  • Introduced through: systemd/libsystemd0@232-25+deb9u1 and systemd/libudev1@232-25+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libudev1@232-25+deb9u1

Overview

systemd 242 changes the VT1 mode upon a logout, which allows attackers to read cleartext passwords in certain circumstances, such as watching a shutdown, or using Ctrl-Alt-F1 and Ctrl-Alt-F2. This occurs because the KDGKBMODE (aka current keyboard mode) check is mishandled.

References

high severity

Loop with Unreachable Exit Condition ('Infinite Loop')

  • Vulnerable module: systemd/libsystemd0
  • Introduced through: systemd/libsystemd0@232-25+deb9u1 and systemd/libudev1@232-25+deb9u1
  • Fixed in: 232-25+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libudev1@232-25+deb9u1

Overview

In systemd 223 through 235, a remote DNS server can respond with a custom crafted DNS NSEC resource record to trigger an infinite loop in the dns_packet_read_type_window() function of the 'systemd-resolved' service and cause a DoS of the affected service.

References

high severity

Out-of-Bounds

  • Vulnerable module: systemd/libsystemd0
  • Introduced through: systemd/libsystemd0@232-25+deb9u1 and systemd/libudev1@232-25+deb9u1
  • Fixed in: 232-25+deb9u6

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libudev1@232-25+deb9u1

Overview

A buffer overflow vulnerability in the dhcp6 client of systemd allows a malicious dhcp6 server to overwrite heap memory in systemd-networkd. Affected releases are systemd: versions up to and including 239.

References

high severity

Privilege Chaining

  • Vulnerable module: systemd/libsystemd0
  • Introduced through: systemd/libsystemd0@232-25+deb9u1 and systemd/libudev1@232-25+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libudev1@232-25+deb9u1

Overview

It was discovered that a systemd service that uses DynamicUser property can get new privileges through the execution of SUID binaries, which would allow to create binaries owned by the service transient group with the setgid bit set. A local attacker may use this flaw to access resources that will be owned by a potentially different service in the future, when the GID will be recycled.

References

high severity

Use After Free

  • Vulnerable module: systemd/libsystemd0
  • Introduced through: systemd/libsystemd0@232-25+deb9u1 and systemd/libudev1@232-25+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* systemd/libudev1@232-25+deb9u1

Overview

A heap use-after-free vulnerability was found in systemd before version v245-rc1, where asynchronous Polkit queries are performed while handling dbus messages. A local unprivileged attacker can abuse this flaw to crash systemd services or potentially execute code and elevate their privileges, by sending specially crafted dbus messages.

References

high severity

Access Restriction Bypass

  • Vulnerable module: util-linux
  • Introduced through: util-linux@2.29.2-1, util-linux/bsdutils@1:2.29.2-1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/bsdutils@1:2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/libblkid1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/libfdisk1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/libmount1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/libsmartcols1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/libuuid1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/mount@2.29.2-1

Overview

runuser in util-linux allows local users to escape to the parent session via a crafted TIOCSTI ioctl call, which pushes characters to the terminal's input buffer.

References

high severity

Access Restriction Bypass

  • Vulnerable module: util-linux
  • Introduced through: util-linux@2.29.2-1, util-linux/libblkid1@2.29.2-1 and others
  • Fixed in: 2.29.2-1+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/libblkid1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/libfdisk1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/libmount1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/libsmartcols1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/libuuid1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* util-linux/mount@2.29.2-1

Overview

In util-linux before 2.32-rc1, bash-completion/umount allows local users to gain privileges by embedding shell commands in a mountpoint name, which is mishandled during a umount command (within Bash) by a different user, as demonstrated by logging in as root and entering umount followed by a tab character for autocompletion.

References

medium severity

Improper Input Validation

  • Vulnerable module: apt
  • Introduced through: apt@1.4.8 and apt/libapt-pkg5.0@1.4.8
  • Fixed in: 1.4.10

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* apt@1.4.8
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* apt/libapt-pkg5.0@1.4.8

Overview

Missing input validation in the ar/tar implementations of APT before version 2.1.2 could result in denial of service when processing specially crafted deb files.

References

medium severity

Integer Overflow or Wraparound

  • Vulnerable module: apt
  • Introduced through: apt@1.4.8 and apt/libapt-pkg5.0@1.4.8
  • Fixed in: 1.4.11

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* apt@1.4.8
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* apt/libapt-pkg5.0@1.4.8

Overview

Affected versions of this package are vulnerable to Integer Overflow or Wraparound. APT had several integer overflows and underflows while parsing .deb packages, aka GHSL-2020-168 GHSL-2020-169, in files apt-pkg/contrib/extracttar.cc, apt-pkg/deb/debfile.cc, and apt-pkg/contrib/arfile.cc. This issue affects: apt 1.2.32ubuntu0 versions prior to 1.2.32ubuntu0.2; 1.6.12ubuntu0 versions prior to 1.6.12ubuntu0.2; 2.0.2ubuntu0 versions prior to 2.0.2ubuntu0.2; 2.1.10ubuntu0 versions prior to 2.1.10ubuntu0.1;

Remediation

Upgrade apt to version or higher.

References

medium severity

Out-of-bounds Write

  • Vulnerable module: e2fsprogs
  • Introduced through: e2fsprogs@1.43.4-2, e2fsprogs/e2fslibs@1.43.4-2 and others
  • Fixed in: 1.43.4-2+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* e2fsprogs@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* e2fsprogs/e2fslibs@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* e2fsprogs/libcomerr2@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* e2fsprogs/libss2@1.43.4-2

Overview

An exploitable code execution vulnerability exists in the quota file functionality of E2fsprogs 1.45.3. A specially crafted ext4 partition can cause an out-of-bounds write on the heap, resulting in code execution. An attacker can corrupt a partition to trigger this vulnerability.

References

medium severity

Out-of-bounds Write

  • Vulnerable module: e2fsprogs
  • Introduced through: e2fsprogs@1.43.4-2, e2fsprogs/e2fslibs@1.43.4-2 and others
  • Fixed in: 1.43.4-2+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* e2fsprogs@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* e2fsprogs/e2fslibs@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* e2fsprogs/libcomerr2@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* e2fsprogs/libss2@1.43.4-2

Overview

A code execution vulnerability exists in the directory rehashing functionality of E2fsprogs e2fsck 1.45.4. A specially crafted ext4 directory can cause an out-of-bounds write on the stack, resulting in code execution. An attacker can corrupt a partition to trigger this vulnerability.

References

medium severity

Out-of-Bounds

  • Vulnerable module: elfutils/libelf1
  • Introduced through: elfutils/libelf1@0.168-1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* elfutils/libelf1@0.168-1

Overview

An invalid memory address dereference was discovered in dwfl_segment_report_module.c in libdwfl in elfutils through v0.174. The vulnerability allows attackers to cause a denial of service (application crash) with a crafted ELF file, as demonstrated by consider_notes.

References

medium severity

Out-of-bounds Read

  • Vulnerable module: elfutils/libelf1
  • Introduced through: elfutils/libelf1@0.168-1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* elfutils/libelf1@0.168-1

Overview

dwarf_getaranges in dwarf_getaranges.c in libdw in elfutils before 2018-08-18 allows remote attackers to cause a denial of service (heap-based buffer over-read) via a crafted file.

References

medium severity

Out-of-bounds Write

  • Vulnerable module: freetype/libfreetype6
  • Introduced through: freetype/libfreetype6@2.6.3-3.2
  • Fixed in: 2.6.3-3.2+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* freetype/libfreetype6@2.6.3-3.2

Overview

Affected versions of this package are vulnerable to Out-of-bounds Write. Heap buffer overflow in Freetype in Google Chrome prior to 86.0.4240.111 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

Remediation

Upgrade freetype to version or higher.

References

medium severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

The DNS stub resolver in the GNU C Library (aka glibc or libc6) before version 2.26, when EDNS support is enabled, will solicit large UDP responses from name servers, potentially simplifying off-path DNS spoofing attacks due to IP fragmentation.

References

medium severity
new

Double Free

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

Affected versions of this package are vulnerable to Double Free. The nameserver caching daemon (nscd) in the GNU C Library (aka glibc or libc6) 2.29 through 2.33, when processing a request for netgroup lookup, may crash due to a double-free, potentially resulting in degraded service or Denial of Service on the local system. This is related to netgroupcache.c.

Remediation

There is no fixed version for glibc.

References

medium severity

Improper Input Validation

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

In the GNU C Library (aka glibc or libc6) through 2.28, the getaddrinfo function would successfully parse a string that contained an IPv4 address followed by whitespace and arbitrary characters, which could lead applications to incorrectly assume that it had parsed a valid string, without the possibility of embedded HTTP headers or other potentially dangerous substrings.

References

medium severity

Missing Release of Resource after Effective Lifetime

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others
  • Fixed in: 2.24-11+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

The glob function in glob.c in the GNU C Library (aka glibc or libc6) before 2.27, when invoked with GLOB_TILDE, could skip freeing allocated memory when processing the ~ operator with a long user name, potentially leading to a denial of service (memory leak).

References

medium severity

Out-of-Bounds

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

The GNU C Library (aka glibc or libc6) before 2.32 could overflow an on-stack buffer during range reduction if an input to an 80-bit long double function contains a non-canonical bit pattern, a seen when passing a 0x5d414141414141410000 value to sinl on x86 targets. This is related to sysdeps/ieee754/ldbl-96/e_rem_pio2l.c.

References

medium severity

Out-of-bounds Read

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

Affected versions of this package are vulnerable to Out-of-bounds Read. The iconv feature in the GNU C Library (aka glibc or libc6) through 2.32, when processing invalid multi-byte input sequences in the EUC-KR encoding, may have a buffer over-read.

Remediation

There is no fixed version for glibc.

References

medium severity

Use After Free

  • Vulnerable module: glibc/libc-bin
  • Introduced through: glibc/libc-bin@2.24-11+deb9u1, glibc/libc6@2.24-11+deb9u1 and others
  • Fixed in: 2.24-11+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* glibc/multiarch-support@2.24-11+deb9u1

Overview

Use-after-free vulnerability in the clntudp_call function in sunrpc/clnt_udp.c in the GNU C Library (aka glibc or libc6) before 2.26 allows remote attackers to have unspecified impact via vectors related to error path.

References

medium severity

Information Exposure

  • Vulnerable module: gnutls28/libgnutls30
  • Introduced through: gnutls28/libgnutls30@3.5.8-5+deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnutls28/libgnutls30@3.5.8-5+deb9u3

Overview

A Bleichenbacher type side-channel based padding oracle attack was found in the way gnutls handles verification of RSA decrypted PKCS#1 v1.5 data. An attacker who is able to run process on the same physical core as the victim process, could use this to extract plaintext or in some cases downgrade any TLS connections to a vulnerable server.

References

medium severity

Use of a Broken or Risky Cryptographic Algorithm

  • Vulnerable module: gnutls28/libgnutls30
  • Introduced through: gnutls28/libgnutls30@3.5.8-5+deb9u3
  • Fixed in: 3.5.8-5+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnutls28/libgnutls30@3.5.8-5+deb9u3

Overview

It was found that the GnuTLS implementation of HMAC-SHA-384 was vulnerable to a Lucky thirteen style attack. Remote attackers could use this flaw to conduct distinguishing attacks and plain text recovery attacks via statistical analysis of timing data using crafted packets.

References

medium severity

Use of a Broken or Risky Cryptographic Algorithm

  • Vulnerable module: gnutls28/libgnutls30
  • Introduced through: gnutls28/libgnutls30@3.5.8-5+deb9u3
  • Fixed in: 3.5.8-5+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnutls28/libgnutls30@3.5.8-5+deb9u3

Overview

A cache-based side channel in GnuTLS implementation that leads to plain text recovery in cross-VM attack setting was found. An attacker could use a combination of "Just in Time" Prime+probe attack in combination with Lucky-13 attack to recover plain text using crafted packets.

References

medium severity

Use of a Broken or Risky Cryptographic Algorithm

  • Vulnerable module: gnutls28/libgnutls30
  • Introduced through: gnutls28/libgnutls30@3.5.8-5+deb9u3
  • Fixed in: 3.5.8-5+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* gnutls28/libgnutls30@3.5.8-5+deb9u3

Overview

It was found that the GnuTLS implementation of HMAC-SHA-256 was vulnerable to a Lucky thirteen style attack. Remote attackers could use this flaw to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data using crafted packets.

References

medium severity

Cryptographic Issues

  • Vulnerable module: libgcrypt20
  • Introduced through: libgcrypt20@1.7.6-2+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libgcrypt20@1.7.6-2+deb9u2

Overview

In Libgcrypt 1.8.4, the C implementation of AES is vulnerable to a flush-and-reload side-channel attack because physical addresses are available to other processes. (The C implementation is used on platforms where an assembly-language implementation is unavailable.)

References

medium severity

Information Exposure

  • Vulnerable module: libgcrypt20
  • Introduced through: libgcrypt20@1.7.6-2+deb9u2
  • Fixed in: 1.7.6-2+deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libgcrypt20@1.7.6-2+deb9u2

Overview

Libgcrypt before 1.7.10 and 1.8.x before 1.8.3 allows a memory-cache side-channel attack on ECDSA signatures that can be mitigated through the use of blinding during the signing process in the _gcry_ecc_ecdsa_sign function in cipher/ecc-ecdsa.c, aka the Return Of the Hidden Number Problem or ROHNP. To discover an ECDSA key, the attacker needs access to either the local machine or a different virtual machine on the same physical host.

References

medium severity

Race Condition

  • Vulnerable module: libgcrypt20
  • Introduced through: libgcrypt20@1.7.6-2+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libgcrypt20@1.7.6-2+deb9u2

Overview

It was discovered that there was a ECDSA timing attack in the libgcrypt20 cryptographic library. Version affected: 1.8.4-5, 1.7.6-2+deb9u3, and 1.6.3-2+deb8u4. Versions fixed: 1.8.5-2 and 1.6.3-2+deb8u7.

References

medium severity

Missing Release of Resource after Effective Lifetime

  • Vulnerable module: libpng1.6/libpng16-16
  • Introduced through: libpng1.6/libpng16-16@1.6.28-1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libpng1.6/libpng16-16@1.6.28-1

Overview

gif2png 2.5.13 has a memory leak in the writefile function.

References

medium severity

Integer Overflow or Wraparound

  • Vulnerable module: libx11/libx11-6
  • Introduced through: libx11/libx11-6@2:1.6.4-3 and libx11/libx11-data@2:1.6.4-3
  • Fixed in: 2:1.6.4-3+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* libx11/libx11-data@2:1.6.4-3

Overview

Affected versions of this package are vulnerable to Integer Overflow or Wraparound. An integer overflow leading to a heap-buffer overflow was found in The X Input Method (XIM) client was implemented in libX11 before version 1.6.10. As per upstream this is security relevant when setuid programs call XIM client functions while running with elevated privileges. No such programs are shipped with Red Hat Enterprise Linux.

Remediation

Upgrade libx11 to version or higher.

References

medium severity

Information Exposure

  • Vulnerable module: nettle/libhogweed4
  • Introduced through: nettle/libhogweed4@3.3-1+b2 and nettle/libnettle6@3.3-1+b2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* nettle/libhogweed4@3.3-1+b2
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* nettle/libnettle6@3.3-1+b2

Overview

A Bleichenbacher type side-channel based padding oracle attack was found in the way nettle handles endian conversion of RSA decrypted PKCS#1 v1.5 data. An attacker who is able to run a process on the same physical core as the victim process, could use this flaw extract plaintext or in some cases downgrade any TLS connections to a vulnerable server.

References

medium severity

Access Restriction Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Access Restriction Bypass. None

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Cross-site Scripting (XSS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). None

Details

A cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.

This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.

Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.

Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as &lt; and > can be coded as &gt; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.

The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.

Types of attacks

There are a few methods by which XSS can be manipulated:

Type Origin Description
Stored Server The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.
Reflected Server The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.
DOM-based Client The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.
Mutated The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.

Affected environments

The following environments are susceptible to an XSS attack:

  • Web servers
  • Application servers
  • Web application environments

How to prevent

This section describes the top best practices designed to specifically protect your code:

  • Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
  • Convert special characters such as ?, &, /, <, > and spaces to their respective HTML or URL encoded equivalents.
  • Give users the option to disable client-side scripts.
  • Redirect invalid requests.
  • Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
  • Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
  • Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Cryptographic Issues

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Cryptographic Issues due to use of unsafe RSA-MD5 checkum in Kerberos TGS.

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

medium severity

CVE-2014-2422

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to CVE-2014-2422. It allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors.

Remediation

Upgrade openjdk-jre to version 7.0.55, 8.0.5 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS) in the way the TLS implementation in the JSSE component of OpenJDK re-used single null TLS sessions for new TLS connections. A remote attacker could possibly use this flaw to impact availability of a Java application providing TLS server.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Sound). Supported versions that are affected are Java SE: 6u201, 7u191 and 8u182; Java SE Embedded: 8u181; JRockit: R28.3.19. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g. through a web service which supplies data to the APIs.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

  • High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

  • Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade openjdk-jre to version 7.0.191, 8.0.182 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Serialization). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, JRockit component of Oracle Java SE (subcomponent: Serialization). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, JRockit. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Libraries). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: JAXP). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: JAX-WS). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Networking). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151, 9.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Serialization). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: JNDI). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded, JRockit accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: This vulnerability applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: I18n). Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Java SE, Java SE Embedded executes to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data as well as unauthorized read access to a subset of Java SE, Java SE Embedded accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Libraries). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: This vulnerability applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, JRockit component of Oracle Java SE (subcomponent: Serialization). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, JRockit. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.171 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Libraries). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: This vulnerability applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: AWT). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: JNDI). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: This vulnerability applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Security). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.181, 8.0.171 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Concurrency). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.181, 8.0.171, 10.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: JMX). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.181, 8.0.171 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: AWT). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.181, 8.0.171 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: JAXP). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.181, 8.0.171 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Serialization). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.181, 8.0.171 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_201

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: JSSE). Difficult to exploit vulnerability allows unauthenticated attacker with network access via SSL/TLS to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded, JRockit accessible data as well as unauthorized read access to a subset of Java SE, Java SE Embedded, JRockit accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g. code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g. through a web service which supplies data to the APIs.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.201, 8.0.191 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_201

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Sound). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded, JRockit. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g. through a web service which supplies data to the APIs.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.201, 8.0.191 or higher.

References

medium severity

Encoding Error

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Encoding Error. Incorrect isBuiltinStreamHandler causes URL normalization issues.

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

medium severity

HTTP Response Splitting

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to HTTP Response Splitting. The HttpServer implementation did not restrict the use of CR and LF characters in values for HTTP headers, possibly allowing HTTP response splitting attacks.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. None

Remediation

Upgrade openjdk-jre to version 7.0.241, 8.0.231, 11.0.5, 13.0.1 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE component of Oracle Java SE (subcomponent: Smart Card IO). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE accessible data as well as unauthorized access to critical data or complete access to all Java SE accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE component of Oracle Java SE (subcomponent: Javadoc). Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Java SE. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE accessible data as well as unauthorized read access to a subset of Java SE accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Networking). Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Java SE, Java SE Embedded, JRockit. While the vulnerability is in Java SE, Java SE Embedded, JRockit, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded, JRockit accessible data. Note: This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: JCE). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Java SE, Java SE Embedded, JRockit accessible data. Note: This vulnerability applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: JGSS). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java SE Embedded, JRockit accessible data. Note: This vulnerability applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: AWT). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, JRockit component of Oracle Java SE (subcomponent: RMI). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, JRockit. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, JRockit accessible data as well as unauthorized read access to a subset of Java SE, JRockit accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.181, 8.0.171 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Libraries). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.191, 8.0.181 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: JSSE). Difficult to exploit vulnerability allows unauthenticated attacker with network access via SSL/TLS to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.191, 8.0.181 or higher.

References

medium severity

Improper Handling

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Handling via the HTTP proxy responses in HttpURLConnection.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Improper Handling

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Handling. The Kerberos implementation in the Kerberos component in OpenJDK did not properly handle proxy credentials. This could lead to the unintended use of wrong credentials and possible user impersonation.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Improper Input Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Input Validation. A flaw was found in the way the XMLSchemaValidator class in the JAXP component of OpenJDK enforced the "use-grammar-pool-only" feature. A specially-crafted XML file could possibly use this flaw to manipulate with the validation process in certain cases.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

medium severity

Information Exposure

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Information Exposure. Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Security). Easily exploitable vulnerability allows unauthenticated attacker with logon to the infrastructure where Java SE, Java SE Embedded, JRockit executes to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Java SE, Java SE Embedded, JRockit accessible data. Note: This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.161, 8.0.151 or higher.

References

medium severity

Information Exposure

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Information Exposure. Vulnerability in the Java SE component of Oracle Java SE (subcomponent: JavaFX). Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Information Exposure

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Information Exposure. Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: LDAP). Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Java SE Embedded, JRockit accessible data. Note: This vulnerability applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

Information Exposure

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Information Exposure. Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: JGSS). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. While the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 7.0.171, 8.0.161 or higher.

References

medium severity

integer overflow

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to integer overflow via the SunGraphics2D class in the 2D component in OpenJDK. The check of offset and length values passed to drawChars() and drawBytes() methods could be bypassed, leading to excessive memory allocation or attempt to access buffer out of bounds.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Integer Overflow

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_281

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Integer Overflow. It was discovered that the Hotspot component of OpenJDK did not properly check for integer overflows when when optimizing code, leading to out-of-bounds access. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.281, 8.0.271, 11.0.9, 15.0.1 or higher.

References

medium severity

Man-in-the-Middle (MitM)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Man-in-the-Middle (MitM). It does not correctly handle CertificateVerify TLS handshake message received unexpectedly. An attacker can use this flaw to affect confidentiality or integrity of a TLS connection.

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

medium severity

Out-of-Bounds

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Out-of-Bounds. None

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Regular Expression Denial of Service (ReDoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Regular Expression Denial of Service (ReDoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Regular Expression Denial of Service (ReDoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_154-b01
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@7u154-7.20.0.3 openjdk-jre@1.7.0_154-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). The use of overly complex regular expressions in java.utils.Scanner could cause a high CPU usage when Scanner was used on parse certain inputs.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

medium severity

Improper Authentication

  • Vulnerable module: openldap/libldap-2.4-2
  • Introduced through: openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1 and openldap/libldap-common@2.4.44+dfsg-5+deb9u1
  • Fixed in: 2.4.44+dfsg-5+deb9u3

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

Overview

An issue was discovered in the server in OpenLDAP before 2.4.48. When the server administrator delegates rootDN (database admin) privileges for certain databases but wants to maintain isolation (e.g., for multi-tenant deployments), slapd does not properly stop a rootDN from requesting authorization as an identity from another database during a SASL bind or with a proxyAuthz (RFC 4370) control. (It is not a common configuration to deploy a system where the server administrator and a DB administrator enjoy different levels of trust.)

References

medium severity

Improper Input Validation

  • Vulnerable module: openssl/libssl1.1
  • Introduced through: openssl/libssl1.1@1.1.0f-3+deb9u1
  • Fixed in: 1.1.0f-3+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openssl/libssl1.1@1.1.0f-3+deb9u1

Overview

Because of an implementation bug the PA-RISC CRYPTO_memcmp function is effectively reduced to only comparing the least significant bit of each byte. This allows an attacker to forge messages that would be considered as authenticated in an amount of tries lower than that guaranteed by the security claims of the scheme. The module can only be compiled by the HP-UX assembler, so that only HP-UX PA-RISC targets are affected. Fixed in OpenSSL 1.1.0h (Affected 1.1.0-1.1.0g).

References

medium severity

Information Exposure

  • Vulnerable module: openssl/libssl1.1
  • Introduced through: openssl/libssl1.1@1.1.0f-3+deb9u1
  • Fixed in: 1.1.0f-3+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openssl/libssl1.1@1.1.0f-3+deb9u1

Overview

There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. OpenSSL version 1.0.2-1.0.2m and 1.1.0-1.1.0g are affected. Fixed in OpenSSL 1.0.2n. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available. The fix is also available in commit e502cc86d in the OpenSSL git repository.

References

medium severity

Information Exposure

  • Vulnerable module: openssl/libssl1.1
  • Introduced through: openssl/libssl1.1@1.1.0f-3+deb9u1
  • Fixed in: 1.1.0j-1~deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openssl/libssl1.1@1.1.0f-3+deb9u1

medium severity

Missing Encryption of Sensitive Data

  • Vulnerable module: openssl/libssl1.1
  • Introduced through: openssl/libssl1.1@1.1.0f-3+deb9u1
  • Fixed in: 1.1.0l-1~deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:7u154-7.20.0.3@* openssl/libssl1.1@1.1.0f-3+deb9u1

Overview

Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead