4 ms·

> File uploads remain one of the hardest problems to solve when it comes to security. Why? It seems like they should have read/write but no execute. What goe

> File uploads remain one of the hardest problems to solve when it comes to security. Why? It seems like they should have read/write but no execute. What goes wrong?

meragrin_ 5y ago
That doesn't help when the uploaded file is only read/write but crafted in a way to exploit the code processing the file.
jacquesm 5y ago
You essentially have a gateway into a very large chunk of code that was most likely not built with security in mind on the parsing side, on top of that you are guaranteed write access to some file system.
- danudey 5y ago
  Ideally you would sandbox this with: 1. No filesystem access 2. No network access 3. Input passed on stdin (or a pre-opened fd) 4. Output passed to stdout (or a pre-opened fd) 5. A hard timeout specified before the process is killed Suddenly bam, dramatically safer. If you're looking for a tool that can do all of this for you, check out firejail: https://firejail.wordpress.com/ https://firejail.wordpress.com/ It has a ton of options, but you can do all of what I suggested and more, really easily.
  - cookiengineer 5y ago
    Note that firejail had a serious RCE in the way it parses URLs for at least emails. Personally, having read the codebase, I wouldn't put too much faith in its security, given how long it took that the meta character parsing problems were discovered. A user input facing software should always use fuzzing to uncover such bugs.
staunch 5y ago
> What goes wrong? Usually what goes wrong is parsing or processing the files. It's hard to get programmers to safely validate a 20 byte email address string. It takes a lot more care to safely parse a 4,000,000 byte image file in a complex format.
mdavidn 5y ago
File formats like PDF contain a script that must be interpreted in order to read the image.
- sushsjsuauahab 5y ago
  That sounds like a pdf problem ^.^
  - spijdar 5y ago
    PDF is an example, but far from the only one. Many file types have executable/scripted portions or simply very complex file formats that have huge attack surfaces. JPEG XL predictors are Turing complete, given an unlimited image size... Off the top of my head, a lot of old console exploits on the Wii and GameCube revolved feeding malicious save files to games. Same idea, missing bounds checks or whatever when deserializing some field lets you shell the process. Parsing random files from users is just dangerous.
  - Hamuko 5y ago
    Some say the P in PDF stands for Problem.
ASalazarMX 5y ago
The file is not executable, but the parser executes it in its own context: > When uploading image files, GitLab Workhorse passes any files with the extensions jpg|jpeg|tiff through to ExifTool to remove any non-whitelisted tags. > An issue with this is that ExifTool will ignore the file extension and try to determine what the file is based on the content, allowing for any of the supported parsers to be hit instead of just JPEG and TIFF by just renaming the uploaded file. > One of the supported formats is DjVu. When parsing the DjVu annotation, the tokens are evaled to "convert C escape sequences". https://gitlab.com/gitlab-org/gitlab/-/issues/327121 https://gitlab.com/gitlab-org/gitlab/-/issues/327121
- formerly_proven 5y ago
  eval $schmuh in a file format parser is... uhm, yeah. Not subtle.
SahAssar 5y ago
That might be true if you treat all files as opaque blobs, but services like these do things like resizing images, extracting metadata, and converting to other formats.
fragmede 5y ago
Well, it's a media file parser vulnerability for one, so the filesystem execute bit doesn't protect against it, and the memory nx bit just means you have to get to a page where it is set.

> File uploads remain one of the hardest problems to solve when it comes to security. Why? It seems like they should have read/write but no execute. What goes wrong?

meragrin_ 5y ago

That doesn't help when the uploaded file is only read/write but crafted in a way to exploit the code processing the file.

jacquesm 5y ago

You essentially have a gateway into a very large chunk of code that was most likely not built with security in mind on the parsing side, on top of that you are guaranteed write access to some file system.

danudey 5y ago
Ideally you would sandbox this with: 1. No filesystem access 2. No network access 3. Input passed on stdin (or a pre-opened fd) 4. Output passed to stdout (or a pre-opened fd) 5. A hard timeout specified before the process is killed Suddenly bam, dramatically safer. If you're looking for a tool that can do all of this for you, check out firejail: https://firejail.wordpress.com/ https://firejail.wordpress.com/ It has a ton of options, but you can do all of what I suggested and more, really easily.
- cookiengineer 5y ago
  Note that firejail had a serious RCE in the way it parses URLs for at least emails. Personally, having read the codebase, I wouldn't put too much faith in its security, given how long it took that the meta character parsing problems were discovered. A user input facing software should always use fuzzing to uncover such bugs.

staunch 5y ago

> What goes wrong? Usually what goes wrong is parsing or processing the files. It's hard to get programmers to safely validate a 20 byte email address string. It takes a lot more care to safely parse a 4,000,000 byte image file in a complex format.

mdavidn 5y ago

File formats like PDF contain a script that must be interpreted in order to read the image.

sushsjsuauahab 5y ago
That sounds like a pdf problem ^.^
- spijdar 5y ago
  PDF is an example, but far from the only one. Many file types have executable/scripted portions or simply very complex file formats that have huge attack surfaces. JPEG XL predictors are Turing complete, given an unlimited image size... Off the top of my head, a lot of old console exploits on the Wii and GameCube revolved feeding malicious save files to games. Same idea, missing bounds checks or whatever when deserializing some field lets you shell the process. Parsing random files from users is just dangerous.
- Hamuko 5y ago
  Some say the P in PDF stands for Problem.

ASalazarMX 5y ago

The file is not executable, but the parser executes it in its own context: > When uploading image files, GitLab Workhorse passes any files with the extensions jpg|jpeg|tiff through to ExifTool to remove any non-whitelisted tags. > An issue with this is that ExifTool will ignore the file extension and try to determine what the file is based on the content, allowing for any of the supported parsers to be hit instead of just JPEG and TIFF by just renaming the uploaded file. > One of the supported formats is DjVu. When parsing the DjVu annotation, the tokens are evaled to "convert C escape sequences". https://gitlab.com/gitlab-org/gitlab/-/issues/327121 https://gitlab.com/gitlab-org/gitlab/-/issues/327121

formerly_proven 5y ago
eval $schmuh in a file format parser is... uhm, yeah. Not subtle.

SahAssar 5y ago

That might be true if you treat all files as opaque blobs, but services like these do things like resizing images, extracting metadata, and converting to other formats.

fragmede 5y ago

Well, it's a media file parser vulnerability for one, so the filesystem execute bit doesn't protect against it, and the memory nx bit just means you have to get to a page where it is set.