Security concern of EpicGamesLauncher.exe?

Community Community & Industry Discussion
1

Hey Epic & community,

It’s been a while since I updated my UnrealEngine, but I did so today and noticed something that troubles me. I’m semi-serious about security, so I control my firewall fairly carefully. It’s amazing how Windows apps that ‘party with’ (share) with your information are proliferating.

So I updated to the latest UE bits, and now whenever I try to load the editor my firewall blocks an outbound IP connection request from the “Local Security Authority Process” application (system service) to IP 72.167.18.239 (p3plpkivs-v03.any.prod.phx3.secureserver.net) and the engine load stops at an “Error! No version information received” error.

What are you guys doing in the launcher that would trigger an IPC call over to LSASS and have it call out to such a strange IP address? I’m willing to grant apps like the UnrealEngine fairly open IP access, since I can then monitor the process’s file access activity if I want, but I’m not really too excited about opening a ring-0 process like LSASS to chitchat with GoDaddy.

Can someone please explain what’s going on?

(I’m also pretty disappointed that I can’t run anything UE-related in a VM like I do virtually everything else due to the engine’s DX11 requirement, but I guess that’s understandable.)

Thanks in advance…

2

Someone from the Online Team can probably answer this with certainty, but it is most probably a connection to the content delivery network. We partner with other companies, such as Amazon to make downloads, blog posts and news feeds available all over the world. There are many servers in every country, and the Launcher will automatically connect to the one closest/fastest to your location.

3

yeh I noticed this aswel… I don’t mind allowing connections via firewall for specific programs I might use via there own .exe like the EpicGamesLauncher.exe but when its wanting to connect through something else on the system lsass.exe just to work (ie download) that ain’t cool.

4

Thanks for responding so quickly. This is pretty much what I expected and is reasonable in itself, but I’m more concerned why the request is coming from the LSA. My first guess would be a digital certificate check, but that usually comes from the originating process. LSASS is more associated with ‘windows networking’ features like Active Directory. Thus the question.

A response from the Online Team or anyone in the know would be welcome here. I’m skimming source to see if I can answer my own question, but progress is slow.

5

I opened the port & sniffed the wire traffic from LSASS appears to be a OCSP certificate check. This is OK as far as it goes, I’ve just never seen OCSP traffic originate from the LSA process before.

My guess is that origination from the LSA is unintentional. Is there any way Epic could change this to do all their PKI stuff (all traffic, really) to come from Epic’s executables?

Among other reasons, several known worms are known to hijack the LSA on compromised systems and tunnel their traffic from there to bypass antivirus. This is why I have it blocked - no other applications to my (limited) knowledge behave like this.

I’d suggest going to the tried & true CRL method - it’s less vulnerable and more or less the best practice IMHO.

6

I guess this isn’t a major concern to Epic. Since we don’t have access to the launcher source code I wasn’t able to trace this very far.

In the interest of ‘openness’ I would suggest that Epic consider publishing launcher source, just keep the PKI certificates private - attach them as a resource as a post-build step.

8

still not fixed

still having to make temp firewall exemption for effing lsass.exe everytime just to start this useless launcher.

common epic

9

I don’t think I’d put in those exact words but yeah, I’m kind of disappointed by the Microsoft-ish ‘close-bug/as-designed, no-explanation’ way they handled this as well. It’s not up to Epic’s awesome (imho) standards.

but understand the issues of hooking completely open source to the epic $tore are problematic at best. I might suggest to Epic publishing the source but withholding the epic certificates, but on the other hand I could pretty easily extract their cert from their exe, transplant it into the open source and cause headaches, which I wouldn’t do but others probably would. This whole LSASS round trip is (likely) validating the signature of the launcher exe with Epic. Personally I think it probably wasn’t a good idea of adding money transaction capability to anything even remotely connected to the engine. I would have advised leaving that to a browser solution, perhaps via an embedded browser.

perhaps they’ll fix it when they port the launcher to linux (and other platforms I assume), although that opens up even more cans of worms and is another reason they should have implemented the store in a browser ant moved on to more important stuff.

Since the engine won’t run in a type-2 VM and the launcher is closed-source means I have to trust it and keep my fingers crossed. I opted to ‘trust but verify’ the thing; since it’s network traffic is mostly encrypted all I can do is monitor the app’s file access and traffic volumes and hope it’s doing the right thing. Which is becoming less and less common these days, at least with other apps. So far I haven’t seen the launcher (or anything in the engine) do anything bad as far as I can tell…

11

I do not speak for Epic, but I also do not see them publishing the source to the Launcher. I’d be the first one to cheer for the source as we (Linux Community) have been starved for a year now without the Launcher. :slight_smile:

The Launcher contains things like Marketplace purchases, secure transactions etc, so it would be unwise to open that up unless a way is found to exclude those or protect them in some other way.

12

Hey all,

