5 ms·

The Update Framework

140 points by ashitlerferad 10y ago

doublerebel 10y ago
So obviously we have to wonder why TUF hasn't been applied to NodeJS's npm. All I can find is a suggestion that maybe someone from TUF posted to a node mailing list in 2014 [1]. Any more recent info? [1]: https://groups.google.com/forum/m/?fromgroups#!topic/theupdateframework/GbWtUbnO8_I https://groups.google.com/forum/m/?fromgroups#!topic/theupda...
- zamalek 10y ago
  I assume that you'd first need a native JS TUF package published to NPM. I don't think that adding another language dependency is a decision that would be taken lightly. Additionally, I don't see any Windows instructions (NB: python-ffi) and Node supports Windows as a first-class citizen.
- raesene10 10y ago
  AFAIK several language package managers have looked at implementing TUF for their repositories, but the only live implementation that I know of is Docker Content Trust. I kind of think it's an important part of secure management of libraries. As the Fosshub breach last week showed, software repo's are tempting targets for attackers...
  - bennofs 10y ago
    Hackage/Cabal also has at least a partial implementation of TUF.
    - cm3 10y ago
      And opam (OCaml) is working on it too.
    - deleted 10y ago
      [deleted]
breakingcups 10y ago
Quite obligatory XKCD: https://xkcd.com/927/ https://xkcd.com/927/
- adontz 10y ago
  While this link is the expected joke, it is not joke at all. I'm writing software updater right now. Security is one of major concerns. Target platform, both client and server side is Linux. I write most of the code in Python. Looks like great opportunity to use TUF. But it is not. My updater has so many specific requirements that TUF is not nearly what I need. More than this, TUF is not subset of what I need and cannot be foundation for what I need, even from security perspective.
  - bennofs 10y ago
    Can you share what your different requirements that are not supported by TUF are?
    - adontz 10y ago
      Software is split into a few overlays. Each overlay is filesystem slice, some overlays may have intersection. They are merged in specific order to get the final filesystem. Some overlays may be version-related (v1, v2), some environment-related (test, live), some may contain specific device configuration. Ordered overlay set forms an update stream. (That's just terminology we use, I do not want to teach somebody how to call things right) Initially client knows only own hardware ID (which is just sha256 of part serials, MAC, etc.), and registers itself on server, which is allowed only from trusted networks. During registration client receives unique HTTP client certificate. Later administrator approves registration and assigns client specific stream. Stream may include sensitive information, like unique credentials to access some other services. Some overlays, which are not secret, like executables, 3rd party libraries, OSS stuff, are just rsynced to save time and bandwidth, but others like configuration and credentials, are downloaded over HTTP with client certificate authentication. Overlays are merged on client side in memory and applied in semi-atomic way (series of file moves within partition, not writes or other I/O in between). There are a few other requirements, like log if devices tries to register second time, log if device tries to register from non-trusted network, log every update attempt, successful or failed, etc. And this is of course just brief overview. For instance, administrator approving registration is not a single person, but group of administrators, each with different permissions on streams. Client cannot download stream of some other client, and cannot get any information on overlays used by other clients, etc. I do not see any way generic updater [framework] (not only TUF) to fulfill my requirements not causing more problem, than solved.
fit2rule 10y ago
We've got a great update framework already, if only everyone would use it: git. Seriously. I can't think why this wouldn't "just work".
- asdfadr1344kk 10y ago
  You can't think of it because you don't understand TUF's theat model.
- AndrewDucker 10y ago
  Because it means downloading the entire history when all you want is the latest version.
  - tokenizerrr 10y ago
    git clone --depth=1, git fetch --depth=1, etc. Though I suppose then you get things like https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193772935 https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...
- bennofs 10y ago
  From " 1.5.2. Goals for specific attacks to protect against" from the TUF spec: Git protects against: * Arbitrary installation attacks. (Because metadata is signed) * Extraneous dependencies attacks. (Because metadata is signed) * Mix-and-match attacks. (Because a git commit hash depends on its parents) * Rollback attacks, assuming you make sure you only fast-forward when pulling. * Wrong software installation. It does not protect against: * Indefinite freeze attacks. The attacker could just replay the same signed git repository for a long time. * Vulnerability to key compromises. (Everyone can sign any commit, no separation) It also has no built-in support for mirrors, and you cannot delegate trust to sub-maintainers easily, since any person who can sign a commit may potentially modify every file in the repo. So I don't see how `git` is a valid solutions to the problems that TUF wants to solve.
- tonyedgecombe 10y ago
  When your only tool is a hammer everything starts to look like a nail.
wtbob 10y ago
From the spec: > Delegated trust can be revoked at any time by the delegating role signing new metadata that indicates the delegated role is no longer trusted. This is a mistake, as it means that a client must receive the new metadata in order to be made aware of the revocation. The correct approach is either to delegate trust for a particular time period (determining how long is a risk-based decision), or to specify an online trust check (this fails safe).
- bennofs 10y ago
  Doesn't the `snapshot.json` file protect against "not being aware of the revocation"? Since `snapshot.json` can be trusted to be up-to-date (due to being included by hash in `timestamp.json`), and `snapshot.json` has a hash of all metadata files, we can be sure that our metadata is up-to-date (or at most as old as the interval after which `timestamp.json` is considered out of date, which is as you say a risk-based decision). And our metadata includes the delegations, so if the metadata is up to date, then so is our delegation information.
- evancordell 10y ago
  Every metadata file, including those that specify delegations, have an expiration. There are also higher-level expirations in the snapshot and timestamp files (a delegation won't be trusted if it's referenced by an out-of-date snapshot or timestamp) I.e. there are multiple time-based controls in place
amelius 10y ago
Shouldn't this be part of the OS?
- wmf 10y ago
  Probably, but should language package managers wait until all major OSes add this functionality or should they implement it themselves?
- djsumdog 10y ago
  sigh. I know there are those in the Python/Pypy community that thing everything should be done via pip; not the system manager. Others say we should have system packages (and they make elaborate systems that check for new python packages they use and build them with fpm). I really prefer the system managers, but what if things don't get new packages in a timely manager. When I was on openstack security, we used the Cannonical repos since they updated faster than the Debian repos, but some major exploits would be left out there for half a month (which lead down the path of; do we want to run our own CI-builds so we can deploy CVE patches immediately). This isn't even getting into the issues with Java/Scala/Groovy projects that could have jars with exploits embedded within the project (most OS packages let projects keep their own jars, instead of using a set of system jars. Gentoo tries to use system jars, but oh boy is that it's own crazy mess). There are lots of programs that embedded C/C++ libraries for stability/error reporting (I'm looking at you Firefox/Libreoffice) and hence there are scanning tools for finding these embedded libraries with security issues (some guy did a talk on this at Ruxcon 2012 I believe). TL;DR It's turtles all the way down.
heavenlyhash 10y ago
Everyone: Read this. At least the threat models. Do not assume all software you currently use gets these things right.
cookrn 10y ago
The Github PR for merging this into Rubygems is ~3 years old: https://github.com/rubygems/rubygems/pull/719 https://github.com/rubygems/rubygems/pull/719

140 points by ashitlerferad 10y ago

So obviously we have to wonder why TUF hasn't been applied to NodeJS's npm. All I can find is a suggestion that maybe someone from TUF posted to a node mailing list in 2014 [1]. Any more recent info? [1]: https://groups.google.com/forum/m/?fromgroups#!topic/theupdateframework/GbWtUbnO8_I https://groups.google.com/forum/m/?fromgroups#!topic/theupda...

zamalek 10y ago
I assume that you'd first need a native JS TUF package published to NPM. I don't think that adding another language dependency is a decision that would be taken lightly. Additionally, I don't see any Windows instructions (NB: python-ffi) and Node supports Windows as a first-class citizen.
raesene10 10y ago
AFAIK several language package managers have looked at implementing TUF for their repositories, but the only live implementation that I know of is Docker Content Trust. I kind of think it's an important part of secure management of libraries. As the Fosshub breach last week showed, software repo's are tempting targets for attackers...
- bennofs 10y ago
  Hackage/Cabal also has at least a partial implementation of TUF.
  - cm3 10y ago
    And opam (OCaml) is working on it too.
  - deleted 10y ago
    [deleted]

breakingcups 10y ago

Quite obligatory XKCD: https://xkcd.com/927/ https://xkcd.com/927/

adontz 10y ago
While this link is the expected joke, it is not joke at all. I'm writing software updater right now. Security is one of major concerns. Target platform, both client and server side is Linux. I write most of the code in Python. Looks like great opportunity to use TUF. But it is not. My updater has so many specific requirements that TUF is not nearly what I need. More than this, TUF is not subset of what I need and cannot be foundation for what I need, even from security perspective.
- bennofs 10y ago
  Can you share what your different requirements that are not supported by TUF are?
  - adontz 10y ago
    Software is split into a few overlays. Each overlay is filesystem slice, some overlays may have intersection. They are merged in specific order to get the final filesystem. Some overlays may be version-related (v1, v2), some environment-related (test, live), some may contain specific device configuration. Ordered overlay set forms an update stream. (That's just terminology we use, I do not want to teach somebody how to call things right) Initially client knows only own hardware ID (which is just sha256 of part serials, MAC, etc.), and registers itself on server, which is allowed only from trusted networks. During registration client receives unique HTTP client certificate. Later administrator approves registration and assigns client specific stream. Stream may include sensitive information, like unique credentials to access some other services. Some overlays, which are not secret, like executables, 3rd party libraries, OSS stuff, are just rsynced to save time and bandwidth, but others like configuration and credentials, are downloaded over HTTP with client certificate authentication. Overlays are merged on client side in memory and applied in semi-atomic way (series of file moves within partition, not writes or other I/O in between). There are a few other requirements, like log if devices tries to register second time, log if device tries to register from non-trusted network, log every update attempt, successful or failed, etc. And this is of course just brief overview. For instance, administrator approving registration is not a single person, but group of administrators, each with different permissions on streams. Client cannot download stream of some other client, and cannot get any information on overlays used by other clients, etc. I do not see any way generic updater [framework] (not only TUF) to fulfill my requirements not causing more problem, than solved.

fit2rule 10y ago

We've got a great update framework already, if only everyone would use it: git. Seriously. I can't think why this wouldn't "just work".

asdfadr1344kk 10y ago
You can't think of it because you don't understand TUF's theat model.
AndrewDucker 10y ago
Because it means downloading the entire history when all you want is the latest version.
- tokenizerrr 10y ago
  git clone --depth=1, git fetch --depth=1, etc. Though I suppose then you get things like https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193772935 https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...
bennofs 10y ago
From " 1.5.2. Goals for specific attacks to protect against" from the TUF spec: Git protects against: * Arbitrary installation attacks. (Because metadata is signed) * Extraneous dependencies attacks. (Because metadata is signed) * Mix-and-match attacks. (Because a git commit hash depends on its parents) * Rollback attacks, assuming you make sure you only fast-forward when pulling. * Wrong software installation. It does not protect against: * Indefinite freeze attacks. The attacker could just replay the same signed git repository for a long time. * Vulnerability to key compromises. (Everyone can sign any commit, no separation) It also has no built-in support for mirrors, and you cannot delegate trust to sub-maintainers easily, since any person who can sign a commit may potentially modify every file in the repo. So I don't see how `git` is a valid solutions to the problems that TUF wants to solve.
tonyedgecombe 10y ago
When your only tool is a hammer everything starts to look like a nail.

wtbob 10y ago

From the spec: > Delegated trust can be revoked at any time by the delegating role signing new metadata that indicates the delegated role is no longer trusted. This is a mistake, as it means that a client must receive the new metadata in order to be made aware of the revocation. The correct approach is either to delegate trust for a particular time period (determining how long is a risk-based decision), or to specify an online trust check (this fails safe).

bennofs 10y ago
Doesn't the `snapshot.json` file protect against "not being aware of the revocation"? Since `snapshot.json` can be trusted to be up-to-date (due to being included by hash in `timestamp.json`), and `snapshot.json` has a hash of all metadata files, we can be sure that our metadata is up-to-date (or at most as old as the interval after which `timestamp.json` is considered out of date, which is as you say a risk-based decision). And our metadata includes the delegations, so if the metadata is up to date, then so is our delegation information.
evancordell 10y ago
Every metadata file, including those that specify delegations, have an expiration. There are also higher-level expirations in the snapshot and timestamp files (a delegation won't be trusted if it's referenced by an out-of-date snapshot or timestamp) I.e. there are multiple time-based controls in place

amelius 10y ago

Shouldn't this be part of the OS?

wmf 10y ago
Probably, but should language package managers wait until all major OSes add this functionality or should they implement it themselves?
djsumdog 10y ago
sigh. I know there are those in the Python/Pypy community that thing everything should be done via pip; not the system manager. Others say we should have system packages (and they make elaborate systems that check for new python packages they use and build them with fpm). I really prefer the system managers, but what if things don't get new packages in a timely manager. When I was on openstack security, we used the Cannonical repos since they updated faster than the Debian repos, but some major exploits would be left out there for half a month (which lead down the path of; do we want to run our own CI-builds so we can deploy CVE patches immediately). This isn't even getting into the issues with Java/Scala/Groovy projects that could have jars with exploits embedded within the project (most OS packages let projects keep their own jars, instead of using a set of system jars. Gentoo tries to use system jars, but oh boy is that it's own crazy mess). There are lots of programs that embedded C/C++ libraries for stability/error reporting (I'm looking at you Firefox/Libreoffice) and hence there are scanning tools for finding these embedded libraries with security issues (some guy did a talk on this at Ruxcon 2012 I believe). TL;DR It's turtles all the way down.

heavenlyhash 10y ago

Everyone: Read this. At least the threat models. Do not assume all software you currently use gets these things right.

cookrn 10y ago

The Github PR for merging this into Rubygems is ~3 years old: https://github.com/rubygems/rubygems/pull/719 https://github.com/rubygems/rubygems/pull/719