Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential Issue regarding file upload #3044

Open
nevercodecorrect opened this issue May 6, 2024 · 5 comments
Open

Potential Issue regarding file upload #3044

nevercodecorrect opened this issue May 6, 2024 · 5 comments
Labels

Comments

@nevercodecorrect
Copy link

Describe the bug/problem

In the code here, it uses the user provided file extension to determine the file type. However, it is possible to bypass it with a crafted a file name. This could be a potential security issue as described in CWE-646

To Reproduce

upload any file with a extension name like txt.

Expected behavior
A magic number based file type detection could be applied here.

I would be happy to make a PR for this. Please let me know your opinion.

@OzzieIsaacs
Copy link
Collaborator

Sorry I'm to stupid to understand the example: I tried "filetxt", "filetxt.", "file.pdf.txt", all of them lead to aborting the upload of the file.
Could you please give me a example filename, preferably with a quoted filename so I know where the filename is starting and ending?
The CWE talkes about files with double endings getting handled as if they had the first file ending. Where is this happening in calibre-web, I don't see it?

@nevercodecorrect
Copy link
Author

nevercodecorrect commented May 10, 2024

@OzzieIsaacs , thanks for the reply. Sorry for my unclear explanation. Here is a better example?
Assuming an malicious user wants to upload a malicious file.
In the beginning, he tries to directly upload malicious.exe (assuming a windows executable, may apply to any executable file)
image
As expected, it is blocked by the file type filtering as the file extension name is not one of the allowed ones.
image
However, for the same file, if we rename it to the malicious.txt, the file remains malicious if it is executed as the name just a symbol used to be human friendly. Then it could be uploaded to the server
image
Here is another example, executable binary python is not allowed to upload as it does not have extension. However, if we rename it to python.txt, it can be uploaded to the server.
image

The consequence of this vunlerability could be that an attacker can drop malicious files for the benefits of future attack (like this step is one piece of the whole attack chain). Or he could fool other users to download his malicious script while other users just think it is a txt file e-book.

@Jerk-Solutions
Copy link

I think the best way to resolve this would be to allow for an integration with an antimalware toolkit like ClamAV. Accept the upload, scan the files and if nothing gets flagged, add to the db.

An alternative would be to have such a toolkit running separately and scan the files on the local system.

@OzzieIsaacs
Copy link
Collaborator

I thought some time on this. If you upload an executable on Linux, the executable flag isn't set, so the file can't be executed (I currently can't check it in windows). I'm using ClamAV on my computer to scan files and there it's slow like hell (feels like over 30sec before a file scan is complete), if you have to do this on every upload, users will complain about it. So I think this would be nice to have, yes, but it's not practicable.
The file uploaded (even with executable flag set), can't create any damage on the firsthand, there is no function within calibre-web to execute it (if you view it using the viewer, it will be interpreted as pdf, txt or comic file so this means also no special harm. Something from outside of calibre-web needs to start the executable.
@nevercodecorrect: I'm curious, what was/is your solution for this topic? (You could also write me an email if this shouldn't discussed in the public)

@nevercodecorrect
Copy link
Author

@OzzieIsaacs yes, single uploading wont execute an executable file. But it could be used to future exploitable or malicious user could use the platform to distribute malware.

The solution to this topic is using the file's magic code instead of using the remote-user provided extension to decide the file type . One intro document is available here. Magic code is often the first a few bytes of the file. For different file types, the magic code would be different. For example, unix executable is 7f 45 4c 46 while a normal PNG file is 89 50 4e 47 so those file types could be distinguished. You could add a dependency library like python-magic to check the magic code. If adding a dependency is not welcomed, invoking linux's file command to check output will be another way (I think file command would be available in most linux distribs but I am not sure about windows side).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants