[security problem] core download signatures should be verified

[yurivict]

Currently files available here http://buildbot.libretro.com/nightly/linux/x86_64/latest/ are zipped shared objects. Such approach is susceptible to the MITM attack: attacker can substitute the file on the fly and RetroArch won't even notice this.

See the generic framework for MITM attackers here: https://github.com/infobyte/evilgrade It is only necessary to write a simple plugin to substitute RetroArch core download.

RetroArch should be shipped with its own public key. All cores on the site should be signed with the private key that developers have. OpenSSL can be used to sign files.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/28082727-security-problem-core-download-signatures-should-be-verified?utm_campaign=plugin&utm_content=tracker%2F296058&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F296058&utm_medium=issues&utm_source=github).

[inactive123]

SSL support will be introduced and it is something leiradel will look into.

That being said, it will be an option, it won't be enforced which I think is where you are going with this. We cannot accept or tolerate having a hard dependency against any SSL library. RA prides itself on being zero-dependency and it tries to walk a fine line between featureful and non-bloated. If we were talking about very lightweight SSL libraries then enforcing SSL might be an option, but both PolarSSL, OpenSSL and the like don't fit that description, and NIHing it would be quite the totally separate side project and I don't think people would really want to see us NIHing SSL to begin with.

RA as a project can never ever have hard dependencies against big bloated libraries like this. It will always have to be a 'soft' dependency instead. Long story short: SSL support will probably be introduced, but there will always be the option to download cores without SSL.

[andres-asm]

What if the end user wants to run his own unsigned cores? Also, OpenSSL is an enormous dependency as twinaphex just said.

I don't think something as OpenSSL can be NIHed reliably.

[yurivict]

Users can run their own cores, not problem. But cores downloaded from the central servers should be signed.

[inactive123]

Well, like I said, a hard dependency against any SSL library is not an option, it has to be optional if we are going to do it. Having a hard dependency against any bloated library would be a cardinal sin from our perspective.

Anyway, leiradel expressed interest in implementing SSL, so it will get done, but I don't think we are going to enforce SSL to be used for core / content downloading all the same. It will be optional.

[yurivict]

There are other ways to sign: you can use GPG, or you can use some independent implementation.

But signature checking has to be required. Because otherwise earlier or later download will get compromised, and this will be the end of RetroArch.

[andres-asm]

openpgp isn't exactly small either, I agree security is a concern, specially as the project grows but consider this.

Users are using the cores in most cases with software from unverified sources too, and they even download and exchange save states and other data that can be used for exploits too. Case in point, dosbox, that core (and standalone dosbox too) has full filesystem access without any hacking involved, so signature or not it can be used to wipe an entire filesystem.

The only thing we could achieve with signed cores is plausible deniability and a false sense of security.

[yurivict]

The only thing we could achieve with signed cores is plausible deniability and a false sense of security.

Signing eliminates download process as a suspect. Download via WiFi is the usual way of MITM compromise. There is the device "WiFi Pineapple" (under $100), that allows to systematically hijack and compromise WiFi networks without having any deep knowledge of networking. Same with Kali linux distro. There are communities online that discuss such hacking opportunities on daily basis. You can't just think that "nobody probably will do anything", because they will. Think of the guy sitting in Starbucks for hours with WiFi Pineapple in his bag.

[andres-asm]

I'm acknowledging the risk. It's still not fixing any security flaws. Hence the false sense of security.

[inactive123]

Let's just see what @leiradel will come up with in cooperation with me later on.

[RollingStar]

As a stopgap that's easier to make, how about a separate program that verifies the hashes? Doesn't even have to be part of the RetroArch program. Only thing RetroArch would need to provide is a list of known-good hashes (preferably SHA256 or something else modern, but MD5 is not currently known to be vulnerable to second pre-image attacks).

And to get any part of this started, can the ZIPs be hashed or signed in some way, even if there are no immediate plans to implement hash or signature checking in RetroArch?

[wastasy]

Hi, I would like to know if you have an email address account to send sensitive information in attachments. Can I use libretro@gmail.com? I look forward to hearing from you.