Project

General

Profile

Actions

Bug #5885

closed

base64_decode not populating up to an invalid character

Added by Brandon Murphy almost 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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


Subtasks 1 (0 open1 closed)

Bug #5896: base64_decode not populating up to an invalid character (6.0.x backport)ClosedShivani BhardwajActions
Actions #1

Updated by Victor Julien almost 2 years ago

  • Priority changed from Normal to High
Actions #2

Updated by Shivani Bhardwaj almost 2 years ago

  • Status changed from New to In Progress
Actions #3

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
Actions #4

Updated by Shivani Bhardwaj almost 2 years ago

  • Target version set to 7.0.0-rc2
Actions #6

Updated by OISF Ticketbot almost 2 years ago

  • Subtask #5896 added
Actions #7

Updated by OISF Ticketbot almost 2 years ago

  • Label deleted (Needs backport to 6.0)
Actions #8

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!

Actions #10

Updated by Shivani Bhardwaj over 1 year ago

  • Status changed from In Review to Resolved
Actions #11

Updated by Shivani Bhardwaj over 1 year ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF