google / turbinia

Automation and Scaling of Digital Forensics Tools

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Bug]: Faulty creation of file_path when using api evidence upload

HolzmanoLagrene opened this issue · comments

What steps will reproduce the bug?

  1. Normal everyday use
  2. When using the api_servers evidence upload

What is the expected behavior?

When uploading a file with name somefile.ext, I expect the filename after the upload to be including the same ext. When looking at the additional steps done in the code (version handling using timestamp), I expect the new file name to be somefile_2024-03-20T15:54:15.890239Z.ext.

What do you see instead?

Looking at the code the parameter file_name in async def get_file_path(file_name: str, ticket_id: str) is overwritten by the first line of code of that function:

Here is the full code of what happens below:

file_name = os.path.splitext(file_name)[0]
file_extension = os.path.splitext(file_name)[1]
file_extension = '.' + file_extension if file_extension else ''
current_time = datetime.now().strftime(turbinia_config.DATETIME_FORMAT)
new_name = f'{file_name}_{current_time}{file_extension}'

Using this function with e.g file_name="somefile.ext", the first line

file_name = os.path.splitext(file_name)[0]

returns somefile and overwrites the file_name parameter value right away. When we then apply the next line

    file_extension = os.path.splitext(file_name)[1]

file_name is not "somefile.ext" anymore, but "somefile" and the second line will always return an empty value for file_extension-variable. This results in a loss of the original file extension in any case.

A simple fix could be done like this:

file_name_without_ext, file_extension = os.path.splitext(file_name)
current_time = datetime.now().strftime(turbinia_config.DATETIME_FORMAT)
new_name = f'{file_name_without_ext}_{current_time}{file_extension}'

Additional information

I think this goes unnoticed with most evidence types, but using CompressedDirectory with its less elegant type check, this error will result in a failure of the preprocessor.

Thanks for reporting the issue @HolzmanoLagrene. Did you want to submit a pull request with your suggested fix?

I'm including this in #1460

Cool thanks!