|
|
Posted on 7/31/2023 6:36:01 PM
|
|
|
|
One sunny morning, I was sitting in front of my laptop restructuring some C# code. Everything is going well and it will be a productive day. Then I added too many equal signs to the constant string literal, and things exploded. Productivity is gone. Sunday's calm reconstruction is behind us. Even the sun decided to hide behind the clouds.
After spending 30 to 40 minutes trying to figure out what I was doing wrong, I realized it wasn't me. It's Microsoft. Apparently, I stumbled upon an old bug in the Base64 decoding function.Convert.FromBase64StringThis bug has definitely been around since .NET 1.1 was introduced in 2003. Wow! That's old. And it's not very difficult to reproduce. Good job:
Technically, this is illegal Base64. The legal version is "abc=". Note only one filler character =. Base64 encoding represents every 6 bits of binary input in one ASCII character. This means that every 4 characters in a Base64 encoded string represents 3 bytes. When the encoded data is not a multiple of 3 bytes, the Base64 encoder adds a filler character to make Base64 a multiple of 4 characters. This will generate a Base64 string that is properly populated with "abc=". Adding another = will invalidate it.
Base64 "abc=" is decoded as two bytes [105, 183]. That's right. Adding another padding character at the end should not really change the encoded value. It's like adding a space to the end of a sentence. Yes, it's there, but it doesn't change the meaning of the sentence. But .NET doesn't think so. "abc==" is decoded as a byte [109]. Not only did it get shorter, which was weird because we made the input longer. It has also become different. The first byte goes from 105 to 109. And it didn't throw an exception either. Add another = and you get an exception. Amazing!
Code:
Output:
'abc=' -> [105, 183]
'abc==' -> [109]
At first I couldn't believe it and started investigating. I googled for a while and didn't find much. Then I posted on StackOverflow and didn't get much luck either. Once I figured out what was going on, I even had to answer my own questions. After searching on GitHub for a while, I stumbled upon a fix made in .NET Core in July 2018. So the latest .NET Core version handles this issue correctly and throws an exception:
Unhandled Exception: System.FormatException: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.
at System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
at System.Convert.FromBase64String(String s)
at Program.DecodeAndPrint(String base64) in ./base64/Program.cs:line 13
at Program.Main() in ./base64/Program.cs:line 8
Convert.FromBase64() has a subtle bug where the second illegally padded character at the end of the string causes the decoding to "succeed" by removing the penultimate character.
We are at . This bug was inadvertently fixed when the API was optimized in NetCore 2.1. Add tests to log errors and make sure we don't go backwards.
The workaround in .NET 4.7.2 is to refill the incorrectly populated string with something like this:
Original:The hyperlink login is visible.
|
Previous:Azure DevOps (viii) Compiles ASP.NET MVC projects using Pipelines BuildNext:A new timer in .NET 6, PeriodicTimer, is used
|
Landlord|
Posted on 7/31/2023 6:39:50 PM
|
