Docker azul/zulu-openjdk-debian:8u152-8.25.0.1

Vulnerabilities

329 via 531 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
  • 123
  • 97
  • 109
Status
  • 329
  • 0
  • 0
OS binaries
  • 224
  • 105

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:8u152-8.25.0.1@* apt@1.4.8
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* apt/libapt-pkg5.0@1.4.8

NVD Description

Note: Versions mentioned in the description apply to the upstream apt package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 apt to version 1.4.9 or higher.

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:8u152-8.25.0.1@* bzip2/libbz2-1.0@1.0.6-8.1

NVD Description

Note: Versions mentioned in the description apply to the upstream bzip2 package.

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

Remediation

There is no fixed version for Debian:9 bzip2.

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:8u152-8.25.0.1@* cyrus-sasl2/libsasl2-2@2.1.27~101-g0780600+dfsg-3
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* cyrus-sasl2/libsasl2-modules@2.1.27~101-g0780600+dfsg-3
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* cyrus-sasl2/libsasl2-modules-db@2.1.27~101-g0780600+dfsg-3

NVD Description

Note: Versions mentioned in the description apply to the upstream cyrus-sasl2 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 cyrus-sasl2 to version 2.1.27~101-g0780600+dfsg-3+deb9u1 or higher.

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:8u152-8.25.0.1@* expat/libexpat1@2.2.0-2+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream expat package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 expat to version 2.2.0-2+deb9u3 or higher.

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:8u152-8.25.0.1@* expat/libexpat1@2.2.0-2+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream expat package. See Remediation section below for Debian:9 relevant versions.

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).

Remediation

Upgrade Debian:9 expat to version 2.2.0-2+deb9u2 or higher.

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:8u152-8.25.0.1@* gcc-6/gcc-6-base@6.3.0-18
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* gcc-6/libgcc1@1:6.3.0-18
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* gcc-6/libstdc++6@6.3.0-18

NVD Description

Note: Versions mentioned in the description apply to the upstream gcc-6 package.

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.

Remediation

There is no fixed version for Debian:9 gcc-6.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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.

Remediation

There is no fixed version for Debian:9 glibc.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 glibc to version 2.24-11+deb9u4 or higher.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 glibc to version 2.24-11+deb9u4 or higher.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 glibc to version 2.24-11+deb9u4 or higher.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 glibc to version 2.24-11+deb9u4 or higher.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 glibc to version 2.24-11+deb9u4 or higher.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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.

Remediation

There is no fixed version for Debian:9 glibc.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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.

Remediation

There is no fixed version for Debian:9 glibc.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 glibc to version 2.24-11+deb9u4 or higher.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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.

Remediation

There is no fixed version for Debian:9 glibc.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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.

Remediation

There is no fixed version for Debian:9 glibc.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 glibc to version 2.24-11+deb9u4 or higher.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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.

Remediation

There is no fixed version for Debian:9 glibc.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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 Debian:9 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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 glibc to version 2.24-11+deb9u4 or higher.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

The mq_notify function in the GNU C Library (aka glibc) versions 2.32 and 2.33 has a use-after-free. It may use the notification thread attributes object (passed through its struct sigevent parameter) after it has been freed by the caller, leading to a denial of service (application crash) or possibly unspecified other impact.

Remediation

There is no fixed version for Debian:9 glibc.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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.

Remediation

There is no fixed version for Debian:9 glibc.

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:8u152-8.25.0.1@* gnupg2/dirmngr@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* gnupg2/gnupg@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* gnupg2/gnupg-agent@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* gnupg2/gnupg-l10n@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* gnupg2/gpgv@2.1.18-8~deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream gnupg2 package.

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.

Remediation

There is no fixed version for Debian:9 gnupg2.

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:8u152-8.25.0.1@* gnupg2/dirmngr@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* gnupg2/gnupg@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* gnupg2/gnupg-agent@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* gnupg2/gnupg-l10n@2.1.18-8~deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* gnupg2/gpgv@2.1.18-8~deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream gnupg2 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 gnupg2 to version 2.1.18-8~deb9u2 or higher.

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:8u152-8.25.0.1@* gnutls28/libgnutls30@3.5.8-5+deb9u3

NVD Description

