CVE-2024-41129

The ops library is a Python framework for developing and testing Kubernetes and machine charms. The issue here is that ops passes the secret content as one of the args via CLI. This issue may affect any of the charms that are using: Juju (>=3.0), Juju secrets and not correctly capturing and processing subprocess.CalledProcessError. This vulnerability is fixed in 2.15.0.

The ops library is a Python framework for developing and testing Kubernetes and machine charms. The issue here is that ops passes the secret content as one of the args via CLI. This issue may affect any of the charms that are using: Juju (>=3.0), Juju secrets and not correctly capturing and processing subprocess.CalledProcessError. This vulnerability is fixed in 2.15.0.

Summary

The issue here is that we pass the secret content as one of the args via CLI. This issue may affect any of our charms that are using: Juju (>=3.0), Juju secrets and not correctly capturing and processing subprocess.CalledProcessError.

There are two points that may log this command, in different files:

First, if there is an error during a secret handling, there will be a subprocess.CalledProcessError, which will contain the CLI comand + all its args. This is going to be logged in any logging level. This exception, if not caught by the charm, will bubble up to the /var/log/juju/ logs and syslog journal. Now, on Ubuntu 22.04, these logs are protected with:

$ juju ssh -m controller 0 -- ls -la /var/log/juju/
total 224
drwxr-xr-x 2 syslog adm      4096 Jul 14 10:59 .
drwxrwxr-x 9 root   syslog   4096 Jul 14 10:58 ..
-rw-r----- 1 syslog adm     20124 Jul 14 11:10 audit.log
-rw-r----- 1 syslog adm    110432 Jul 14 11:10 logsink.log
-rw-r----- 1 syslog adm     80783 Jul 14 11:06 machine-0.log
-rw-r----- 1 syslog adm       766 Jul 14 11:10 machine-lock.log
-rw-r--r-- 1 root   root        0 Jul 14 10:59 slow-query.log
-rw-r----- 1 syslog adm      3732 Jul 14 11:10 unit-controller-0.log

Second, certain audit setups may log terminal commands, which would result in this command being logged with its secrets. It is unknown if this is done on ubuntu security benchmarks, such as CIS hardening.

Keep in mind these logs may be copied or even backed up. Which exposes it to more services in the user's environment (e.g. CI runs in GH - although these are dummy password generated per test only).

Passing secrets straight via CLI is not advised. Here are some ways out:

1. Redacting: which commands and which args represent secrets are known, so they can be redacted. It would also mean capturing a subprocess.CalledProcessError, redacting its content and reissuing the same type of exception; this will not cover the case auditd is set to log CLI commands, if that is a risk
2. Temp files: secret-add, for example, can use a secret file instead, as can be seen here. However, if ops uses a file, ops will need to be sure to correctly remove it later
3. stdin: not sure it is accepted by secret-* commands, but generally, secrets are not shown on CLI whilst typing them; auditd may not capture that stdin

Severity Rationale

This is a CWE-532. Potentially, these secrets can lead to privilege escalation but Ubuntu default is to have logs only accessible to adm group users.

Marking this issue as "Moderate", as this report is not presenting a clear way on how to get access to the logs themselves: either getting local access to an adm group user (e.g. ubuntu) or recovering logs stored on a 3rd party service.

Details

