CVE-2024-47083

Power Platform Terraform Provider allows managing environments and other resources within Power Platform. Versions prior to 3.0.0 have an issue in the Power Platform Terraform Provider where sensitive information, specifically the client_secret used in the service principal authentication, may be exposed in logs. This exposure occurs due to an error in the logging code that causes the client_secret to not be properly masked when logs are persisted or viewed. Users should upgrade to version 3.0.0 to receive a patched version of the provider that removes all logging of sensitive content. Users who have used this provider with the affected versions should take the following additional steps to mitigate the risk: Immediately rotate the client_secret for any service principal that has been configured using this Terraform provider. This will invalidate any potentially exposed secrets. Those who have set the TF_LOG_PATH environment variable or configured Terraform to persist logs to a file or an external system, consider disabling this until they have updated to a fixed version of the provider. Those who have existing logs that may contain the client_secret should remove or sanitize these logs to prevent unauthorized access. This includes logs on disk, in monitoring systems, or in logging services.

Weakness

The product does not neutralize or incorrectly neutralizes output that is written to logs.

Affected Software

Extended Description

This can allow an attacker to forge log entries or inject malicious content into logs. Log forging vulnerabilities occur when:

Potential Mitigations

• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/268.html
• https://cwe.mitre.org/data/definitions/81.html
• https://cwe.mitre.org/data/definitions/93.html

References

• https://github.com/microsoft/terraform-provider-power-platform/releases/tag/v3.0.0
• https://github.com/microsoft/terraform-provider-power-platform/security/advisories/GHSA-7w3w-pjm5-m36c
• https://registry.terraform.io/providers/microsoft/power-platform/latest/docs#authenticating-to-power-platform-using-a-service-principal-with-oidc