Universalmediaserver: Security Vulnerability

[chrismoberly]

Hi team USM!

I've found a critical security vulnerability affecting the current release of USM. This may allow an attacker on the same local network to compromise a machine running the software.

How would you like me to disclose that information to you - in the open here on Github, via a PGP encrypted email, etc?

Thanks!

[Nadahar]

Preferably not public so we could fix it first. Do you have access to a Tox client?

[chrismoberly]

I haven't used Tox but can certainly give it a go. How shall i find you on there?

[Nadahar]

@chrismoberly Thank you very much for alerting us.

@UniversalMediaServer/developers You can find further information on the forum.

[SubJunk]

@chrismoberly thanks a lot for this disclosure, we will look at fixing this

[chrismoberly]

Thanks! Your team was super quick to respond to this, very friendly, and great to chat with.

Keep up the great work!

• cm

[chrismoberly]

Hi guys,

How's the patch going? I'm doing public disclosure on this vuln for a couple other products (not UMS) tomorrow. Do you need some more time on this?

Thanks!

[Nadahar]

I think we have reasonable control of our own code, but we haven't been able to solve the vulnerabilities that stems from Cling yet. This library is used by quite a few UPnP Java implementations of various types, so the best thing would be if it could be solved there.

I have been trying to solve the problems found in Cling form a couple of different angles, but they have produced nothing but dead ends this far.

When it comes to disclosure @SubJunk should decide what to do, but I still think UMS has a limited exposure in that the attacker would need to get access to the local LAN so I'm not sure that a disclosure before it is completely solved would pose a big problem.

[chrismoberly]

Yep - I think that UMS is not a huge target for this attack, to be honest, as it is generally installed on home networks.

I'll wait to see what SJ says.

Thanks!

[chrismoberly]

Hi guys,
I can see this is being actively discussed in pull requests, etc, so am going to proceed with disclosure.
Thanks!

[Nadahar]

Yeah, we're not used to work in secret, so it didn't take long until something was posted in public :wink: In any case, as far as I can understand we're relying on a response to https://github.com/4thline/seamless/issues/9 to be able to close it off completely. It seems like this isn't very much maintained anymore, and I don't know if the author cares to fix it.

That said, with my latest modifications, evil-ssdp is blocked even though not every hole is plugged.

Thanks for alerting us. If you would like to help us push for some changes in Cling/Seamless, I guess you could test some of the tools listed here. I'm pretty sure they'll all fail :wink:

[Nadahar]

For reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-13416
http://seclists.org/fulldisclosure/2018/Jul/94
https://www.exploit-db.com/exploits/45133/

[SubJunk]

Also https://appuals.com/universal-media-server-7-1-0s-ssdp-upnp-functionality-found-vulnerable-to-remote-command-execution-in-windows-domains/

[valib]

This all disclosures are bullshit. There is not realy emphasized that the attacer must be connected to the private LAN which is under control of the UMS user and this is the most importand information. In the https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-13416 it is not mentioned that at all and they mention only remote attacker which is nonsens.

[chrismoberly]

Hi valib. I made sure to make that very clear in the first paragraph of the public disclosure (see http://seclists.org/fulldisclosure/2018/Jul/94).

"The XML parsing engine for Universal Media Server's SSDP/UPNP functionality is vulnerable to an XML External Entity Processing (XXE) attack. Unauthenticated attackers on the same LAN can use this vulnerability to..."

Often, in the security world, there are only two types of attacks: local, meaning on the same machine and remote, meaning not on the same machine. There should be more room for subtleties there, but that is usually how things are classified.

[chrismoberly]

Let me email Mitre and see if they can change the open description to match my public disclosure...

[valib]

@chrismoberly agree that the UMS is vurnelable for this attack but users should know that if they prevent their private LAN against the not authorized users they will minimal the vurnelability.

[chrismoberly]

@valib Yep, that's reasonable. I've just contacted Mitre asking them to update the description to match what I publicly disclosed on Seclists.

Thanks and keep up the good work!

[valib]

@chrismoberly thanks.

[SubJunk]

@valib good point and thanks @chrismoberly

[Sami32]

@chrismoberly Did you tested BubbleUPnP and Serviio media server as well?
I'm just curious as BubbleUPnP use the same Cling library than us, and Serviio used to also if i'm not sure what they are using now.

[chrismoberly]

@Sami32

Thanks for the tip. I hadn't, actually. I tested about 10 applications when I was researching UPNP. Plex, Vuze, and UMS were vulnerable so I shared those results and moved on to try some new things.

I just quickly tested Bubble. It is vulnerable. Serviio doesn't seem to be, at least not without digging deeper.

I took a look at some apps powered by MiniUPNPc, as that library is very widely used. It seems a very old version of it may be vulnerable, but nothing current that I could find. It looks to be maintained fairly well, so might be worth looking at if you guys are researching alternatives. It's used by Bitcore Core and all the crypto forks of it as well.

[Sami32]

@chrismoberly Thank you very much for having taken the time to test and answer :)

[SubJunk]

Last time I looked at Serviio they seemed to have been rewritten in Node.JS so that might be why they don't have that Cling vulnerability

[chrismoberly]

BTW, Mitre has not replied to my email asking for the change in description... Sorry guys, I will bug them again.

[Sami32]

@SubJunk Serviio has always been a Java program and still is.
They stopped to use Cling around 2014 and now use their own or modified Cling version.

[SubJunk]

Maybe they were using Node.JS for the startup file scan then, or maybe I'm just remembering another server since I often look at what our competitors are doing 🤷‍♂️

[SubJunk]

