Hacker News Reader

Comment by codegeek | Hacker News Reader

"..Bowling said he discovered a way to abuse how ExifTool handles uploads for DjVu file format used for scanned documents to gain control over the entire underlying GitLab web server"

Ah, the good old "File upload vulnerability". File uploads remain one of the hardest problems to solve when it comes to security.

View on HN

> uploads for DjVu file format used for scanned documents to gain control over the entire underlying GitLab web server

A usecase for WASM's nanoprocesses (capability-based security) perhaps? Of course, until such a time someone exploits the WASM runtime itself.

RLBox is a toolkit for doing just this: https://plsyssec.github.io/rlbox_sandboxing_api/sphinx/

Used in Firefox to sandbox some libraries, including image handling IIRC.

Retrofitting seccomp or a custom Apparmor policy are both much lower hanging fruit. The problem is folk tend to link these things directly into their web servers

I really like the idea of using WASM for application "plugins". You can pick your implementation language, and with the right runtime, it can be speedy and secure. Seems like a win.

The blockers, to me, right now are:

1) I mostly write Go, and the Go runtimes didn't seem to be particularly maintained when I last looked. So it just hasn't been worth it to me to do plugins. (I have done "provide your own code to a Go application" before -- "gojq" and "expr" got the job done. Less features than a full WASM runtime, but still pretty powerful.)

2) It's unclear to me which programming language APIs should target. You add a plugin system and you want developers to use it -- what are the popular languages that target WASM? Go and Tinygo look great here, but I have a feeling that the average programmer wants something a little more dynamic for their small plugins. AssemblyScript obviously wants to be the standard, but it's probably too different from Typescript to make it a no-brainer for Javascript developers. Some sort of Perl/Python/Ruby that compiles to WASM would be great, but I haven't seen much progress on that front.

As for running untrusted code in general, I don't think WASM needs to block you. gVisor simulates the linux kernel for containers, providing stronger isolation between them, and is designed to protect you from things like this. (I think the original usecase was running ffmpeg to transcode user-provided video files?) And you can always go full VM on these things. Or take the nuclear option -- carefully audit the untrusted code and build up that trust ;)

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

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

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.

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

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.

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.

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.

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.

Is that because people use hackjob dependencies to handle it more often than not?

ExifTool is hackjob? I think not.

But also, file uploads should be handled in a jail or box of some type - and never let their analysis make network calls.

I’ve had a really hard time finding good guides for hardening VMs for malware analysis or processing untrusted inputs as you suggest - any guidance on learning resources?

I learned the hard way. But for these restricted jails I'd start by making a VM that is not allowed out at all, like DROP on iptavles OUTPUT chain.

At that point, why not just boot the virtual machine with no network interface attached?

Malware anti detection: some will not launch without a network connection. The idea is to simulate a functional network but not provide access.

Yea, the VM has a network so it looks "real" and I'm using the network interface to push the files to it (via SSH). Iptables let's related. And on the Host I'm also blocking/logging the VM network.

It's a perl program that evaluates untrusted strings it finds in user files. What exactly is your standard for "is hackjob"? It appears to be a complete piece of shit.

It's clearly not complete shit, else it wouldn't be used by literally millions of people/systems. ExifTool is so far away from shit that in fact it was chosen by a highly respected company with a very good team.

A hackjob usually has less deploys than my own stuff (which, outside of Windows 2000 components, is less than a few millions)

By this reasoning "Baywatch" was a great TV show because lots of people saw it.

Baywatch was a great TV show. Maybe you don't like it. Millions all over the world do.

I have never seen it, but am aware of the low brow reputation. If you genuinely like it, could you tell me what you like about it? I recently saw some old episodes of Knight Rider and admit that the show was fun.

Just because something is useful doesn't mean it's not a hackjob.

Just looks at how PHP got so popular. Clearly it was useful and thus became popular. I think it's hard to argue that it wasn't a hackjob when it first started.

JavaScript is a perfect instance

Quite so. It was put together in a day, and we have to endure some of its quirks decades later.

ExifTool is the tool to extract and write and fix metadata, bar none. I haven't seen anything that even comes remotely close at how good it is at handling just jpeg metadata (exif, XMP, IPTC, MarkerNotes, and all the fine bugs every vendor has when creating these), let alone other formats too.

ExifTool is essentially for (image) metadata what ffmpeg is for video.

It isn't a hack job, but it started out as one, like so very many other things. Version 1.00 was released end of 2003, while the problematic code was added in 2008. Mind you, the problematic code does not just eval whatever it sees, it tries to make sure the input isn't dangerous first. That check failed spectacularly, defeated by a newline combined with how '$' in perl regex works without any special flags[0]. Using eval was a bad choice to begin with (but I am told something you would commonly see in perl software of the time, yes, even in 2008 still), it was the lazy choice of re-using perl to unescape C-strings instead of rolling your own unescaping code.

So what do you suggest? Use libexif[1]? Exiv2[2]? Where would I run it? Can you suggest any operating system that never had a "stupid" RCE?

>It appears to be a complete piece of shit.

Let's see your code then. All the code you ever wrote that is possibly still in use somewhere. So if you never ever fucked up or got lazy, feel free to cast the first stone, otherwise I would suggest you dial down your rhetoric when it comes to taking massive steaming piles on other people's work.

Yes, Phil Harvey had a "WTF?!"-class security bug here[4], shit happens, "goto fail", let me deRail your yaml and the Debian random number of the day is: 6.

He patched it promptly compared to other vendors and projects (public release on April 13th, while April 7th was the initial bug report, to Gitlab not ExifTool, which Gitlab then passed along[3]).

You can blame him for the bug, you can blame Gitlab for not running exiftool in some sandbox. But that half the gitlab instances remain unpatched some 7 months after patches became available, that you'll have to put on the people running these instances.

[0] https://github.com/exiftool/exiftool/commit/cf0f4e7dcd024ca9...

[1] http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libexif

[2] http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=exiv2

[3] https://hackerone.com/reports/1154542

[4] I cannot be sure if he wrote it, or if somebody else contributed it, but at the very least he didn't catch it during review. Looks like he wrote it, tho.

Reply on news.ycombinator.com