Note: Versions mentioned in the description apply to the upstream gnutls28 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 gnutls28 to version 3.5.8-5+deb9u5 or higher.

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:8u152-8.25.0.1@* inetutils/inetutils-ping@2:1.9.4-2+b1

NVD Description

Note: Versions mentioned in the description apply to the upstream inetutils package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 inetutils to version 2:1.9.4-2+deb9u1 or higher.

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:8u152-8.25.0.1@* libbsd/libbsd0@0.8.3-1

NVD Description

Note: Versions mentioned in the description apply to the upstream libbsd package. See Remediation section below for Debian:9 relevant versions.

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).

Remediation

Upgrade Debian:9 libbsd to version 0.8.3-1+deb9u1 or higher.

References

high severity

Information Exposure

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

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* libgcrypt20@1.7.6-2+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream libgcrypt20 package. See Remediation section below for Debian:9 relevant versions.

Libgcrypt before 1.8.8 and 1.9.x before 1.9.3 mishandles ElGamal encryption because it lacks exponent blinding to address a side-channel attack against mpi_powm, and the window size is not chosen appropriately. (There is also an interoperability problem because the selection of the k integer value does not properly consider the differences between basic ElGamal encryption and generalized ElGamal encryption.) This, for example, affects use of ElGamal in OpenPGP.

Remediation

Upgrade Debian:9 libgcrypt20 to version 1.7.6-2+deb9u4 or higher.

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:8u152-8.25.0.1@* libidn/libidn11@1.33-1

NVD Description

Note: Versions mentioned in the description apply to the upstream libidn package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 libidn to version 1.33-1+deb9u1 or higher.

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:8u152-8.25.0.1@* libpng1.6/libpng16-16@1.6.28-1

NVD Description

Note: Versions mentioned in the description apply to the upstream libpng1.6 package.

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

Remediation

There is no fixed version for Debian:9 libpng1.6.

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:8u152-8.25.0.1@* libtasn1-6@4.10-1.1

NVD Description

Note: Versions mentioned in the description apply to the upstream libtasn1-6 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 libtasn1-6 to version 4.10-1.1+deb9u1 or higher.

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:8u152-8.25.0.1@* libtasn1-6@4.10-1.1

NVD Description

Note: Versions mentioned in the description apply to the upstream libtasn1-6 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 libtasn1-6 to version 4.10-1.1+deb9u1 or higher.

References

high severity

Buffer Overflow

  • 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+deb9u4

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* libx11/libx11-data@2:1.6.4-3

NVD Description

Note: Versions mentioned in the description apply to the upstream libx11 package. See Remediation section below for Debian:9 relevant versions.

LookupCol.c in X.Org X through X11R7.7 and libX11 before 1.7.1 might allow remote attackers to execute arbitrary code. The libX11 XLookupColor request (intended for server-side color lookup) contains a flaw allowing a client to send color-name requests with a name longer than the maximum size allowed by the protocol (and also longer than the maximum packet size for normal-sized packets). The user-controlled data exceeding the maximum size is then interpreted by the server as additional X protocol requests and executed, e.g., to disable X server authorization completely. For example, if the victim encounters malicious terminal control sequences for color codes, then the attacker may be able to take full control of the running graphical session.

Remediation

Upgrade Debian:9 libx11 to version 2:1.6.4-3+deb9u4 or higher.

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:8u152-8.25.0.1@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* libx11/libx11-data@2:1.6.4-3

NVD Description

Note: Versions mentioned in the description apply to the upstream libx11 package. See Remediation section below for Debian:9 relevant versions.

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).

Remediation

Upgrade Debian:9 libx11 to version 2:1.6.4-3+deb9u1 or higher.

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:8u152-8.25.0.1@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* libx11/libx11-data@2:1.6.4-3

NVD Description

Note: Versions mentioned in the description apply to the upstream libx11 package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 libx11 to version 2:1.6.4-3+deb9u3 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:8u152-8.25.0.1@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* libx11/libx11-data@2:1.6.4-3

NVD Description

Note: Versions mentioned in the description apply to the upstream libx11 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 libx11 to version 2:1.6.4-3+deb9u1 or higher.

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:8u152-8.25.0.1@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* libx11/libx11-data@2:1.6.4-3

NVD Description

Note: Versions mentioned in the description apply to the upstream libx11 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 libx11 to version 2:1.6.4-3+deb9u1 or higher.

References

high severity

Out-of-bounds Write

  • Vulnerable module: lz4/liblz4-1
  • Introduced through: lz4/liblz4-1@0.0~r131-2+b1
  • Fixed in: 0.0~r131-2+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* lz4/liblz4-1@0.0~r131-2+b1

NVD Description

Note: Versions mentioned in the description apply to the upstream lz4 package. See Remediation section below for Debian:9 relevant versions.

There's a flaw in lz4. An attacker who submits a crafted file to an application linked with lz4 may be able to trigger an integer overflow, leading to calling of memmove() on a negative size argument, causing an out-of-bounds write and/or a crash. The greatest impact of this flaw is to availability, with some potential impact to confidentiality and integrity as well.

Remediation

Upgrade Debian:9 lz4 to version 0.0~r131-2+deb9u1 or higher.

References

high severity

Out-of-bounds Write

  • 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:8u152-8.25.0.1@* ncurses/libncursesw5@6.0+20161126-1+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* ncurses/libtinfo5@6.0+20161126-1+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* ncurses/ncurses-base@6.0+20161126-1+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* ncurses/ncurses-bin@6.0+20161126-1+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream ncurses package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 ncurses to version 6.0+20161126-1+deb9u2 or higher.

References

high severity

Use of a Broken or Risky Cryptographic Algorithm

  • 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:8u152-8.25.0.1@* nettle/libhogweed4@3.3-1+b2
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* nettle/libnettle6@3.3-1+b2

NVD Description

Note: Versions mentioned in the description apply to the upstream nettle package.

A flaw was found in Nettle in versions before 3.7.2, where several Nettle signature verification functions (GOST DSA, EDDSA & ECDSA) result in the Elliptic Curve Cryptography point (ECC) multiply function being called with out-of-range scalers, possibly resulting in incorrect results. This flaw allows an attacker to force an invalid signature, causing an assertion failure or possible validation. The highest threat to this vulnerability is to confidentiality, integrity, as well as system availability.

Remediation

There is no fixed version for Debian:9 nettle.

References

high severity

Buffer Overflow

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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: Installer). Difficult to exploit vulnerability allows low privileged attacker with logon to the infrastructure where Java SE executes 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 the Windows installer only.

Remediation

Upgrade openjdk-jre to version 8.0.161 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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: Deployment). 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 8.0.161 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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: Deployment). 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 8.0.161 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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: Install). Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Java SE executes 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 installation process on client deployment of Java.

Remediation

Upgrade openjdk-jre to version 8.0.171 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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: Deployment). 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 8.0.181 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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 Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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: Scripting). Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols 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 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 8.0.191 or higher.

References

high severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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 (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 8.0.191 or higher.

References

high severity

Improper Input Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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
new

Sandbox Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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 Hotspot component of OpenJDK performed range check elimination. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 8.0.301, 11.0.12, 16.0.2 or higher.

References

high severity

Sandbox Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u7 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u7 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u7 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 openldap to version 2.4.44+dfsg-5+deb9u3 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u7 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u7 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u7 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u5 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u7 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+deb9u6

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

A flaw was found in OpenLDAP. This flaw allows an attacker who can send a malicious packet to be processed by OpenLDAP’s slapd server, to trigger an assertion failure. The highest threat from this vulnerability is to system availability.

Remediation

Upgrade Debian:9 openldap to version 2.4.44+dfsg-5+deb9u6 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+deb9u6

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

A flaw was found in OpenLDAP in versions before 2.4.56. This flaw allows an attacker who sends a malicious packet processed by OpenLDAP to force a failed assertion in csnNormalize23(). The highest threat from this vulnerability is to system availability.

Remediation

Upgrade Debian:9 openldap to version 2.4.44+dfsg-5+deb9u6 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u7 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u7 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+deb9u8

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u8 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openldap to version 2.4.44+dfsg-5+deb9u7 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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).

Remediation

Upgrade Debian:9 openldap to version 2.4.44+dfsg-5+deb9u4 or higher.

References