This should hopefully be fixed in https://github.com/UniversalMediaServer/UniversalMediaServer/pull/1609
Can one of you please verify it?

[SubJunk]

Also I had another look at Serviio and it seems to be an Electron app and uses Node.JS for folder crawling, what makes you think they are using Java, @Sami32 ? Maybe I'm missing something

[Sami32]

@SubJunk Are you serious?
The only 2 files related to Electron are for the console AFAICS.

aXMLRPC.jar
commons-codec.jar
commons-imaging.jar
commons-io.jar
commons-jxpath.jar
commons-lang.jar
commons-logging.jar
concurrent.jar
dcraw.exe
derby.jar
ffmpeg.exe
freemarker.jar
groovy-all.jar
gson.jar
httpclient-cache.jar
httpclient.jar
httpcore.jar
icu4j.jar
imgscalr-lib.jar
jISO8601.jar
jaudiotagger.jar
jcl-over-slf4j.jar
jcs.jar
jdom.jar
jnat-pmplib.jar
jul-to-slf4j.jar
log4j.jar
lucene-analyzers-common.jar
lucene-core.jar
org.restlet.ext.gson.jar
org.restlet.ext.simple.jar
org.restlet.ext.slf4j.jar
org.restlet.ext.xstream.jar
org.restlet.jar
padlock.jar
rome-modules.jar
rome.jar
sbbi-upnp.jar
serviio-mediabrowser-api.jar
serviio-mediabrowser-web.jar
serviio-web-console-api.jar
serviio-web-console.jar
serviio.jar
simple.jar
slf4j-api.jar
slf4j-log4j12.jar
streamflyer-core.jar
winp.jar
xstream.jar

What is the file that make you think that this program is Node.JS? I'm very curious...
http://download.serviio.org/releases/serviio-1.9.2-win-setup.exe

[Nadahar]

@SubJunk I downloaded the latest Serviio not that long ago, and the server is a JAR. I don't know what all the other stuff is, and some of that might be Electron or some other web based crap. I didn't really look at that, I only checked the server JAR to see if Cling was packed in it (and it isn't).

[SubJunk]

Hmm maybe I'm looking in the wrong place, since I'm on a Mac at the moment. I only see Electron stuff and saw a Node.JS process crawling through files. There is likely some other folder I didn't see that contains the .jar files.

[SubJunk]

Their Electron GUI is really nice and responsive, I'm jealous!

[SubJunk]

Oh yeah I found the Java - on macOS Serviio stores their Java files in the Application Support directory. They also include a copy of JRE in their bundle (like we do in our standalone builds) so I might be able to learn from how they do that to improve ours

[Nadahar]

Their Electron GUI is really nice and responsive, I'm jealous!

It's funny how different people can be. I think all these "mobile" UI's on the desktop is a complete disaster, and Electron and Node.JS applications running on the desktop is something I really despise. If people are that lazy, they should do something else than making software IMO. It's big, slow, buggy, uses huge amounts of memory for doing very little, doesn't utilize the advantages of having a mouse where you can actually hit something that is smaller than a barn and usually wastes a lot of screen space. It's simply a terrible idea IMO.

[SubJunk]

Personally I find Java hard to work with in terms of GUI so it is a relief to work with HTML/CSS when I can, but yes we each have our opinions and areas of expertise.

Anyway it's cool that this security bug got fixed and released, I wonder if you could re-test with the fixed PR @chrismoberly ? I would be happy to compile it for you to test if that would help, just let me know your operating system if so

[Nadahar]

@SubJunk Did I really miss something big now? When/where was is fixed and released? Are you referring to that done in Seamless? If so, I'm afraid you'll be disappointed, as that XML parser is only used for GENA AFAICR, and I suspect that the "fix" actually breaks GENA.

[SubJunk]

I don't have a good understanding of this issue so maybe there is more to it, I thought it was a Cling problem and saw that the fix was merged thanks to the issue by @Sami32 on their tracker https://github.com/4thline/cling/issues/243
Are there other vulnerable dependencies we rely on?

[Nadahar]

I'm not sure if there are other dependencies, this isn't very easy to neither check nor test in detail. There are certainly parts of our code that needs fixing in addition to the problems in Cling, but it's probably the Cling issue that makes us fail the evil-ssd.

As I tried to point out in the seamless (part of Cling) issue, I don't think the fix will work, and I know that it won't "fix" Cling since that's just one of the XML parsers used by Cling.

It seems to me like it was a rush to "get it out of the way" rather than to actually fix it. Although I haven't tested the "new" version of Cling, I can pretty much guarantee you that it hasn't fixed anything, and it has probably broken GENA in addition.

[Nadahar]

As I suspected, #1609 hasn't fixed anything.

I just tested 4f2b1157d9b620da02d4516d65cf3bb4a49cdde2:

Connection from [10.xx.xx.xx] port 445 [tcp/*] accepted (family 2, sport 55360)
SMBxxxxxxxxPC NETWORK PROGRAM 1.0LANMAN1.0Windows for Workgroups 3.1aLM1.2X002LANMAN2.1NT LM 0.12SMB 2.002SMB 2.???

For those that hasn't done the test before, this means that UMS (and Cling) is still very much vulnerable. Why do you close such an important issue without testing it first?

[SubJunk]

It was just an automatic close because the PR was merged, I had meant to reopen it until it was manually tested. Thanks for testing and reporting back.

[Nadahar]

@SubJunk It seems that you closed this for the same reason (#1609) once again. It still doesn't fix it.

[Nadahar]

I rest my case :laughing:

[SubJunk]

This was closed automatically in error