For what’s it’s worth, I was contacted by an Unreal developer today who offered a solution: add a " -http=wininet’ (without the quotes) command line parameter to the launcher. This apparently causes the engine to use the native Windows WinINet’ APIs instead of the CURL open-source library it uses by default. The effect of this is that the launcher network traffic is all in-process so no unusual firewall exceptions are necessary.

Whether this solution becomes the default in future releases is up to Epic (obviously) but for those of us tin-foil-hat types this is a great workaround.

Thanks to Epic for being, well, so awesome…

13

You don’t need to use the launcher. You can launch a project by browsing to the projects directory, and opening the .uproject file.

14

Yep, this is more about launching the launcher (aka store) than the editor.

15

Sorry, was trying to respond to password1lol, and my quote disappeared - he was voicing frustration specifically about the “necessity” of the launcher.

16

Hi All,

As Dave mentioned our long term plan is to fully transition to using libcurl for all of our http(s) needs on Windows, Linux and OSX. Presently we use libcurl by default for Windows and Linux but have not deprecated the wininet code so you are free to use the “-http=wininet” parameter for now. Myself or one of my colleagues will investing how we are misusing libcurl and hopefully this will be all but a memory in a future release.

17

Even if you don’t use the launcher the editor still has to save in the library right? Then the project is still left open to be seen.

19

Even if you don’t use the launcher to open a project it will still save to the library? Then leaving expose for other to view projects?

20

This is still an issue though “-http=wininet” works to avoid the lsass firewall request every dammmn time… Which has been good to use for this issue… up until now, I’ve starting playing UT more regularly again… and launching UT directly using the unrealtournament startup arg from steam… thus bypassing the epic launcher (with “-http=wininet”) now means I have the whole lsass.exe ruubbish to temp allow again every dammn time. Because UT doesn’t directly support the “-http=wininet” startup arg.

fyi I use netlimiter… would be nice if you sorted out your stuff epic!

21

As Alex mentioned above, this issue is due to the engine moving to libcurl for http and https. Epic apparently sees this as absolving them from responsibility and reduces their interest in solving the problem. (Sorry if that sounds a bit harsh, I am poking Epic with a sharp stick in the hopes of getting some action)

I havent taken the time to look into it too deeply (my bad) but I still don’t quite see why the multi-platform libcurl would want or need to incur this out-of-process LSASS traffic. I would have thought libcurl would bind to a generic network sockets interface for the sake of portability, but apparently that’s not the case, at least not on Windows.

But yeah, this continues to be both an issue and a concern to me and others. Search on ‘libcurl lsass’ and you’ll see threat advisories, etc out there. Among other issues, LSASS is a common vector that viruses use.

@Alex or @gmpreussner: Is there any way to flag libcurl.dll to stay entirely inproc? It would seem to me libcurl would have to support http/s in a way other than by using this NTLM crud to support platforms other than Windows.

FWIW I’ve addressed my own concerns by cobbling together another layer of security I call ‘tripwire’ that alerts on unauthorized file access patterns, and from what I can tell UE isn’t currently reaching into the cookie jar. But that doesn’t mean it or something it depends on wont in the future. And having to monitor the system process just adds confusion to my tripwire alerts.

Thinking about the implications of UE depending on an open source networking stack that establishes encrypted and out of process data streams makes me pretty uncomfortable… Not only does it open UE to OpenSSL HeartBleed type vulnerabilities, but any semi-skilled hacker would see this is very low hanging fruit ripe for exploitation through source code commits, etc.

I can rationalize the need for encrypted comms in a (mostly) open-source project like UE, and I’m not advocating Epic implement it’s own SSL layer (although my guess is that Max Pressuner could do it in a month as a 10% project), but is there any way to split the difference and not force people to have to choose between “using a depreciated API that might go away” and just “bending over and closing their eyes” (which describes 99.9% of users), letting who knows what imported code party with their data?

Sorry if this sounds paranoid. It’s actually more cynical but based on real life experience over the years. This could be a train wreck waiting to happen.

22

@12many: An SSL layer (and encryption in general) is a can of worms that I would rather leave for others to open :slight_smile:

I don’t know libcurl enough to comment on what is happening, but the behavior seems unexpected to me as well. It is likely some configuration or initialization we’re doing wrong. Team Online will look into it.

25

Thanks Max, you guys are totally awesome.

For what it’s worth, I took a quick skim of the libcurl stuff and it appears to be more of a OS-agnostic wrapper around native OS implementations rather than an OS-agnostic implementation itself. This is smart in several ways, since it relieves the libcurl devs from having to support a full SSL stack with all that implies. But if this is the case it also means that fixing this problem is going to be problematic at best.

And yeah, doing something like SSL ‘right’ is /hard/ and I’m not advocating you do anything like that. I’m not sure there’s a good solution - it’s not obvious to me.

Keep us posted. Wish there was a way we could help…