Vulnerability in transmission on the LEDE branch and policy on updating packages for LEDE

For Developers
1

I noticed that the transmission package on the lede-17.01 branch has not be updated since Jan 2017 and it is still on 2.92. In Openwrt 18 it was updated in May 2018 for version 2.94 and on Jan 28, 2018 to version 2.93.

On Jan 5, a vulnerability with transmission involving remote code execution was discovered and reported.

At the moment everybody running LEDE with the transmission package is vulnerable. Considering that transmission advertises its version to its pears, any malicious peer can realize that the daemon running on the router is vulnerable and try to exploit it...

A few people (including me) was thinking that the service release of 17.01.6 one month ago meant that all vulnerabilities up to that date were patched.

I think this should be patched considering that a few people are still running LEDE.
I wonder if I was "lucky" to find out this or it is not the only case of outdated vulnerable code in LEDE. I am not sure if the wolfssl used in openwrt is vulnerable to this https://www.cvedetails.com/cve/CVE-2018-1000517/ but it would not be a bad idea to update it.

I have a few questions:

  • When somebody updated a package (but also on the "generic" core) in the latest Openwrt version, should it not be also back ported to the previous Openwrt version? Maybe not for everything but at least to fix a vulnerabilities.
  • If an update is necessary, is there a way to update the package? It looks that when there is a release the git commits of the feeds are fixed. I can change it if I recompile from source but I do not think there is a easy way to change it later.
  • Should not be possible to download updates on the packages automatically for users without having to re-install Openwrt from scratch?
2

Sure, the fix can be backported to the previous branch. But there are thousands of packages and there are no common resources to do the backports. Feel free to author, compile and test the backport into 17.01, and then please issue a pull request to get your backport into the official sources. This is a community effort, so your help is needed...

Assuming that all known security fixes are always fixes in all the packages, is just wrong. There are no resources for such an effort. In general, the focus is mainly on master, and not everything gets backported into older branches.

Once your backport is there in the source repo, buildbot will compile the package and users can install it via opkg (with any need of reinstalling the whole openwrt). You understood the pinned feeds at release wrongly. You only get the old pinned feeds if you erroneously now checkout and compile an old release instead of the 17.01 branch head.

Note that 17.01 is already now on limited support and will have endoflife in a few months.

3

Sorry, you are saying that you do not need to do anything to install the new package? Is the user notified in some way that there is an update?

What do you mean by?

4

No, I did not say that.
I said that once it has been backported, and compiled by buildbot into the download repo, the user can install it with opkg package manager. But there is no notification about updates.

Regarding pinned feeds, I pretty much mean just what you quoted from me. If you compile a branch head, you can get the packages that have been updated in that branch. But if you compile from an old release tag, you get the old versions of packages due to that hash pinning that you referenced "git commits get fixed at release".

Buildbot also builds the updated user space packages so that they are available for installed releases via opkg. But somebody needs to do the backporting first.

5

Ok. Thanks. Can I ask you why you do the hash pinning for the release then? Just to have a reference to what was available at the time of the release?

6

Yep. Some people want reproduceable builds, so that pinning provides a static version of the release (not only the core Openwrt, but also the packages from feeds)