[release/7.0] Base64.Decode: fixed latent bug for non-ASCII inputs #76812
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
|
@adamsitnik if this is ready, please fill out the template, add the |
|
Tagging subscribers to this area: @dotnet/area-system-memory Issue DetailsBackport of #76795 to release/7.0 /cc @adamsitnik @gfoidl Customer ImpactTestingRiskIMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.
|
|
@gfoidl based on your knowledge of the main PR, do you mind helping answer these 3 items from the template?
|
|
Is this sufficient? Customer Impact.NET 6 and earlier didn't have this bug. Without that fix in .NET 7 Base64.Decode has a bug in the recognization of non-ASCII / non-Base64 characters that leads to decoding of invalid data -- especially in the case of decoding via buffer-chains where up to consumed / written it should be assumed the data is valid. With the bug, this constraint is violated, meaning that customers could operate on invalid data. TestingUnit tests got added to repro the faulty behavior, and to ensure that the fix works. RiskNone I could see. The bug got introduced in the .NET 7 timeframe and wasn't there in .NET 6 and previous versions. |
|
Thanks @gfoidl ! I'll copy it into the main description. I just changed the risk to "Low". |
carlossanlop
added
Servicing-consider
|
Approved by Tactics via email. @tannergooding all I need is a sign-off. |
|
|
ghost
locked as resolved and limited conversation to collaborators
Backport of #76795 to release/7.0
/cc @adamsitnik @gfoidl
Customer Impact
.NET 6 and earlier didn't have this bug. Without that fix in .NET 7 Base64.Decode has a bug in the recognization of non-ASCII / non-Base64 characters that leads to decoding of invalid data -- especially in the case of decoding via buffer-chains where up to consumed / written it should be assumed the data is valid. With the bug, this constraint is violated, meaning that customers could operate on invalid data.
As Base64 is used for e.g. security tokens too, that could be also a security hole.
Testing
Unit tests got added to repro the faulty behavior, and to ensure that the fix works.
Also manual debugging in a console app, to see where the bug originated.
The input values, which are added in the unit tests, are obtained by a fuzz-test run by me via sharpfuzz.
Risk
Low. The bug got introduced in the .NET 7 timeframe and wasn't there in .NET 6 and previous versions.
The additional bitwise and, that fixes the bug, is negligible perf-wise.
IMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.