high severity

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:8u152-8.25.0.1@* openssl/libssl1.1@1.1.0f-3+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openssl package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 openssl to version 1.1.0l-1~deb9u3 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:8u152-8.25.0.1@* openssl/libssl1.1@1.1.0f-3+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openssl package. See Remediation section below for Debian:9 relevant versions.

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).

Remediation

Upgrade Debian:9 openssl to version 1.1.0j-1~deb9u1 or higher.

References

high severity

Use of a Broken or Risky Cryptographic Algorithm

  • 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:8u152-8.25.0.1@* openssl/libssl1.1@1.1.0f-3+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openssl package. See Remediation section below for Debian:9 relevant versions.

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).

Remediation

Upgrade Debian:9 openssl to version 1.1.0k-1~deb9u1 or higher.

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:8u152-8.25.0.1@* p11-kit/libp11-kit0@0.23.3-2

NVD Description

Note: Versions mentioned in the description apply to the upstream p11-kit package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 p11-kit to version 0.23.3-2+deb9u1 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:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 perl to version 5.24.1-3+deb9u7 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:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 perl to version 5.24.1-3+deb9u7 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:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 perl to version 5.24.1-3+deb9u4 or higher.

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:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

Perl before 5.26.3 and 5.28.0 before 5.28.1 has a buffer overflow via a crafted regular expression that triggers invalid write operations.

Remediation

Upgrade Debian:9 perl to version 5.24.1-3+deb9u5 or higher.

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:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

Perl before 5.26.3 has a buffer overflow via a crafted regular expression that triggers invalid write operations.

Remediation

Upgrade Debian:9 perl to version 5.24.1-3+deb9u5 or higher.

References

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:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

Perl before 5.26.3 has a buffer over-read via a crafted regular expression that triggers disclosure of sensitive information from process memory.

Remediation

Upgrade Debian:9 perl to version 5.24.1-3+deb9u5 or higher.

References

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:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 perl to version 5.24.1-3+deb9u3 or higher.

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

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

Perl before 5.26.3 and 5.28.x before 5.28.1 has a buffer overflow via a crafted regular expression that triggers invalid write operations.

Remediation

Upgrade Debian:9 perl to version 5.24.1-3+deb9u5 or higher.

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:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 perl to version 5.24.1-3+deb9u3 or higher.

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:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 perl to version 5.24.1-3+deb9u3 or higher.

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:8u152-8.25.0.1@* perl/perl-base@5.24.1-3+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream perl package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 perl to version 5.24.1-3+deb9u7 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:8u152-8.25.0.1@* sensible-utils@0.0.9

NVD Description

Note: Versions mentioned in the description apply to the upstream sensible-utils package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 sensible-utils to version 0.0.9+deb9u1 or higher.

References

high severity

Improper Privilege Management

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

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* shadow/login@1:4.4-4.1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* shadow/passwd@1:4.4-4.1

NVD Description

Note: Versions mentioned in the description apply to the upstream shadow package. See Remediation section below for Debian:9 relevant versions.

