3

ubuntu-make (umake) can be used to install the latest version of a variety of popular developer tools.

How secure is this process and how does it compare to the security built in to apt-get, such as digital signatures via keys that are not stored on the repository servers, secure, automated updates when security vulnerabilities are identified in tools, etc.? Apt has an apt-secure man page with details on the apt approach to security. Does umake have anything like that?

Does umake, or the processes that create the packages it delivers, check any digital signatures on the underlying packages, including e.g. Maven Central signatures? How are the signature keys vetted? Does the process create any signatures that umake, in turn, automatically checks? These steps seem important, as discussed at Is Maven a plausible vector of attack? - Information Security Stack Exchange

I see that umake doesn't do updates yet (updating tools · Issue #74). Is there any way to determine whether a given installed tool is out-of-date, so you know when to do the "remove/reinstall" workaround? Is there any way to check installed umake tools for security vulnerabilities? Is the archive of packaged tools and any associated version and security metadata available for inspection directly over the web? If not, is it available via umake? What format are the packages and metadata in?

Finally, are there any plans to use The Update Framework (TUF) to really deal with software updates in a secure way?

nealmcb
  • 3,647

1 Answers1

0

I could not find a complete answer to this, either. Just one aspect:

Ubuntu make recently failed to install a package due to the wrong checksum, so there seems to be some checking. See f.ex. https://github.com/ubuntu/ubuntu-make/issues/457 and https://github.com/ubuntu/ubuntu-make/issues/346.

This does not state where the hashes are stored etc, but at least a MD5 checksum seems to be computed.

Update: seems like some packages have a GPG signature. See Error(s) while installing Android Studio using umake.

Update 2: seems like, for android, they just download the checksum from the same HTML page that also has the download link. See the repo, which says

"""Parse Android download links, expect to find a sha1sum and a url"""

serv-inc
  • 3,059
  • 1
    Thanks - that's helpful. I'll just note that MD5 produces a hash, which is quite different from a signature. An adversary can trivially generate a new hash to match a forged package, and can often replace the original hash with the new hash, in such a way that the user wouldn't notice. Properly done signatures can only be forged via much much harder attacks on the offline systems where the signature keys are secured. – nealmcb Jul 04 '17 at 15:10
  • @Neal: thanks for pointing out the difference between hashes and signatures. If the checksums are distributed with the program via ppa, can these checksums be altered? Or did you mean creating a package that also matches the known hash? How is this vulnerable? (as long as there is no known feasible preimage attack for md5) – serv-inc Jul 04 '17 at 16:07
  • 1
    If the checksums are distributed along with the package, they add little-to-no value, since the adversary can just change both of them to match. By contrast, valid signatures can only be generated by using a private key which should always be kept off line and preferably in a special hardware unit which is much much harder to attack. The end user can get the corresponding public key once (e.g. when installing Ubuntu originally) and use that to check signatures in ways that would detect any attacker who simply managed to pwn the server, which is often surprisingly easy. – nealmcb Jul 04 '17 at 23:05
  • @nealmcb: sure about distributing with the package, but how about distributing them with umake itself? – serv-inc Jul 05 '17 at 19:54
  • How would that work? If I use umake to build mytool, I'm not going to then compute the md5 of mytool and make it part of the umake distribution, and then keep updating umake every time I update mytool. – nealmcb Jul 06 '17 at 04:03
  • @nealmcb: it seems as though they mostly just download the original software, and compare it to some local checksum. That's the probable cause of the bugs: the software to download was updated, but the umake-internal checksum was not. – serv-inc Jul 06 '17 at 07:53
  • The umake checksum issues you're pointing to seem to reflect either download corruption errors (which is what they're designed to catch) or bugs in how umake is generating or comparing the checksums. Umake doesn't have the checksums of the android images it's downloading somehow built in to it. But this is all quite a different issue than the need for proper signatures which would catch intentional attempt to insert malware in the packages. – nealmcb Jul 06 '17 at 21:15
  • "Umake doesn't have the checksums of the android images it's downloading somehow built in to it". So what is that: https://github.com/ubuntu/ubuntu-make/commit/055ea817e2b74aa192529b147144bfbea9a5a66f ? – serv-inc Jul 07 '17 at 14:06
  • @nealmcb: it seems like they removed the built-in checksum in recent-versions of umake, and just download the SHA1 checksum. See the update – serv-inc Aug 18 '17 at 05:11
  • 1
    Well that would seem to make it particularly easy to convince someone, falsely, that everything checked out. All an attacker has to do is compromise the download page, and hack both the download and the checksum. As my original question points out, checksums don't help here. We need signatures from offline keys. – nealmcb Aug 28 '17 at 15:44