Bug #5885
closedbase64_decode not populating up to an invalid character
Description
This might be a regression of https://redmine.openinfosecfoundation.org/issues/5223
I was working on a base64_decode signature, and I'm having a hard time to get it firing. I've long forgotten where this ticket landed specific to what happens to the buffer when a non base64 character is hit. I was thinking it'd still populate the base64_data buffer with what could be decoded, but that doesn't seem to be the case.
reference: https://redmine.openinfosecfoundation.org/issues/5223
example: https://app.any.run/tasks/f785af40-6c70-43db-94cf-a67f9484301d/#
pcap attached:
In current my use case the string is API=Y21Wd2IzSjBaVzFoYVd4bWNtRjFaRUJoZEc4dVoyOTJMbUYxOmpqcHh4b3Rhb2w%3D
I was hoping that I could call the base64_decode, and it would populate base64_data with everything that can be decoded up to hitting that %.
A rule that doesn't hit with 6.0.9 or 7.0.0-beta1, but does hit in 6.0.6. http.request_body; content:"API="; startswith; base64_decode:offset 0, relative; base64_data; content:"Ym9zLml";
If I add the url_decode transform it works great, but that transform is not available in all the engines.
http.request_body; url_decode; content:"API="; startswith; base64_decode:offset 0, relative; base64_data; content:"Ym9zLml";
I'm hoping to just get an understanding of what the expected behavior is, that will help determine if this is an issue, or just a difference in expectation
Files
Updated by Victor Julien almost 2 years ago
- Priority changed from Normal to High
Updated by Shivani Bhardwaj almost 2 years ago
- Status changed from New to In Progress
Updated by Shivani Bhardwaj almost 2 years ago
- Tracker changed from Support to Bug
- Status changed from In Progress to In Review
- Label Needs backport to 6.0 added
Updated by Shivani Bhardwaj almost 2 years ago
In Review PR: https://github.com/OISF/suricata/pull/8579
Updated by OISF Ticketbot almost 2 years ago
- Label deleted (
Needs backport to 6.0)
Updated by Shivani Bhardwaj almost 2 years ago
Hi zoomequipd
! I was looking into this and it indeed is a bug. We're looking into how to avoid such bugs into future. I have a PR alongwith the tests containing the same test strings and pcap that you have shared here. However, I have a question regarding the second content
keyword. From what I understand, it is intended to match with the decoded data but with the string that you have mentioned i.e. Y21Wd2IzSjBaVzFoYVd4bWNtRjFaRUJoZEc4dVoyOTJMbUYxOmpqcHh4b3Rhb2w%3D
I could not make it work as the decoded data looked much different. I was able to make it work with the data that we should get after base64 decoding it.
Here's the decoded data that works in the second content
: https://cyberchef.io/#recipe=From_Base64('A-Za-z0-9%2B/%3D',true)&input=WTIxV2QySXpTakJhVnpGb1lWZDRiV050UmpGYVJVSm9aRWM0ZFZveU9USk1iVVl4T21wcWNIaDRiM1JoYjJ3
Here's the test in suricata-verify that works with the content in the shared link above: https://github.com/OISF/suricata-verify/pull/1141/files#diff-3662aa01ea992498463f3ff72f33cdc704a561a1b5b3078d4c99bdbc60c69ccbR1
Could you please check this and let me know in what case should it match Ym9zLml
instead? Thank you very much!
Updated by Brandon Murphy almost 2 years ago
Sorry there, let me attach the original examples.
source: https://app.any.run/tasks/0ae73137-b9e4-44d7-b84b-ef9992418690/#
Updated by Shivani Bhardwaj over 1 year ago
- Status changed from In Review to Resolved
Updated by Shivani Bhardwaj over 1 year ago
- Status changed from Resolved to Closed