6 ms·

The most important information is missing - did the attackers get the package signing key? The comment "the window for package compromise was very very small" i

by kfreds 12y ago

The most important information is missing - did the attackers get the package signing key? The comment "the window for package compromise was very very small" is a bit ambiguous. That the security of package integrity is so fragile should greatly concern all of us. Almost all big Linux distributions rely on downloading compiled packages signed by a single key. If the build system is compromised your Linux distribution of choice will happily give you trojaned packages that you install as root. If the signing key is compromised a man-in-the-middle is required, but the difficulty to mount an attack is decreased due to the fact that most repositories don't transport over TLS. The situation can be improved in many ways. By making the build process deterministic many parties can compile the same package and compare the result, alerting the community if one of the build systems report a different checksum. Package managers like apt and yum should be extended with the ability to rely on signatures from multiple parties. The Tor Project, Debian and Fedora has started working on the first problem, but I don't know of any efforts to support multi-sig. https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise https://blog.torproject.org/blog/deterministic-builds-part-o... https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details https://blog.torproject.org/blog/deterministic-builds-part-t... https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds https://securityblog.redhat.com/2013/09/18/reproducible-builds-for-fedora/ https://securityblog.redhat.com/2013/09/18/reproducible-buil...

vezzy-fnord 12y ago
Nix already solved the first problem a while ago, though its adoption is hindered by the fact that it would essentially deprecate the entire infrastructure that actually makes a distribution a distribution, and is therefore unaligned with best interests. This is in spite of widespread claims of wanting standardization.
- drostie 12y ago
  Nix is just simply amazing, and there IS a distribution (NixOS[1]) which ships it. The big problem is of course keeping packages current. Nix and SmartOS[2] are both really important in my book. Nobody's talking about them as distributions but they both have intense potential to completely change not just server-administration (which is what they solve right now) but having a nice desktop experience. It would look like the Windows desktop experience, where they try to hide C: from you and just give you a set of shared-across-your-applications folders: Documents, Desktop Icons, Pictures. When every application occupies its own universe, then the OS itself behaves just the way that the "window" metaphor suggests; moreover you can start to seamlessly include VMs and get Windows applications living next to OSX ones. The only cost is hard-drive space, but hard drive space can be shared if we can package the software and share packages with the same checksums. Eventually, I hope that people will just assume that an application "comes with" its operating environment. 1. http://nixos.org/ http://nixos.org/ 2. https://smartos.org/ https://smartos.org/
  - vezzy-fnord 12y ago
    My point was concerning the mainstream distributions adopting it. I'm well aware of NixOS.
- qznc 12y ago
  I never heard Nix addressing the reproducible-problem as Debian does here: https://wiki.debian.org/ReproducibleBuilds/Howto https://wiki.debian.org/ReproducibleBuilds/Howto E.g. various build tools (e.g. gcc) include timestamps in their output
e12e 12y ago
Hopefully/presumably the gpg-signing key wasn't on the box (no reason for it to be) -- so the only way to compromise the debs would/should be by uploading/using a new gpg-key -- which apt would warn the user about. Now, if anyone followed only part of the instructions: http://webcache.googleusercontent.com/search?q=cache:deb.haskell.org&ie=utf-8&oe=utf-8&gws_rd=cr&ei=fzXiVKr5NuvXyQPe9oKoCA They would be owned: Repository keys To avoid warnings, you might want to install the key used to sign these repositories: GET http://deb.haskell.org/deb.haskell.org.gpg-key | \ apt-key add - Unless they paid attention to: The key is signed using a key from the Debian keyring, in case you want to verify it first. This is of course backwards: it should list instructions for verifying the key before instructions on how to add it to apt...
- e12e 12y ago
  Getting the gpg-key via http and not verifying it is batshit crazy anyway. I'm perfectly fine with anchoring trust in Debian's keyring -- after all, you implicitly trust that key with root access to all servers running apt. Sadly, Debian's support for trusted (by the user, and which Debian can vouch for the key, if not the software) third party repositories is still somewhat sketchy -- it'd be nice if there was a "apt-get-me-a-key-for-this-url-only-if-signed-by-the-debian-keyring <apt-url>"-command. That would of course imply that Debian becomes a bit of a CA for apt-repositories -- which it already is in the case of deb.haskell.org. See also: https://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s7.5.3.8 https://www.debian.org/doc/manuals/securing-debian-howto/ch7... [ed: changing link to use https!]

by kfreds 12y ago

vezzy-fnord 12y ago

Nix already solved the first problem a while ago, though its adoption is hindered by the fact that it would essentially deprecate the entire infrastructure that actually makes a distribution a distribution, and is therefore unaligned with best interests. This is in spite of widespread claims of wanting standardization.

drostie 12y ago
Nix is just simply amazing, and there IS a distribution (NixOS[1]) which ships it. The big problem is of course keeping packages current. Nix and SmartOS[2] are both really important in my book. Nobody's talking about them as distributions but they both have intense potential to completely change not just server-administration (which is what they solve right now) but having a nice desktop experience. It would look like the Windows desktop experience, where they try to hide C: from you and just give you a set of shared-across-your-applications folders: Documents, Desktop Icons, Pictures. When every application occupies its own universe, then the OS itself behaves just the way that the "window" metaphor suggests; moreover you can start to seamlessly include VMs and get Windows applications living next to OSX ones. The only cost is hard-drive space, but hard drive space can be shared if we can package the software and share packages with the same checksums. Eventually, I hope that people will just assume that an application "comes with" its operating environment. 1. http://nixos.org/ http://nixos.org/ 2. https://smartos.org/ https://smartos.org/
- vezzy-fnord 12y ago
  My point was concerning the mainstream distributions adopting it. I'm well aware of NixOS.
qznc 12y ago
I never heard Nix addressing the reproducible-problem as Debian does here: https://wiki.debian.org/ReproducibleBuilds/Howto https://wiki.debian.org/ReproducibleBuilds/Howto E.g. various build tools (e.g. gcc) include timestamps in their output

e12e 12y ago

Hopefully/presumably the gpg-signing key wasn't on the box (no reason for it to be) -- so the only way to compromise the debs would/should be by uploading/using a new gpg-key -- which apt would warn the user about. Now, if anyone followed only part of the instructions: http://webcache.googleusercontent.com/search?q=cache:deb.haskell.org&ie=utf-8&oe=utf-8&gws_rd=cr&ei=fzXiVKr5NuvXyQPe9oKoCA They would be owned: Repository keys To avoid warnings, you might want to install the key used to sign these repositories: GET http://deb.haskell.org/deb.haskell.org.gpg-key | \ apt-key add - Unless they paid attention to: The key is signed using a key from the Debian keyring, in case you want to verify it first. This is of course backwards: it should list instructions for verifying the key before instructions on how to add it to apt...

e12e 12y ago
Getting the gpg-key via http and not verifying it is batshit crazy anyway. I'm perfectly fine with anchoring trust in Debian's keyring -- after all, you implicitly trust that key with root access to all servers running apt. Sadly, Debian's support for trusted (by the user, and which Debian can vouch for the key, if not the software) third party repositories is still somewhat sketchy -- it'd be nice if there was a "apt-get-me-a-key-for-this-url-only-if-signed-by-the-debian-keyring <apt-url>"-command. That would of course imply that Debian becomes a bit of a CA for apt-repositories -- which it already is in the case of deb.haskell.org. See also: https://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s7.5.3.8 https://www.debian.org/doc/manuals/securing-debian-howto/ch7... [ed: changing link to use https!]