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

fix: File name injections via Content-ID header #487

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

sharat87
Copy link
Contributor

@sharat87 sharat87 commented Apr 13, 2024

Fixes #467
Fixes CVE-2024-27448

This is how we're fixing this:

  1. Replace any /, back-slash and : characters in the Content-ID header with -.
  2. Prepend this with the MD5 of the original Content-ID header, so attachments with names ../file.txt and ..-file.txt don't overwrite each other.

If this is an approach you guys would be interested in taking forward, I'll look into adding tests to ensure we don't regress on this. Let me know. Thanks for all your work on this project.

The tests are failing because the cid:... in HTML messages aren't getting replaced with the URLs to the image attachments themselves. I'm not sure where this replacement is happening, if I can find it, I think I can fix it.

@sharat87 sharat87 changed the title fix: File name injections via Content-ID header fix: File name injections via Content-ID header Apr 13, 2024
@sharat87 sharat87 marked this pull request as draft April 13, 2024 09:56
@sharat87 sharat87 marked this pull request as ready for review April 13, 2024 09:56
this._currentNode.meta.contentId = originalContentId
? (crypto.createHash('md5').update(originalContentId).digest('hex') +
'-' +
originalContentId.replace(/[:/\\]+/g, '-'))
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think originalContentId.replace(/(\.\.|:|\/|\\)+/g, '-') should be better

Copy link

@stypr stypr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this needs to be fixed directly from the vulnerable code I mentioned in the original issue.

There is a very high chance that the bug will occur again once the maintainer updates the vendor folder to latest.

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

Successfully merging this pull request may close these issues.

[Vulnerability] Arbitrary File Write leading to Remote Code Execution (RCE)
2 participants