Vulnerabilities

Versions from 3.5.8 to 3.5.60.

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

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

• Use wrapper.backend.type=SOCKET, or

• Upgrade to Wrapper version 3.6.0 (or higher), which use anonymous pipes with appropriate permissions.

All versions before 3.5.58.

Warning

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.

• Upgrade to Wrapper version 3.5.58 or higher.

• Set the required privileges for the service (requires the Professional Edition, version 3.5.57 or higher).

• It is possible to edit the Local Security Policy settings, but there is a risk of affecting other services (not recommended).

All versions before 3.5.58.

High (if the conditions below are met).

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.

• Upgrade to Wrapper version 3.5.58 or higher.

• Or, make sure to strip any '%' character in the message to log before calling WrapperManager.log().

Version 3.5.55.

Warning

Windows binaries not signed.

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

Versions 3.5.44 and 3.5.45.

Warning

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.

No special action required.

Version 3.5.44.

Medium

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.

• Upgrade to Wrapper version 3.5.45 or higher.

• Always make sure to download the Wrapper binaries from the official Java Service Wrapper website and store them in a safe place where they can't be altered.

Versions from 3.5.35 to 3.5.40.

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

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.

• Upgrade to Wrapper version 3.5.41 or higher, or

• Comment wrapper.lang.windows.encoding or set it to its default value (ANSI).

Version 3.5.35.

High

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.

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.

• Upgrade to Wrapper version 3.5.41 or higher, or

• Set wrapper.lang.windows.encoding to a value other than UTF-8.

Versions from 3.5.8 to 3.5.11.

Critical

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.

• Upgrade to Wrapper version 3.5.12 or higher, or

• Set the wrapper.umask property to a safe value.

All versions before 3.3.7.

Warning

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.

• Upgrade to Wrapper version 3.3.7 or higher.

All versions before 3.3.0.

High

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.

• Upgrade to Wrapper version 3.3.0 or higher, or

• Use wrapper.ignore_signals=TRUE (not recommended).

Versions from 3.0.0 to 3.1.2, and then from 3.2.2 to 3.2.3.

High

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.

• Bug #1538725

• Bug #1110183

• Upgrade to Wrapper version 3.1.2 or higher.

• Do not specify wrapper.ntservice.account or wrapper.ntservice.password on the command line when installing the Wrapper as a Windows service.

All versions before 2.2.6.

High

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.

• Upgrade to Wrapper version 2.2.6 or higher.