Summary
In SPIRE before versions 0.8.5, 0.9.4, 0.10.2, 0.11.3 and 0.12.1, the "aws_iid" Node Attestor improperly normalizes the path provided through the agent ID templating feature, which may allow the issuance of an arbitrary SPIFFE ID within the same trust domain, if the attacker controls the value of an EC2 tag prior to attestation, and the attestor is configured for agent ID templating where the tag value is the last element in the path. This issue has been fixed in SPIRE versions 0.11.3 and 0.12.1.
What are the changes introduced by the patched versions?
The patched versions no longer apply path normalization when generating agent IDs in the aws_iid, gcp_iit, x509pop and sshpop node attestors.
The patched versions also include a patched k8s-workload-registrar, which no longer applies path normalization prior to registering SPIFFE IDs with SPIRE Server.
Further Behavioral Changes
The patched versions further introduce several safety checks to improve consistency of the normalization of SPIFFE IDs, which previously may have resulted in surprising behavior. These checks may be disabled through the use of the allow_unsafe_ids configurable - please see the Upgrade Considerations section below for more information.
SPIRE Server now rejects API requests containing non-normalized SPIFFE IDs, as well as API requests from callers presenting client certificates containing a non-normalized SPIFFE ID. Specifically, this means that all SPIFFE IDs must:
- Have a "spiffe" scheme.
- Have a lowercase host component.
- Have a path without a trailing slash (including
/).
- Not include a path with empty,
., or .. segments.
- Not include percent encoded ASCII characters.
- Not include a mix of percent-encoded and raw UTF-8 characters.
This includes the following APIs:
- Entry API
BatchCreateEntryBatchUpdateEntry
- SVID API
- Agent API
- Legacy Registration API
MintX509SVIDMintJWTSVIDCreateEntryCreateEntryIfNotExistsUpdateEntry
Agent ID normalization is also enforced with the patched releases. In addition to the normalization rules described above, patched releases will also reject IDs produced by node attestors that look like the SPIRE Server ID.
Upgrade considerations
While the patch that closes the vulnerability is relatively small and targeted, the patched releases also ship with a number of behavioral changes intended to promote safety and avoid surprising behavior. These additional changes can be easily disabled through the use of the allow_unsafe_ids configurable (below). This section describes how to determine if your SPIRE deployment is affected by this behavioral change.
There is a small chance that registration entries with non-normalized SPIFFE IDs already exist in your SPIRE deployment (e.g. registration entries with SPIFFE IDs that include percent encoded ASCII). When a patched version of SPIRE Server starts, it will scan for such entries. If any are found, they will be logged at the Error level with the following message: Ignoring entry with invalid [spiffeID, parentID]; this entry will be automatically deleted by a future release. SPIRE Server will additionally emit a telemetry gauge indicating how many entries were ignored using the entry.ignored key. These ignored entries will not be honored by a patched SPIRE Server unless the allow_unsafe_ids configurable is set. Operators optimizing for availability may choose to upgrade a single SPIRE Server while blocking client traffic, such that the affected entries will be logged without affecting the workloads which they describe.
Finally, if you are using custom node attestors, please ensure that they generate normalized SPIFFE IDs (see Further Behavioral Changes above). Node attestations that result in non-normalized IDs will fail unless allow_unsafe_ids is set.
In the event that your deployment is adversely affected by the above changes, simply set the below configuration flag which has been introduced with the patched versions. This flag disables these new checks in their entirety, and leaves only the targeted vulnerability fix behind. Please be aware that this flag is already deprecated, and will be removed in the next major release. As a result, it is very important to correct any integration that may be relying on this behavior. To disable the new safety checks, please add the following to your patched SPIRE Server configuration:
server {
...
allow_unsafe_ids = true
....
}
It is strongly advised that these checks be disabled if and only if your deployment is adversely affected by these behavioral changes, and setting the flag is necessary to continue with the operation of your deployment. Again, this flag will be removed in the next major release - please ensure that the situation requiring its use is corrected as soon as possible.
Should I upgrade SPIRE?
All SPIRE users running affected supported versions are advised to upgrade to the corresponding patched version. If you are running an unsupported version of SPIRE, please upgrade to a supported version of SPIRE as soon as possible.
Workarounds
Discontinue use of aws_iid agent ID templating, or ensure that EC2 tag values are not utilized in aws_iid agent ID templating.
If you have layered security controls on top of SPIRE Server API access (e.g. to implement a SPIFFE ID block list), ensure that all IDs are normalized prior to making a policy decision.
References
c53robin Analyst
Summary
In SPIRE before versions 0.8.5, 0.9.4, 0.10.2, 0.11.3 and 0.12.1, the "aws_iid" Node Attestor improperly normalizes the path provided through the agent ID templating feature, which may allow the issuance of an arbitrary SPIFFE ID within the same trust domain, if the attacker controls the value of an EC2 tag prior to attestation, and the attestor is configured for agent ID templating where the tag value is the last element in the path. This issue has been fixed in SPIRE versions 0.11.3 and 0.12.1.
What are the changes introduced by the patched versions?
The patched versions no longer apply path normalization when generating agent IDs in the
aws_iid,gcp_iit,x509popandsshpopnode attestors.The patched versions also include a patched k8s-workload-registrar, which no longer applies path normalization prior to registering SPIFFE IDs with SPIRE Server.
Further Behavioral Changes
The patched versions further introduce several safety checks to improve consistency of the normalization of SPIFFE IDs, which previously may have resulted in surprising behavior. These checks may be disabled through the use of the
allow_unsafe_idsconfigurable - please see the Upgrade Considerations section below for more information.SPIRE Server now rejects API requests containing non-normalized SPIFFE IDs, as well as API requests from callers presenting client certificates containing a non-normalized SPIFFE ID. Specifically, this means that all SPIFFE IDs must:
/).., or..segments.This includes the following APIs:
BatchCreateEntryBatchUpdateEntryMintX509SVIDMintJWTSVIDCreateJoinTokenMintX509SVIDMintJWTSVIDCreateEntryCreateEntryIfNotExistsUpdateEntryAgent ID normalization is also enforced with the patched releases. In addition to the normalization rules described above, patched releases will also reject IDs produced by node attestors that look like the SPIRE Server ID.
Upgrade considerations
While the patch that closes the vulnerability is relatively small and targeted, the patched releases also ship with a number of behavioral changes intended to promote safety and avoid surprising behavior. These additional changes can be easily disabled through the use of the
allow_unsafe_idsconfigurable (below). This section describes how to determine if your SPIRE deployment is affected by this behavioral change.There is a small chance that registration entries with non-normalized SPIFFE IDs already exist in your SPIRE deployment (e.g. registration entries with SPIFFE IDs that include percent encoded ASCII). When a patched version of SPIRE Server starts, it will scan for such entries. If any are found, they will be logged at the Error level with the following message:
Ignoring entry with invalid [spiffeID, parentID]; this entry will be automatically deleted by a future release. SPIRE Server will additionally emit a telemetry gauge indicating how many entries were ignored using theentry.ignoredkey. These ignored entries will not be honored by a patched SPIRE Server unless theallow_unsafe_idsconfigurable is set. Operators optimizing for availability may choose to upgrade a single SPIRE Server while blocking client traffic, such that the affected entries will be logged without affecting the workloads which they describe.Finally, if you are using custom node attestors, please ensure that they generate normalized SPIFFE IDs (see Further Behavioral Changes above). Node attestations that result in non-normalized IDs will fail unless
allow_unsafe_idsis set.In the event that your deployment is adversely affected by the above changes, simply set the below configuration flag which has been introduced with the patched versions. This flag disables these new checks in their entirety, and leaves only the targeted vulnerability fix behind. Please be aware that this flag is already deprecated, and will be removed in the next major release. As a result, it is very important to correct any integration that may be relying on this behavior. To disable the new safety checks, please add the following to your patched SPIRE Server configuration:
It is strongly advised that these checks be disabled if and only if your deployment is adversely affected by these behavioral changes, and setting the flag is necessary to continue with the operation of your deployment. Again, this flag will be removed in the next major release - please ensure that the situation requiring its use is corrected as soon as possible.
Should I upgrade SPIRE?
All SPIRE users running affected supported versions are advised to upgrade to the corresponding patched version. If you are running an unsupported version of SPIRE, please upgrade to a supported version of SPIRE as soon as possible.
Workarounds
Discontinue use of
aws_iidagent ID templating, or ensure that EC2 tag values are not utilized inaws_iidagent ID templating.If you have layered security controls on top of SPIRE Server API access (e.g. to implement a SPIFFE ID block list), ensure that all IDs are normalized prior to making a policy decision.
References