Turris OS 5.1.3 is released into the Stable branch!

Dear Turris users,

It is a pleasure to announce to you that we released Turris OS 5.1.3 from the Testing branch. There are fixes for security vulnerabilities with bug fixes and improvements.

What’s new in this release?

  • Fixed issue when CA for OpenVPN was not created in some cases
  • Make factory reset on Turris Shield easier - long pressing RESET button does factory reset
  • Updated Python to version 3.7.9
  • Updated adblock, zoneinfo, tinyproxy, logrotate, nextdns, netdata, bind, python3-urllib3, btrfs-progs, libuv, nano, chrony, uci, kernel, reptyr, psmisc
  • We marked the configuration file for nextdns, so in this update, it gets overwritten once again and since then the system would be aware that it should not overwrite it in upcoming updates. Thank you for reporting this issue on Reddit.
  • Dropped Transmission variants (openssl, mbedtls) according to upstream change in OpenWrt master branch and now, there is just one variant. Because of that, if you will install luci-app-transmission, it will install transmission with it. This change is included in OpenWrt LuCI master branch now.
  • Updated version of reForis, there should be a fix for WebSockets as some of you experienced infinite loading while using remote connection to your router.
  • Updated bind to the latest version 9.16.8, which has tweaks for DNS Flag Day 2020. For other resolvers, it will come with next fixup release Turris OS 5.1.4.
  • Updated youtube-dl to the latest version, which is these days 2020.11.1.1

Fixed CVEs:

  • tinyproxy: CVE-2017-11747
  • python-urllib3: CVE-2020-26137
  • chrony: CVE-2020-14367
  • libuv: CVE-2020-8252
    and more.

We suggest updating to this version as possible to protect your home against Internet Threats.

When you are using automatic updates, you will be updated to this version automatically. If you are using approvals and delayed updates, you can check the Updater tab in reForis for more details.

If you will find any bugs in this release, please report it to our Technical department, which is available at tech.support@turris.cz

9 Likes

Any known bugs for this version?

Omnia Indiegogo, /srv on ssd
Transmission got stopped and disabled with this update, had to re-enable and start manually…

I understand this is only informative news, but is there a complete and detailed changelog and all CVEs somewhere?

This is a little bit problematic. Life would be much easier if people would be using if they would include in the commit message “Fixes CVE-XXXX-YYYY” while they are contributing to any OpenWrt feed. If there is a package update, you need to go to its software homepage, find the changelog and see if there isn’t mentioned CVE. Also, you can check the security mailing list of some GNU/Linux distributions and see if the update of related software is present in OpenWrt or if someone does not have already open pull request.

This stuff is not automatic, and you need to manually compare or keep watching changes in related repositories. There is a file git-hash in our repository, so you can check which exact commits we are using from feeds.

On the other hand, I don’t want to copy&paste all the details from my previous posts, so I am trying a different approach. Hopefully, you like it.

1 Like

Do you mean OpenWRT or Turris website?
Because for example here https://openwrt.org/releases/19.07/changelog-19.07.4 does not have a single CVE of yours :wink:

Can you tell me exactly where he is, please.

Neither of it. We are tracking openwrt-19.07 branches, so we have the latest changes from related branches. Some of those packages are not preinstalled by default. If anyone is using them, then they will be updated and be safe against security vulnerability.

What I mean is to tracking changes in https://github.com/openwrt/openwrt/commits/openwrt-19.07 and https://github.com/openwrt/packages/commits/openwrt-19.07 and such repositories. All of those can be found here: https://gitlab.nic.cz/turris/turris-build/-/blob/v5.1.3/feeds.conf

Let’s have example.
Take a look at libuv update to version 1.40.0, which fixes CVE-2020-8252, this is not said anywhere in commit and you need to go to homepage of libuv and check it on your own. Sometimes it is not explicitly listed in changelog. Luckily for us, it was mentioned in the pull request. And there are security trackers like Debian has.

We are not waiting until OpenWrt does new releases. We are based on the latest OpenWrt 19.07.4 since version 5.1.1, but it was even earlier as we are tracking related changes. Source:

Mine listed CVEs are not fixed in OpenWrt 19.07.4. You would need to compile it yourself or wait until OpenWrt does a new release or try to use opkg upgrade, which is not suggested to use even on OpenWrt forum. They could be listed in the next release of OpenWrt 19.07.5 if it is going to be. Nobody knows that.

