Fixing vulnerability if file name length to big. #171
Conversation
Removed uriDecodeFileName, since it is now invoked in parseFileName function.
- Bump version to 1.1.6-alpha.3 - Update required busboy version to the latest one - Update test command: use absolute path to _mocha, using relative path causes errors in windows env.
Add details from which version useTempFiles available.
Add tests for cutting huge names in parseFileName.
Fix typo: forgot comma.
|
Hi @RomanBurunkov, my name is Asaf and I'm working for Snyk. This PR has popped up in our systems as a potential security issue. Before publishing an advisory about it, we'd like to properly understand the issue at hand. Could you perhaps help me understand the need for this PR? Feel free to reply here or e-mail me directly. Thank you! |
|
Hi, file name in request can be set really huge by intruder (e.g. 78000
length) that can lead to ddos. Since the max file length for most of fs is
255, I decided to cut it if length more then 255.
|
|
Hello, i'm a bit confused if this security fix is released already? You commited this on Oct 18, but Version 1.1.6 shows a release date of Sept 20 (before) but lists this as fixed. And looking at the code iof version 1.1.6 installed via npm this bugfix seems to be there too.. Important for @asafbiton too to mark this as fixed inside their vuln database... Thanks, |
|
It is fixed in 1.1.6-alpha.6 and 1.1.6 as well. |
4 participants
Cutting off huge file names by 255 characters.
BTRFS 255 bytes
exFAT 255 UTF-16 characters
ext2 255 bytes
ext3 255 bytes
ext3cow 255 bytes
ext4 255 bytes
FAT32 8.3 (255 UCS-2 code units with VFAT LFNs)
NTFS 255 characters
XFS 255 bytes