IBM Security Verify Access OIDC Provider could disclose directory information that could aid attackers in further attacks against the system. IBM X-Force ID: 239445.

Read More

IBM Security Verify Access OIDC Provider could allow a remote user to cause a denial of service due to uncontrolled resource consumption. IBM X-Force ID: 238921.

Read More

IBM Security Directory Server 6.4.0 could allow a remote attacker to traverse directories on the system. An attacker could send a specially-crafted URL request containing “dot dot” sequences (/../) to view arbitrary files on the system. IBM X-Force ID: 228582.

Read More

IBM Security Directory Server 6.4.0 could allow a remote attacker to obtain sensitive information, caused by the failure to properly enable HTTP Strict Transport Security. An attacker could exploit this vulnerability to obtain sensitive information using man in the middle techniques. X-Force ID: 228569.

Read More

IBM Security Directory Server 6.4.0 is vulnerable to an XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this vulnerability to expose sensitive information or consume memory resources. IBM X-Force ID: 228505.

Read More

FEDORA-2023-89ade611ee

Packages in this update:

gdb-13.2-10.fc39

Update description:

Backport upstream commit d28fbc7197b which fixes RHBZ 2233965, Security fix for CVE-2022-48065

Read More

FEDORA-2023-c33188f575

Packages in this update:

nats-server-2.10.3-1.fc38

Update description:

Without any authorization rules in the nats-server, users can connect
without authentication.

Before nats-server 2.2.0, all authentication and authorization rules for
a nats-server lived in an “authorization” block, defining users. With
nats-server 2.2.0 all users live inside accounts. When using the
authorization block, whose syntax predates this, those users will be
placed into the implicit global account, “$G”. Users inside accounts go
into the newer “accounts” block.

If an “accounts” block is defined, in simple deployment scenarios this
is often used only to enable client access to the system account. When
the only account added is the system account “$SYS”, the nats-server
would create an implicit user in “$G” and set it as the no_auth_user
account, enabling the same “without authentication” logic as without
any rules.

This preserved the ability to connect simply, and then add one
authenticated login for system access.

But with an “authorization” block, this is wrong. Users exist in the
global account, with login rules. And in simple testing, they might
still connect fine without administrators seeing that authentication has
been disabled.

The blind-spot on our part came from encouraging and documenting a
switch to using only “accounts”, instead of “authorization”.

In the fixed versions, using an “authorization” block will inhibit the
implicit creation of a “$G” user and setting it as the no_auth_user
target. In unfixed versions, just creating a second account, with no
users, will also inhibit this behavior.

Read More