You should take a look at our documentation here and check our workflow.

What about this one: https://repo.turris.cz/hbs/omnia/packages/git-hash

1 Like

So it happens that TOS has an update earlier than the OpenWRT parent?

Thanks a lot for the clarification. Cheers!

You understand it well.

Hi there. On the MOX all is going fine, on the Omnia i do get a lot of errors on the HAAS pot after this update?..already tried to de and reinstall it, same error.

Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: Traceback (most recent call last):
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/urllib3/connection.py", line 160, in _new_conn
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/urllib3/util/connection.py", line 61, in create_connection
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/socket.py", line 752, in getaddrinfo
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: socket.gaierror: [Errno -3] Try again
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: 
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: During handling of the above exception, another exception occurred:
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: 
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: Traceback (most recent call last):
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 677, in urlopen
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 381, in _make_request
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 978, in _validate_conn
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/urllib3/connection.py", line 309, in connect
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/urllib3/connection.py", line 172, in _new_conn
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPSConnection object at 0x172c800>: Failed to establish a new connection: [Errno -3] Try again
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: 
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: During handling of the above exception, another exception occurred:
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: 
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: Traceback (most recent call last):
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/requests/adapters.py", line 449, in send
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 727, in urlopen
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/urllib3/util/retry.py", line 439, in increment
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='haas.nic.cz', port=443): Max retries exceeded with url: /api/validate-token (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x172c800>: Failed to establish a new connection: [Errno -3] Try again'))
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: 
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: During handling of the above exception, another exception occurred:
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: 
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]: Traceback (most recent call last):
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/haas_proxy/__main__.py", line 23, in <module>
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/twisted/application/app.py", line 669, in run
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/twisted/application/app.py", line 636, in parseOptions
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/twisted/python/usage.py", line 267, in parseOptions
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/twisted/python/usage.py", line 277, in parseOptions
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/haas_proxy/twisted/plugins/haas_proxy_plugin.py", line 71, in postOptions
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/haas_proxy/twisted/plugins/haas_proxy_plugin.py", line 85, in validate_token
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/requests/api.py", line 119, in post
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/requests/api.py", line 61, in request
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 530, in request
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 643, in send
Nov  8 09:56:20 turristhuis haas-proxy-start[7990]:   File "/usr/lib/python3.7/site-packages/requests/adapters.py", line 516, in send

MOX 512 MB with no additional services running (just more or less the basic config with dynamic firewall) ran out of memory trying to install this update.

Could it be possible to stop some services prior to the update, e.g. suricata? Or at least create a user-configurable list of services that can (and should) be stopped?

Out of curiosity, is it safe/supported to remove Foris with this version? I pretty much exclusively use either reForis or LuCi these days.

Thanks for the feedback. This happened as we backported related changes in Transmission, which were done in upstream. There were packages transmission-daemon-{openssl,mbedtls}, so user could decide which one would like to use and could have installed multiple TLS libraries. And right now, there is just one variant - transmission-daemon. We will try to fix it in upcoming releases.

I am wondering what more or less basic config means. Does it mean package labels with labels such High memory usage, which you can find in reForis? Because you mentioned Suricata as well, are you using PaKon - Parental Control? If yes then it could be related to your traffic as recent data are stored in RAM and data older after 24 hours are moved and stored in persistent archive database (/srv/pakon). More details about it can be found in our documentation here.

If you don’t need to have Storage, Nextcloud and Pakon plugin, then it is safe. It should be supported as long as you are familiar with LuCI/CLI.

Yes, Pakon is running there. But I’d still rather get Pakon stopped for a while than a failed update…

Does the automatic update work with Omnia on external drive? I’ve moved the root filesystem onto an mSATA drive which requires bootloader changes and am wondering if it should be safe to go with the update or is there likelihood it’ll mess up my setup.

That’s rather questionable if we want to stop random services that could be used at that time while the update is running. It depends on your traffic and Suricata itself has higher requirements.

Automatic updates works also if you are booting from external devices like mSATA SSD, USB flash drives, and so on. It could be problematic in the future once we update U-boot including U-boot Environment, which would be overwritten by defaults, but we will let you know about it here on the forum.

That’s why I alternatively asked for the possibility of giving us, users, a configuration, where we could say what can be switched off when an update is about to be installed. Something like drop-in directories maybe? pre-update.d, failed-update.d, after-update.d…

A post was merged into an existing topic: Optional migration from Turris OS 3.x for advanced users