The Debian shadow package before 1:4.5-1 for Shadow incorrectly lists pts/0 and pts/1 as physical terminals in /etc/securetty. This allows local users to login as password-less users even if they are connected by non-physical means such as SSH (hence bypassing PAM's nullok_secure configuration). This notably affects environments such as virtual machines automatically generated with a default blank root password, allowing all local users to escalate privileges.

Remediation

Upgrade Debian:9 shadow to version 1:4.4-4.1+deb9u1 or higher.

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
  • Fixed in: 1:4.4-4.1+deb9u1

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* shadow/login@1:4.4-4.1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* shadow/passwd@1:4.4-4.1

NVD Description

Note: Versions mentioned in the description apply to the upstream shadow package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 shadow to version 1:4.4-4.1+deb9u1 or higher.

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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

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

Remediation

Upgrade Debian:9 sqlite3 to version 3.16.2-5+deb9u3 or higher.

References

high severity

Improper Initialization

  • 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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 sqlite3 to version 3.16.2-5+deb9u2 or higher.

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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 sqlite3 to version 3.16.2-5+deb9u2 or higher.

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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 sqlite3 to version 3.16.2-5+deb9u2 or higher.

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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 sqlite3 to version 3.16.2-5+deb9u2 or higher.

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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 sqlite3 to version 3.16.2-5+deb9u2 or higher.

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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 sqlite3 to version 3.16.2-5+deb9u1 or higher.

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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 sqlite3 to version 3.16.2-5+deb9u2 or higher.

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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package.

SQLite3 from 3.6.0 to and including 3.27.2 is vulnerable to heap out-of-bound read in the rtreenode() function when handling invalid rtree tables.

Remediation

There is no fixed version for Debian:9 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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 sqlite3 to version 3.16.2-5+deb9u2 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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

ext/fts3/fts3.c in SQLite before 3.32.0 has a use-after-free in fts3EvalNextRow, related to the snippet feature.

Remediation

Upgrade Debian:9 sqlite3 to version 3.16.2-5+deb9u2 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:8u152-8.25.0.1@* sqlite3/libsqlite3-0@3.16.2-5

NVD Description

Note: Versions mentioned in the description apply to the upstream sqlite3 package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 sqlite3 to version 3.16.2-5+deb9u2 or higher.

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:8u152-8.25.0.1@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* systemd/libudev1@232-25+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream systemd package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 systemd to version 232-25+deb9u7 or higher.

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:8u152-8.25.0.1@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* systemd/libudev1@232-25+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream systemd package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 systemd to version 232-25+deb9u7 or higher.

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:8u152-8.25.0.1@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* systemd/libudev1@232-25+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream systemd package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 systemd to version 232-25+deb9u10 or higher.

References

high severity

Improper Authorization

  • 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:8u152-8.25.0.1@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* systemd/libudev1@232-25+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream systemd package. See Remediation section below for Debian:9 relevant versions.

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".

Remediation

Upgrade Debian:9 systemd to version 232-25+deb9u11 or higher.

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:8u152-8.25.0.1@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* systemd/libudev1@232-25+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream systemd package.

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.

Remediation

There is no fixed version for Debian:9 systemd.

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:8u152-8.25.0.1@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* systemd/libudev1@232-25+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream systemd package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 systemd to version 232-25+deb9u2 or higher.

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:8u152-8.25.0.1@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* systemd/libudev1@232-25+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream systemd package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 systemd to version 232-25+deb9u6 or higher.

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:8u152-8.25.0.1@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* systemd/libudev1@232-25+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream systemd package.

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.

Remediation

There is no fixed version for Debian:9 systemd.

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:8u152-8.25.0.1@* systemd/libsystemd0@232-25+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* systemd/libudev1@232-25+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream systemd package.

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.

Remediation

There is no fixed version for Debian:9 systemd.

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:8u152-8.25.0.1@* util-linux@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/bsdutils@1:2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/libblkid1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/libfdisk1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/libmount1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/libsmartcols1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/libuuid1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/mount@2.29.2-1

NVD Description

Note: Versions mentioned in the description apply to the upstream util-linux package.

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.

Remediation

There is no fixed version for Debian:9 util-linux.

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:8u152-8.25.0.1@* util-linux@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/libblkid1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/libfdisk1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/libmount1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/libsmartcols1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/libuuid1@2.29.2-1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* util-linux/mount@2.29.2-1

NVD Description

Note: Versions mentioned in the description apply to the upstream util-linux package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 util-linux to version 2.29.2-1+deb9u1 or higher.

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:8u152-8.25.0.1@* apt@1.4.8
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* apt/libapt-pkg5.0@1.4.8

NVD Description

Note: Versions mentioned in the description apply to the upstream apt package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 apt to version 1.4.10 or higher.

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:8u152-8.25.0.1@* apt@1.4.8
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* apt/libapt-pkg5.0@1.4.8

NVD Description

Note: Versions mentioned in the description apply to the upstream apt package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 apt to version 1.4.11 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:8u152-8.25.0.1@* e2fsprogs@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* e2fsprogs/e2fslibs@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* e2fsprogs/libcomerr2@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* e2fsprogs/libss2@1.43.4-2

NVD Description

Note: Versions mentioned in the description apply to the upstream e2fsprogs package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 e2fsprogs to version 1.43.4-2+deb9u1 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+deb9u2

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* e2fsprogs@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* e2fsprogs/e2fslibs@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* e2fsprogs/libcomerr2@1.43.4-2
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* e2fsprogs/libss2@1.43.4-2

NVD Description

Note: Versions mentioned in the description apply to the upstream e2fsprogs package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 e2fsprogs to version 1.43.4-2+deb9u2 or higher.

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:8u152-8.25.0.1@* elfutils/libelf1@0.168-1

NVD Description

Note: Versions mentioned in the description apply to the upstream elfutils package.

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.

Remediation

There is no fixed version for Debian:9 elfutils.

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:8u152-8.25.0.1@* elfutils/libelf1@0.168-1

NVD Description

Note: Versions mentioned in the description apply to the upstream elfutils package.

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.

Remediation

There is no fixed version for Debian:9 elfutils.

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:8u152-8.25.0.1@* freetype/libfreetype6@2.6.3-3.2

NVD Description

Note: Versions mentioned in the description apply to the upstream freetype package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 freetype to version 2.6.3-3.2+deb9u2 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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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.

Remediation

There is no fixed version for Debian:9 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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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.

Remediation

There is no fixed version for Debian:9 glibc.

References

medium severity

Loop with Unreachable Exit Condition ('Infinite Loop')

  • 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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

The iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid multi-byte input sequences in IBM1364, IBM1371, IBM1388, IBM1390, and IBM1399 encodings, fails to advance the input state, which could lead to an infinite loop in applications, resulting in a denial of service, a different vulnerability from CVE-2016-10228.

Remediation

There is no fixed version for Debian:9 glibc.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package. See Remediation section below for Debian:9 relevant versions.

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).

