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.
Or, upgrade to Wrapper version 3.6.0 (or higher), which use anonymous pipes with appropriate permissions.
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
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).
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
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().
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
Upgrade to Wrapper version 3.5.45 or higher.
Always make sure to download the Wrapper binaries from the official Wrapper website and store them in a safe place where they can't be altered.
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
Upgrade to Wrapper version 3.5.41 or higher.
Or, comment wrapper.lang.windows.encoding or set it to its default value (ANSI).
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
Upgrade to Wrapper version 3.5.41 or higher.
Or, set wrapper.lang.windows.encoding to a value other than UTF-8.
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
Upgrade to Wrapper version 3.5.12 or higher.
Or, set the wrapper.umask property to a safe value.
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
Upgrade to Wrapper version 3.3.7 or higher.
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.
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.