Richard Zowalla

After a successful WS-Security UsernameToken authentication, the caller identity stays associated with the worker thread once the request completes when web services are served by the standalone OpenEJB HTTP server. A remote unauthenticated attacker whose request is later processed on the same thread can invoke protected EJB methods with the identity of a previously authenticated user. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.

The embedded OpenEJB HTTP server does not isolate HTTP sessions between web applications. A remote attacker can use a session established in one web application in another one, which then trusts session state set by the first application. Only deployments hosting several web applications on the embedded HTTP server are affected. Users are recommended to block network access to the embedded HTTP server from untrusted clients, or to migrate to the Tomcat based TomEE distributions.

When resolving security roles of a realm-authenticated caller, the caller's user name is also treated as a role name in addition to the roles assigned by the realm. An authenticated attacker who can obtain an account whose user name equals a role name, for example through self-registration, is granted that role wherever authorization is evaluated through the Jakarta Authorization policy. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.

The Jakarta Security identity store backed by the Tomcat user database compares the supplied password with the stored value as plain text and ignores the configured credential handler. When digested passwords are stored, an attacker who obtained a stored digest, for example from a leaked users file or backup, can authenticate with the digest instead of the password. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.

The development-time LiveReload support listens on all network interfaces without authentication and accepts websocket connections from any origin. A network attacker, or a web page visited by the developer, can observe the names of changed files in the watched folder and the server version, and reach the deployed applications through the additional port. This only affects LiveReload enabled in the embedded Maven plugin. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.

The embedded OpenEJB HTTP server reports every request as authenticated when an application requests authentication programmatically. A remote unauthenticated attacker can access functionality protected this way. Only applications served by the embedded HTTP server that rely on programmatic authentication are affected. Users are recommended to block network access to the embedded HTTP server from untrusted clients, or to migrate to the Tomcat based TomEE distributions.

The admin service of the standalone OpenEJB server accepts stop requests without any authentication. Any local user or process able to connect to the admin port can stop the server, leading to denial of service; the admin service is enabled by default in the standalone server and bound to the loopback interface. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.

The optional SSH administration service grants full access to the administration shell to every user that authenticates against its configured login domain, without checking for an administrative role. An attacker holding the credentials of any user in that domain, including a low-privileged application user, can execute arbitrary code as the server process. Users are recommended to disable the SSH administration service, or to block network access to it from untrusted clients and restrict its login domain to administrative users.

The JDBC based JAAS login module accepts a login without a password for accounts whose stored password is NULL. A remote attacker who knows the user name of such an account can authenticate as that user and obtain its roles. Only deployments using this login module with NULL passwords in the user table are affected. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.

When a non-default stateful session bean passivation strategy is configured, passivated bean state is written to predictably named files in the shared system temporary directory, reusing files that already exist there, and is deserialized on activation. A local attacker who can write to that directory can read passivated session state or supply data that the server deserializes, potentially leading to code execution as the server process. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.

When MicroProfile JWT authentication is used for servlets that declare a run-as identity, the security state established for a request is not always cleared from the processing thread when the request does not complete normally. A remote attacker holding a valid token can cause later, unrelated requests served by the same thread to invoke enterprise beans with the elevated run-as identity. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.

A negative MicroProfile JWT clock skew setting is not rejected and disables validation of the token expiration and other time-based claims. In such configurations, an attacker in possession of an expired token can still authenticate with it. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.

Ao utilizar o controle de acesso baseado em funções do MicroProfile JWT, as restrições de acesso dos recursos JAX-RS nem sempre são aplicadas conforme declarado. Isso ocorre quando os recursos declaram um conjunto vazio de funções permitidas, quando classes de recursos herdam o mesmo método de uma superclasse comum, ou quando restrições ao nível de classe são declaradas em uma superclasse. Um invasor remoto pode explorar essas falhas para invocar recursos que deveriam ser negados e, em algumas configurações, sem autenticação.

Quando o transporte TLS está habilitado sem exigir a autenticação de certificado do cliente, o `TlsTransportPlugin` atribui um principal de fallback (CN=ANONYMOUS) se nenhum certificado do cliente for apresentado ou se a verificação falhar. Isso ocorre porque a `SSLPeerUnverifiedException` é capturada e suprimida em vez de rejeitar a conexão. Esse comportamento de falha aberta permite que clientes não autenticados estabeleçam uma conexão TLS e recebam uma identidade de principal válida. Se o autorizador configurado, como o `SimpleACLAuthorizer`, não negar explicitamente o acesso ao CN=ANONYMOUS, isso pode resultar em acesso não autorizado aos serviços. Esta condição é registrada apenas no nível de depuração (debug), reduzindo a visibilidade em ambientes de produção.