2024-07-12T14:27:58.0175389Z unit-opensearch-3: 14:27:53 ERROR unit.opensearch/3.juju-log certificates:11: Uncaught exception while in charm code:
2024-07-12T14:27:58.0175524Z Traceback (most recent call last):
2024-07-12T14:27:58.0175957Z   File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py", line 3180, in _run
2024-07-12T14:27:58.0176165Z     result = subprocess.run(args, **kwargs)  # type: ignore
2024-07-12T14:27:58.0176381Z   File "/usr/lib/python3.10/subprocess.py", line 526, in run
2024-07-12T14:27:58.0176561Z     raise CalledProcessError(retcode, process.args,
2024-07-12T14:27:58.0177749Z subprocess.CalledProcessError: Command '('/var/lib/juju/tools/unit-opensearch-3/secret-add', '--label', 'opensearch:app:app-admin', '--owner', 'application', 'keystore-password-ca=aUE...')' returned non-zero exit status 1.
2024-07-12T14:27:58.0177765Z
2024-07-12T14:27:58.0178023Z The above exception was the direct cause of the following exception:
2024-07-12T14:27:58.0178038Z
2024-07-12T14:27:58.0178168Z Traceback (most recent call last):…

The ops library is a Python framework for developing and testing Kubernetes and machine charms. The issue here is that ops passes the secret content as one of the args via CLI. This issue may affect any of the charms that are using: Juju (>=3.0), Juju secrets and not correctly capturing and processing subprocess.CalledProcessError. This vulnerability is fixed in 2.15.0.

The ops library is a Python framework for developing and testing Kubernetes and machine charms. The issue here is that ops passes the secret content as one of the args via CLI. This issue may affect any of the charms that are using: Juju (>=3.0), Juju secrets and not correctly capturing and processing subprocess.CalledProcessError. This vulnerability is fixed in 2.15.0.

Summary

The issue here is that we pass the secret content as one of the args via CLI. This issue may affect any of our charms that are using: Juju (>=3.0), Juju secrets and not correctly capturing and processing subprocess.CalledProcessError.

There are two points that may log this command, in different files:

First, if there is an error during a secret handling, there will be a subprocess.CalledProcessError, which will contain the CLI comand + all its args. This is going to be logged in any logging level. This exception, if not caught by the charm, will bubble up to the /var/log/juju/ logs and syslog journal. Now, on Ubuntu 22.04, these logs are protected with:

$ juju ssh -m controller 0 -- ls -la /var/log/juju/
total 224
drwxr-xr-x 2 syslog adm      4096 Jul 14 10:59 .
drwxrwxr-x 9 root   syslog   4096 Jul 14 10:58 ..
-rw-r----- 1 syslog adm     20124 Jul 14 11:10 audit.log
-rw-r----- 1 syslog adm    110432 Jul 14 11:10 logsink.log
-rw-r----- 1 syslog adm     80783 Jul 14 11:06 machine-0.log
-rw-r----- 1 syslog adm       766 Jul 14 11:10 machine-lock.log
-rw-r--r-- 1 root   root        0 Jul 14 10:59 slow-query.log
-rw-r----- 1 syslog adm      3732 Jul 14 11:10 unit-controller-0.log

Second, certain audit setups may log terminal commands, which would result in this command being logged with its secrets. It is unknown if this is done on ubuntu security benchmarks, such as CIS hardening.

Keep in mind these logs may be copied or even backed up. Which exposes it to more services in the user's environment (e.g. CI runs in GH - although these are dummy password generated per test only).

Passing secrets straight via CLI is not advised. Here are some ways out:

1. Redacting: which commands and which args represent secrets are known, so they can be redacted. It would also mean capturing a subprocess.CalledProcessError, redacting its content and reissuing the same type of exception; this will not cover the case auditd is set to log CLI commands, if that is a risk
2. Temp files: secret-add, for example, can use a secret file instead, as can be seen here. However, if ops uses a file, ops will need to be sure to correctly remove it later
3. stdin: not sure it is accepted by secret-* commands, but generally, secrets are not shown on CLI whilst typing them; auditd may not capture that stdin

Severity Rationale

This is a CWE-532. Potentially, these secrets can lead to privilege escalation but Ubuntu default is to have logs only accessible to adm group users.

Marking this issue as "Moderate", as this report is not presenting a clear way on how to get access to the logs themselves: either getting local access to an adm group user (e.g. ubuntu) or recovering logs stored on a 3rd party service.

Details

2024-07-12T14:27:58.0175389Z unit-opensearch-3: 14:27:53 ERROR unit.opensearch/3.juju-log certificates:11: Uncaught exception while in charm code:
2024-07-12T14:27:58.0175524Z Traceback (most recent call last):
2024-07-12T14:27:58.0175957Z   File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py", line 3180, in _run
2024-07-12T14:27:58.0176165Z     result = subprocess.run(args, **kwargs)  # type: ignore
2024-07-12T14:27:58.0176381Z   File "/usr/lib/python3.10/subprocess.py", line 526, in run
2024-07-12T14:27:58.0176561Z     raise CalledProcessError(retcode, process.args,
2024-07-12T14:27:58.0177749Z subprocess.CalledProcessError: Command '('/var/lib/juju/tools/unit-opensearch-3/secret-add', '--label', 'opensearch:app:app-admin', '--owner', 'application', 'keystore-password-ca=aUE...')' returned non-zero exit status 1.
2024-07-12T14:27:58.0177765Z
2024-07-12T14:27:58.0178023Z The above exception was the direct cause of the following exception:
2024-07-12T14:27:58.0178038Z
2024-07-12T14:27:58.0178168Z Traceback (most recent call last):…

Summary

The issue here is that we pass the secret content as one of the args via CLI. This issue may affect any of our charms that are using: Juju (>=3.0), Juju secrets and not correctly capturing and processing subprocess.CalledProcessError.

There are two points that may log this command, in different files:

First, if there is an error during a secret handling, there will be a subprocess.CalledProcessError, which will contain the CLI comand + all its args. This is going to be logged in any logging level. This exception, if not caught by the charm, will bubble up to the /var/log/juju/ logs and syslog journal. Now, on Ubuntu 22.04, these logs are protected with:

$ juju ssh -m controller 0 -- ls -la /var/log/juju/
total 224
drwxr-xr-x 2 syslog adm      4096 Jul 14 10:59 .
drwxrwxr-x 9 root   syslog   4096 Jul 14 10:58 ..
-rw-r----- 1 syslog adm     20124 Jul 14 11:10 audit.log
-rw-r----- 1 syslog adm    110432 Jul 14 11:10 logsink.log
-rw-r----- 1 syslog adm     80783 Jul 14 11:06 machine-0.log
-rw-r----- 1 syslog adm       766 Jul 14 11:10 machine-lock.log
-rw-r--r-- 1 root   root        0 Jul 14 10:59 slow-query.log
-rw-r----- 1 syslog adm      3732 Jul 14 11:10 unit-controller-0.log

Second, certain audit setups may log terminal commands, which would result in this command being logged with its secrets. It is unknown if this is done on ubuntu security benchmarks, such as CIS hardening.

Keep in mind these logs may be copied or even backed up. Which exposes it to more services in the user's environment (e.g. CI runs in GH - although these are dummy password generated per test only).

Passing secrets straight via CLI is not advised. Here are some ways out:

1. Redacting: which commands and which args represent secrets are known, so they can be redacted. It would also mean capturing a subprocess.CalledProcessError, redacting its content and reissuing the same type of exception; this will not cover the case auditd is set to log CLI commands, if that is a risk
2. Temp files: secret-add, for example, can use a secret file instead, as can be seen here. However, if ops uses a file, ops will need to be sure to correctly remove it later
3. stdin: not sure it is accepted by secret-* commands, but generally, secrets are not shown on CLI whilst typing them; auditd may not capture that stdin

Severity Rationale

This is a CWE-532. Potentially, these secrets can lead to privilege escalation but Ubuntu default is to have logs only accessible to adm group users.

Marking this issue as "Moderate", as this report is not presenting a clear way on how to get access to the logs themselves: either getting local access to an adm group user (e.g. ubuntu) or recovering logs stored on a 3rd party service.

Details

2024-07-12T14:27:58.0175389Z unit-opensearch-3: 14:27:53 ERROR unit.opensearch/3.juju-log certificates:11: Uncaught exception while in charm code:
2024-07-12T14:27:58.0175524Z Traceback (most recent call last):
2024-07-12T14:27:58.0175957Z   File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py", line 3180, in _run
2024-07-12T14:27:58.0176165Z     result = subprocess.run(args, **kwargs)  # type: ignore
2024-07-12T14:27:58.0176381Z   File "/usr/lib/python3.10/subprocess.py", line 526, in run
2024-07-12T14:27:58.0176561Z     raise CalledProcessError(retcode, process.args,
2024-07-12T14:27:58.0177749Z subprocess.CalledProcessError: Command '('/var/lib/juju/tools/unit-opensearch-3/secret-add', '--label', 'opensearch:app:app-admin', '--owner', 'application', 'keystore-password-ca=aUE...')' returned non-zero exit status 1.
2024-07-12T14:27:58.0177765Z
2024-07-12T14:27:58.0178023Z The above exception was the direct cause of the following exception:
2024-07-12T14:27:58.0178038Z
2024-07-12T14:27:58.0178168Z Traceback (most recent call last):…