Bug 1210928

This instance of CVE-2023-22644 affects also CachedStatement.java class where, in various debug() calls, the SQL statement with all parameters are logged into debug file if debug is enabled.

This can be an issue if parameters contain some sort of secrets because their protection is out of the DB configuration realm but they will be public in log files and accessible to anyone. 

It would be a better approach to strip out queries parameter or having them logged in a separate file with a robust permission schema (readable only by root is a good choice)

In addition to this, I would also suggest a change in the L3 process.

To make sure we won't use any secret contained in log files, we can't put in the loop in case of third-party misuse of access credentials.

Consider this scenario. Customer A asks for L3 support and sends us log files. In log files, a password or an access token is stored.

Someone breaches Customer A. Customer A, to avoid being filed can say "look... I know that SUSE is logging credentials and we gave logs to them, maybe they were breached as well, or (even worse) they use those secrets to access our network."

I know this sounds so Machiavellian but from a security perspective, this can be a risk scenario for us and I want to avoid the Company can occur in it.

So my suggestion is, and please revise it with legal:
1. inform the customer that, when collecting logs for a support call, secrets *could be* saved in log files
2. ask the customer to delete all SUMA logs before replicating the problematic situation, to make sure we start from blank content
3. set the SUMA admin password as a temporary value before collecting data
4. the customer replicates the scenario and sends us the debug log file
5. the customer changes the admin password

Please evaluate this as a further engagement process improvement. In cybersecurity we don't deal only with cross site scriptings or sql injection but most of time with business logic weaknesses.

(In reply to Paolo Perego from comment #7)
> In addition to this, I would also suggest a change in the L3 process.
> 
> To make sure we won't use any secret contained in log files, we can't put in
> the loop in case of third-party misuse of access credentials.
> 
> Consider this scenario. Customer A asks for L3 support and sends us log
> files. In log files, a password or an access token is stored.
> 
> Someone breaches Customer A. Customer A, to avoid being filed can say
> "look... I know that SUSE is logging credentials and we gave logs to them,
> maybe they were breached as well, or (even worse) they use those secrets to
> access our network."
> 
> I know this sounds so Machiavellian but from a security perspective, this
> can be a risk scenario for us and I want to avoid the Company can occur in
> it.
> 
> So my suggestion is, and please revise it with legal:
> 1. inform the customer that, when collecting logs for a support call,
> secrets *could be* saved in log files
> 2. ask the customer to delete all SUMA logs before replicating the
> problematic situation, to make sure we start from blank content
> 3. set the SUMA admin password as a temporary value before collecting data
> 4. the customer replicates the scenario and sends us the debug log file
> 5. the customer changes the admin password
> 
> Please evaluate this as a further engagement process improvement. In
> cybersecurity we don't deal only with cross site scriptings or sql injection
> but most of time with business logic weaknesses.

Thanks Paolo, I understand there is a certain risk here. We will need to bring this suggestion to the L3 team though, as they will in the end need to advise customers accordingly. This sounds like it could become a significant overhead for everyone involved, so I understand you would suggest this is needed only in case the previously discussed logging of SQL statements and remote commands should be enabled, which in any case will need to be done explicitly?

Paolo: The fix will be in 4.3.10 and in the next Uyuni version (2023.11).
Code is merged in all active branches.

Re-assign this bug to you for further tracking and closing.

(In reply to Michael Calmer from comment #13)
> Paolo: The fix will be in 4.3.10 and in the next Uyuni version (2023.11).
> Code is merged in all active branches.
> 
> Re-assign this bug to you for further tracking and closing.

Thank you so much Michael!

SUSE-SU-2023:4758-1: An update that solves one vulnerability, contains one feature and has 30 security fixes can now be installed.

Category: security (important)
Bug References: 1191143, 1204235, 1207012, 1207532, 1210928, 1210930, 1211355, 1211560, 1211649, 1212695, 1212904, 1213469, 1214186, 1214471, 1214601, 1214759, 1215209, 1215514, 1215949, 1216030, 1216041, 1216085, 1216128, 1216380, 1216506, 1216555, 1216690, 1216754, 1217038, 1217223, 1217224
CVE References: CVE-2023-22644
Jira References: MSQA-708
Sources used:
openSUSE Leap 15.4 (src): release-notes-susemanager-4.3.10-150400.3.93.1, release-notes-susemanager-proxy-4.3.10-150400.3.72.1
SUSE Manager Proxy 4.3 (src): release-notes-susemanager-proxy-4.3.10-150400.3.72.1
SUSE Manager Retail Branch Server 4.3 (src): release-notes-susemanager-proxy-4.3.10-150400.3.72.1
SUSE Manager Server 4.3 (src): release-notes-susemanager-4.3.10-150400.3.93.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2023:4737-1: An update that solves one vulnerability, contains two features and has 30 security fixes can now be installed.

Category: security (important)
Bug References: 1191143, 1204235, 1207012, 1207532, 1210928, 1210930, 1211355, 1211560, 1211649, 1212695, 1212904, 1213469, 1214186, 1214471, 1214601, 1214759, 1215209, 1215514, 1215949, 1216030, 1216041, 1216085, 1216128, 1216380, 1216506, 1216555, 1216690, 1216754, 1217038, 1217223, 1217224
CVE References: CVE-2023-22644
Jira References: MSQA-708, SUMA-282
Sources used:
openSUSE Leap 15.4 (src): apache2-mod_wsgi-4.7.1-150400.3.9.4
openSUSE Leap 15.5 (src): apache2-mod_wsgi-4.7.1-150400.3.9.4
Public Cloud Module 15-SP4 (src): apache2-mod_wsgi-4.7.1-150400.3.9.4
Public Cloud Module 15-SP5 (src): apache2-mod_wsgi-4.7.1-150400.3.9.4
SUSE Manager Proxy 4.3 Module 4.3 (src): spacecmd-4.3.25-150400.3.30.5, apache2-mod_wsgi-4.7.1-150400.3.9.4, spacewalk-proxy-4.3.17-150400.3.23.5, spacewalk-web-4.3.36-150400.3.36.7, spacewalk-client-tools-4.3.17-150400.3.21.6, spacewalk-backend-4.3.25-150400.3.33.7, susemanager-tftpsync-recv-4.3.9-150400.3.9.5
SUSE Manager Server 4.3 Module 4.3 (src): spacewalk-search-4.3.10-150400.3.15.4, susemanager-sync-data-4.3.14-150400.3.17.5, inter-server-sync-0.3.1-150400.3.24.5, uyuni-reportdb-schema-4.3.8-150400.3.9.6, susemanager-schema-4.3.22-150400.3.30.5, spacewalk-java-4.3.69-150400.3.69.5, susemanager-docs_en-4.3-150400.9.50.5, subscription-matcher-0.33-150400.3.16.3, susemanager-sls-4.3.37-150400.3.37.5, spacewalk-client-tools-4.3.17-150400.3.21.6, susemanager-4.3.33-150400.3.42.4, billing-data-service-4.3.2-150400.10.12.5, spacecmd-4.3.25-150400.3.30.5, spacewalk-backend-4.3.25-150400.3.33.7, apache2-mod_wsgi-4.7.1-150400.3.9.4, spacewalk-web-4.3.36-150400.3.36.7

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

Fixed