PrivX versions between 22.0-33.0 perform improper input validation on a few REST API endpoints. This allows an authenticated user to bypass data read access controls and exfiltrate information normally not available. With a preliminary CVE score of 4.3, this vulnerability may pose a moderate security risk to affected PrivX deployments.
A successful attack can lead to the attacker extracting data from the PrivX database or causing database service level degradation or denial of service.
Attack does not enable plaintext credentials leak. Attacker is not able to modify database contents nor gain target resource access via this vulnerability.
There are no known publicly available exploits for this vulnerability.
The vulnerability is fixed in PrivX minor versions 33.1, 32.3, 31.3 and later, major version 34.0 and later, We recommend you upgrade your PrivX to a fixed version. A mitigation explained below is available in case upgrade is not possible.
The vulnerability can be mitigated in all affected PrivX versions by following the instructions below.
In RPM based deployment.
map $arg_sortdir $sortdir_is_valid {
default 0; # By default, consider sortdir as not valid, if query param is found
asc 1; # sortdir is valid if it's 'asc'
desc 1; # sortdir is valid if it's 'desc'
"" 1; # empty is valid
}
map $arg_sortkey $sortkey_is_valid {
default 0;
id 1;
user_id 1;
source_id 1;
domain 1;
username 1;
remote_addr 1;
type 1;
created 1;
updated 1;
expires 1;
token_expires 1;
"" 1;
}
2. Add the if blocks to the server block for port 443 between the SSL configuration directives and the include directives in /etc/nginx/conf.d/privx.conf
server {
listen 443 ssl http2;
client_max_body_size 1M;
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'AESGCM+EECDH:AESGCM+EDH:AES+EECDH:AES+EDH:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:-DSS:-EDH';
ssl_session_cache shared:SSL:10m;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;
if ($sortdir_is_valid = 0) {
# block invalid sortdir param
return 400;
}
if ($request_uri !~* ^/auth/api/v1/sessionstorage/) {
# for all other endpoints, allow any sortkey value
set $sortkey_is_valid 1;
}
if ($sortkey_is_valid = 0) {
# if sortkey is still marked as invalid, block the request
return 400;
}
include privx/privx-common.conf;
include privx/privx-csp.conf;
include privx/privx-https-location.conf;
}
In Kubernetes based deployment
1. Add the following annotation to the charts/privx/values.yaml file in the top- level setting ingress.common.annotationsnginx.ingress.kubernetes.io/configuration-snippet: |
set $sortdir_is_valid 0;
if ($arg_sortdir = asc) {
set $sortdir_is_valid 1;
}
if ($arg_sortdir = desc) {
set $sortdir_is_valid 1;
}
if ($arg_sortdir = "") {
set $sortdir_is_valid 1;
}
if ($sortdir_is_valid = 0) {
# block invalid sortdir param
return 400;
}
set $sortkey_is_valid 0;
if ($request_uri !~* ^/auth/api/v1/sessionstorage/) {
# for all other endpoints, allow any sortkey value
set $sortkey_is_valid 1;
}
if ($arg_sortkey = id) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = user_id) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = source_id) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = domain) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = username) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = remote_addr) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = type) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = created) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = updated) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = expires) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = token_expires) {
set $sortkey_is_valid 1;
}
if ($arg_sortkey = "") {
set $sortkey_is_valid 1;
}
if ($sortkey_is_valid = 0) {
# if sortkey is still marked as invalid, block the request
return 400;
}
2. Apply the changes by executing the following command:helm upgrade -f <override files> -n <privx namespace> <release name> <privx charts location>
Am I affected?
If your PrivX version is between 22.0-33.0 released before March 2024, then your PrivX is subject to this vulnerability. We recommend you apply mitigation as soon as possible and upgrade to fixed PrivX versions once they are available.
Am I protected by applying the mitigation?
Yes. Your PrivX is protected from the vulnerability by applying the mitigation. But we recommend you upgrade to fixed PrivX versions once they are available.
After applying a mitigation to my PrivX, are there any special steps I need to take for future upgrades?
No. You can upgrade to a fixed version of PrivX normally. The mitigation will be overwritten after upgrade as the mitigation is no longer needed in fixed version.
What PrivX versions contain the fix?
PrivX 33.1, 32.3, 31.3 and later.
PrivX 34.0 and later.
My PrivX version is affected but is out of official support, will I receive a point release for this version?
No. But applying the mitigation will protect you from the vulnerability, and we recommend you upgrade to supported PrivX version as soon as you can.
When this CVE will be disclosed?
The CVE is currently confidential to allow enough time for customers to apply mitigation or upgrade. Details of this CVE will be disclosed on 5th of August, 2024.