Remediation

Upgrade Debian:9 glibc to version 2.24-11+deb9u4 or higher.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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.

Remediation

There is no fixed version for Debian:9 glibc.

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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package.

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 Debian:9 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:8u152-8.25.0.1@* glibc/libc-bin@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/libc6@2.24-11+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* glibc/multiarch-support@2.24-11+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream glibc package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 glibc to version 2.24-11+deb9u2 or higher.

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:8u152-8.25.0.1@* gnutls28/libgnutls30@3.5.8-5+deb9u3

NVD Description

Note: Versions mentioned in the description apply to the upstream gnutls28 package.

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.

Remediation

There is no fixed version for Debian:9 gnutls28.

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:8u152-8.25.0.1@* gnutls28/libgnutls30@3.5.8-5+deb9u3

NVD Description

Note: Versions mentioned in the description apply to the upstream gnutls28 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 gnutls28 to version 3.5.8-5+deb9u4 or higher.

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:8u152-8.25.0.1@* gnutls28/libgnutls30@3.5.8-5+deb9u3

NVD Description

Note: Versions mentioned in the description apply to the upstream gnutls28 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 gnutls28 to version 3.5.8-5+deb9u4 or higher.

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:8u152-8.25.0.1@* gnutls28/libgnutls30@3.5.8-5+deb9u3

NVD Description

Note: Versions mentioned in the description apply to the upstream gnutls28 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 gnutls28 to version 3.5.8-5+deb9u4 or higher.

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:8u152-8.25.0.1@* libgcrypt20@1.7.6-2+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream libgcrypt20 package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 libgcrypt20 to version 1.7.6-2+deb9u3 or higher.

References

medium severity

Race Condition

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

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* libgcrypt20@1.7.6-2+deb9u2

NVD Description

Note: Versions mentioned in the description apply to the upstream libgcrypt20 package.

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.

Remediation

There is no fixed version for Debian:9 libgcrypt20.

References

medium severity

Use After Free

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

Detailed paths

  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* libpng1.6/libpng16-16@1.6.28-1

NVD Description

Note: Versions mentioned in the description apply to the upstream libpng1.6 package. See Remediation section below for Debian:9 relevant versions.

png_image_free in png.c in libpng 1.6.x before 1.6.37 has a use-after-free because png_image_free_function is called under png_safe_execute.

Remediation

Upgrade Debian:9 libpng1.6 to version 1.6.28-1+deb9u1 or higher.

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:8u152-8.25.0.1@* libx11/libx11-6@2:1.6.4-3
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* libx11/libx11-data@2:1.6.4-3

NVD Description

