Vulnerabilities

Issue #13 - Pipe permissions too open on Unix.

Affected Versions

Versions between 3.5.8 and 3.5.60.

Severity

Critical (if sensitive data are passed via the backend, which is possible since version 3.5.57, and the backend is set to PIPE)

Description

When using wrapper.backend.type=PIPE, the Wrapper would create named pipe with permissions that are too open. Windows Editions are not affected and can use PIPE safely.

There is a security concern when wrapper.app.property properties were used to pass sensitive data via the backend as it was possible for any user with access to the server to view the contents of the pipe.

The default transmission type uses SOCKET, which does not have this problem.

Workarounds

Issue #12 - SeImpersonate privilege enabled for Windows Services.

Affected Versions

All versions before 3.5.58.

Severity

Warning

Description

For compatibility with older versions of Windows, Microsoft has decided that SeImpersonatePrivilege will be enabled by default for Windows services. This privilege is automatically added by the service control manager (SCM) via dynamic addition of the SERVICE group when a service is started.

SeImpersonatePrivilege lets a process borrow the identity of a different user. While this can be useful to test how the process behaves under different user contexts, this can also pose significant security risks. The privilege can indeed be abused by to escalate to the LocalSystem account which has the highest privileges level on a Windows system.

This security issue only applies to services configured to run with an account other than LocalSystem (otherwise the service already has the highest possible privileges). However, it is often a good idea to run under a dedicated service account in order to restrict access of the Java application on the hosting system, and conversely, to prevent other third-party processes from accessing the application and Wrapper files.

Starting with version 3.5.58, the Wrapper will disable SeImpersonatePrivilege when running as a Windows service with an account other than LocalSystem (NT AUTHORITY\SYSTEM). Most Java applications will not need this privilege, but in case it is needed the wrapper.ntservice.impersonation property can be used to re-enable it.

Workarounds

Issue #11 - WrapperManager.log() and '%' characters.

Affected Versions

All versions before 3.5.58.

Severity

High (if the conditions below are met).

Description

The Wrapper Java API provides the WrapperManager.log() method to allow user code to log a message at the specified log level. If the second argument, which is the message to log, contained a '%' character, the Wrapper could crash causing a denial of service.

Your application is at risk if it uses user inputs that are ultimately passed to the WrapperManager.log() method.

Workarounds

Issue #10 - Windows binaries signed with revoked certificate.

Affected Versions

Version 3.5.55.

Severity

Warning

Description

Windows binaries not signed.

Workarounds

Please use version 3.5.56, which is signed with an upgraded EV certificate.

Issue #9 - Jar signed with old certificate.

Affected Versions

Versions 3.5.44 and 3.5.45.

Severity

Warning

Description

Jar file is signed with an older code signing certificate (expiring on 2020-12-15 but with a timestamp valid until 2027-06-27).

The jar file is safe to execute.

Workarounds

No special action required.

Issue #8 - Windows binaries not signed.

Affected Versions

Version 3.5.44.

Severity

Medium

Description

The Windows binaries (wrapper.exe, wrapperw.exe, wrapper.dll) are not digitally signed.

Although the lack of a signature does not in itself pose a security threat, it is not possible to verify the authenticity and integrity of binaries without a digital signature. Microsoft Defender SmartScreen may therefore block the first execution and warn of a security risk.

Workarounds

Issue #7 - Non-ANSI encoding and JVM output containing '%' characters.

Affected Versions

Versions between 3.5.35 and 3.5.40.

Severity

High (when wrapper.lang.windows.encoding is used)

Description

Starting with version 3.5.35, wrapper.lang.windows.encoding makes it possible to change the encoding of the locale used by the Wrapper process. This is useful for example to print the log output in UTF-8 or using a specific encoding.

When wrapper.lang.windows.encoding is set, the Wrapper reads the JVM output in a different mode. This mode has a bug where a percentage character '%' in the JVM output could cause the Wrapper to crash.

Your application is particularly exposed if client user input can end up in the logs, making it vulnerable to denial of service attacks.

Workarounds

Issue #6 - Large UTF-8 output messages on Windows.

Affected Versions

Version 3.5.35.

Severity

High

Description

wrapper.lang.windows.encoding makes it possible to change the encoding of the locale used by the Wrapper process. UTF-8 strings are handled with a separate function that uses a fixed-size buffer of 4096 characters. JVM output larger than this width would cause a buffer overflow. JVM output larger than this width would cause a buffer overflow.

Your application is particularly at risk if large user inputs can end up in the logs, as they could cause the Wrapper to crash and lead to a denial of service.

The Wrapper is not affected when wrapper.lang.windows.encoding is left to its default value 'ANSI' or when an encoding other than UTF-8 is used.

Workarounds

Issue #5 - Default umask set to 0000 for Unix Daemons.

Affected Versions

Versions between 3.5.8 and 3.5.11.

Severity

Critical

Description

On UNIX platforms, the default umask is set to 0000 rather than inheriting the value from the parent process when running as a daemon process.

The log and other files have global read/write access.

The default umask of the Java process would also be 0000, and thus of any files created by the Java application, unless they explicitly set new permissions.

The anchor file, if used, can be deleted by anyone and cause the Wrapper to stop.

Workarounds

Issue #4 - Failure with strict SELinux security policy.

Affected Versions

All versions before 3.3.7.

Severity

Warning

Description

Strict SELinux security policy could prevent the wrapper from loading the libwrapper.so library.

This is only a problem when running on a system with SELinux enabled.

Workarounds

Issue #3 - Denial of service when caused by system signals on Unix.

Affected Versions

All versions before 3.3.0.

Severity

High

Description

Crashes may occasionally occur with 64-bit UNIX caused by a native synchronization problem when system signals are trapped. Bug #1614010.

This vulnerability could be used by third-party processes to attempt denial of service attacks.

32-bit binaries are not affected. Windows is not affected.

Workarounds

Issue #2 - wrapper.ntservice.password stored in registry.

Affected Versions

Versions between 3.0.0 and 3.1.2, and then between 3.2.2 and 3.2.3.

Severity

High

Description

The value of the wrapper.ntservice.account and wrapper.ntservice.password were being stored in plain text within the registry if they were specified on the command line when installing the Wrapper as a Windows service.

Workarounds

Issue #1 - JVM output and '%' characters.

Affected Versions

All versions before 2.2.6.

Severity

High

Description

A percentage character '%' in the JVM output could cause the Wrapper to crash.

Your application is particularly exposed if client user input can end up in the logs, making it vulnerable to denial of service attacks.

Workarounds