Hacker News Reader

Comment by seph-reed | Hacker News Reader

> 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?

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

eval $schmuh in a file format parser is... uhm, yeah. Not subtle.

> 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.

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.

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

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.

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/

It has a ton of options, but you can do all of what I suggested and more, really easily.

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.

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

That sounds like a pdf problem ^.^

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.

Some say the P in PDF stands for Problem.

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.

Reply on news.ycombinator.com