Note: Versions mentioned in the description apply to the upstream libx11 package. See Remediation section below for Debian:9 relevant versions.

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 Debian:9 libx11 to version 2:1.6.4-3+deb9u2 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:8u152-8.25.0.1@* nettle/libhogweed4@3.3-1+b2
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* nettle/libnettle6@3.3-1+b2

NVD Description

Note: Versions mentioned in the description apply to the upstream nettle package.

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.

Remediation

There is no fixed version for Debian:9 nettle.

References

medium severity

Access Restriction Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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

Access Restriction Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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. A flaw was found in the way the ForkJoinPool class in the Libraries component of OpenJDK handled its access control context. This could possibly lead to code being executed with incorrect permissions, possibly leading to bypass of certain intended restrictions defined by a SecurityManager.

Remediation

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

References

medium severity

Command Injection

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_291

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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 Command Injection. It was discovered that the implementation of ProcessBuilder in the Libraries component of OpenJDK on the Windows platform did not properly detect command arguments that were not quoted correctly. This could lead to manipulation of command arguments when executing processes with arguments from untrusted sources.

Remediation

Upgrade openjdk-jre to version 16.0.1, 11.0.11, 8.0.291, 7.0.301 or higher.

References

medium severity

Cross-site Scripting (XSS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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

Cryptographic Weakness

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_291

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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 Weakness. A flaw was found in the way the Libraries component of OpenJDK enforced constraints defined in the jdk.jar.disabledAlgorithms security property. Verification of a JAR file signed using a disabled algorithm could succeed in certain cases, leading to bypass of the intended security restrictions.

This vulnerability applies to Java deployments that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.

Remediation

Upgrade openjdk-jre to version 16.0.1, 11.0.11, 8.0.291, 7.0.301 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_182

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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. 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 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 8.0.161 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_171

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_181

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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 Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_191

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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: Serviceability). Easily exploitable vulnerability allows low privileged 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 creation, deletion or modification access to critical data or all Java SE, Java SE Embedded accessible data as well as 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 (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). This vulnerability can only be exploited when Java Usage Tracker functionality is being used.

Remediation

Upgrade openjdk-jre to version 8.0.191 or higher.

References

medium severity

Improper Handling

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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
new

Improper Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_301

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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 Validation. A flaw was found in the way the FtpClient implementation in the Networking component of OpenJDK handled responses to the FTP PASV command. A malicious FTP server could cause a Java application using FtpClient to connect to a host and port that is not accessible from the FTP server and perform port scanning or banner extraction.

Remediation

Upgrade openjdk-jre to version 7.0.311, 8.0.301, 11.0.12, 16.0.2 or higher.

References

medium severity

Information Exposure

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_161

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_271

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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.8.0_152-b16
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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
new

Signature Validation Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_152-b16
  • Fixed in: 1.8.0_301

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-debian@8u152-8.25.0.1 openjdk-jre@1.8.0_152-b16

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 Signature Validation Bypass. A flaw was found in the way the Library component of OpenJDK handled JAR files containing multiple MANIFEST.MF files. Such JAR files could cause signature verification process to return an incorrect result, possibly allowing tampering with signed JAR files.

Remediation

Upgrade openjdk-jre to version 7.0.311, 8.0.301, 11.0.12, 16.0.2 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:8u152-8.25.0.1@* openldap/libldap-2.4-2@2.4.44+dfsg-5+deb9u1
  • Introduced through: azul/zulu-openjdk-debian:8u152-8.25.0.1@* openldap/libldap-common@2.4.44+dfsg-5+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openldap package. See Remediation section below for Debian:9 relevant versions.

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.)

Remediation

Upgrade Debian:9 openldap to version 2.4.44+dfsg-5+deb9u3 or higher.

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:8u152-8.25.0.1@* openssl/libssl1.1@1.1.0f-3+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openssl package. See Remediation section below for Debian:9 relevant versions.

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).

Remediation

Upgrade Debian:9 openssl to version 1.1.0f-3+deb9u2 or higher.

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:8u152-8.25.0.1@* openssl/libssl1.1@1.1.0f-3+deb9u1

NVD Description

Note: Versions mentioned in the description apply to the upstream openssl package. See Remediation section below for Debian:9 relevant versions.

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.

Remediation

Upgrade Debian:9 openssl to version 1.1.0f-3+deb9u2 or higher.

References