[BUG/SECURITY] (Possible IP Address Leak)

[CanadianJeff]

I was told if you go into mumble's config (network -> advanced -> misc) you can disable image download. This setting should be visable by default.

how to leak a users IP and user agent

1: right click send message to a channel or user 2: click on source text 2a: send an image using img src="http://somesite.tld/someimage.jpg" 2b: press ok/send without going into back preview mode 3: check log files on the web server that hosts the image

[mkrautz]

You are right that this is an easy way to get people's IP addresses.

Mumble has supported inline images in text messages using data:// URLs at least since 1.2.x. (Maybe even earlier?).

That's the way people on the servers I frequent send images: Right click the image in your browser, select copy, paste it into the 'Send Message' dialog. No need to muck with URLs - just use the actual image (not the URL!) from the clipboard.

Data URLs might not be great for big images, but neither is the Mumble log view itself. In those cases, a link is the sensible choice.

I'm for changing Mumble to not download external images by default -- since most usage of images in Mumble I see are data URLs anyway. I'm curious what the other devs think.

If we do this, here are some things to take into consideration:

• Should welcome messages still allow tags with http and https URLs? I think we need to keep this for compatibility.
  • If the welcome message's image URLs are kept intact, one can make the case that "server admins" should also be allowed to send images with http/s URLs -- since they can already see your user information in the User Information dialog in Mumble.

[hacst]

The only reason for allowing the external images I can think of is easy update of banners (e.g. you can use your comment to include one of those game stats images you see a lot in forum footers) as well as performance compared to inline images. Especially for big images the data url just isn't the right way to handle it (processing but even more so transfer wise).

[mkrautz]

Another way to implement this in privacy-friendly manner would be to have the server do the fetch.

Then IMG tags could be rewrtitten to be blob:// instead of HTTP(S) URLs - and piggyback on the blobstore that is already used for comments, user avatars, etc.

I quite like this approach.

[hacst]

I thought about that too but I'm not sure it's worth the increased attack surface. It should be easy enough to get right but being able to make the server fetch arbitrary files by design makes me ikky

[funkydude]

I vote for no longer fetching images by default personally. It's not an important enough feature.

[Kissaki]

It's not an important enough feature.

For you.

[skobkin]

is easy update of banners

Yes. We are using external images for server banner.

I think it may be option in client that can disable fetching external images. Or it can be server option that restricts HTML images in messages from non-privileged users.

[SteffanLong]

This would be best resolved as an option in the server .ini configuration file.

[Vash63]

I'd also like a server side option on this. I'm running a murmur server and one of the people on it is a streamer, pretty worried with all the DDOSing for streamers and pros that if someone else on the server sends a general chat message or something it could leak his IP.

[mkrautz]

It's worth noting that it's already achievable by disabling HTML with allowhtml=false.

I assume that is not enough?

We could pretty easily add an allowexternalimages=false option that only strips external (non-data URL images).

[Vash63]

allowhtml should work for now, I'd definitely make use of a flag to disable externally hosted images though.

On Fri, Jul 10, 2015, 05:07 Mikkel Krautz notifications@github.com wrote:

It's worth noting that it's already achievable by disabling HTML with allowhtml=false.

I assume that is not enough?

We could pretty easily add an allowexternalimages=false option that only strips external (non-data URL images).

— Reply to this email directly or view it on GitHub https://github.com/mumble-voip/mumble/issues/1388#issuecomment-120396504 .

[CanadianJeff]

closing due to old age this should have been solved by now

[CanadianJeff]

any reason for reopening this issue?

[CanadianJeff]

should this issue remain open?

[Vash63]

I personally would still like to see a feature that filtered out any img= links that went to external domains (maybe offer a whitelist in the .conf of allowed domains?). I'm not sure this is really within the 'BUG' tag as it feels more like a feature request at this point though. The 'allowhtml' setting has sufficed as far as security is concerned, this would just be helpful functionality to allow HTML while still providing similar security.

[pasimko]

Bumping this. Is this still an issue?

[davidebeatrici]

We can't enable the option by default, as there's a problem with it: it replaces the entire message with [[ No valid image ]], meaning that if someone sends a message with an external image and some text, you wouldn't see any of the two.

Also, the external image should be replaced with its URL, so that you can see it outside of Mumble or save the link.

I think it's safe to enable the option once we have fixed these two things.

[ghost]

Fixed with #3168.