Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert.FromBase64XYZ(...) decoder should reject input when unused bits are not set to 0 #105264

Open
buyaa-n opened this issue Jul 22, 2024 · 1 comment

Comments

@buyaa-n
Copy link
Member

buyaa-n commented Jul 22, 2024

When the input is not multiple of 3 some bits of the encoded values are not used, Convert.ToBase64XYZ(...) encoder overloads sets those bits to 0, but Convert.FromBase64XYZ(...) decoder overloads currently doesn't check those bits and allows any combination of values. Therefore multiple input could decoded to same value, for example when the input is 1 byte character 'A', encoder encodes it to 2 base64 characters and 2 padding "QQ==" , the last 4 bits of the 2nd Q is not used and set to 0s, but decoder doesn't validate that and allows 2^4 = 16 values decoded into same value, for example: "QQ==", "QR==", "QS==", "QT==", "QV==", "QU==", "QW==", "QX==", "QY==", "QZ==", "Qa==", "Qb==", "Qc==", "Qd==", "Qe==", "Qf" will be decoded to a same value, 65, ascii of 'A'.

The spec mentions that unused bits MUST be set to zero by conforming encoders. It also mentions that decoders may reject an input if pad bits have not been set to zero. Don't see any reason to keep allowing non-zero value for those other combinations that produce same result when encoders are expected to produce only one value.

This doesn't seem to be a breaking change, when encoders expected to set unused bits to 0. Though it could break tests that randomly generates Base64 encoded text for decoding.

Related to #105262

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jul 22, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Jul 22, 2024
@buyaa-n buyaa-n added area-System.Runtime and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Jul 22, 2024
@buyaa-n buyaa-n added this to the 10.0.0 milestone Jul 22, 2024
@buyaa-n buyaa-n removed the untriaged New issue has not been triaged by the area owner label Jul 22, 2024
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant