CSA 0: zsh security update

Applications
#1

Chum Security Advisory 0

CVE-2021-45444: RyotaK reported a security issue in zsh, which could result in the execution of arbitrary code [1].

In Zsh 5.8 or below, malicious command outputs inside the prompt perform recursive PROMPT_SUBST expansion, which allows a malicious command output to execute arbitrary commands.

[2]

You are affected if PROMPT_SUBST is enabled. This is the default if you are using the ksh or sh emulation, but not if you are using “normal” zsh.

This problem has been fixed in version 5.8.1 as distributed via Chum.
I recommend that you upgrade your zsh package.

[1] ZSH - Release Notes
[2] Advisory #63 - RyotaK's Vuln DB

Given “normal” usage of a phone with zsh, this issue probably affects nobody using Sailfish/Chum, but maybe I’m wrong :slight_smile:

I know, given the all the circumstances, it’s a bit silly to publish this like this. I’m more interested on how big the userbase of zsh on Chum is and whether everybody just uses the default zsh.
For Chum, it would also be interesting on how users would like to handle security updates: Notification-only? unattended-upgrades-like automated installation of all updates, or only some?

#2

Thanks for this update + explainations :–)

Using it since years on my PC. For maybe too simple reasons: commands completion, aliases, colour prompt.
Tried to use it on SFOS but not sure: can I set it as default shell for user and root?

I’d say: notification and choose which to upgrade.

#3

IMO: No unattended upgrades or installations, ever. (If users really want that, they should be capable of setting up a timed job on their system which runs a refresh/update)

Unfortunately, all installs or upgrades may randomly include unattended upgrades, simply because PackageKit can’t do ‘install one upgrade but not the others’.
So unless Chum(GUI) wants to move to invoking zypper with some magic incantations, the question is a bit moot.

#4

I’m a big fan of going this way and started looking at the zypper libs. But then I got distracted by my million bugs and enhancement issues. … looks like it’s up to you :slight_smile:

#5

Nack, not interesing for me. I prefer doing pointless apps.

1 Like
#6

Sure, chsh -s /usr/bin/zsh works. But that’s at your own risk: if packaging is messed up or zsh stops working for a another reason, you will lose shell access which might be difficult to recover from.

Why? Do you see Chum as rolling release repo which possibly breaks things? I.e, you don’t expect/want stable updates from Chum (fixing bugs and nothing else, like Debian)?

I’m inclined to see Sailfish as a Linux distro just happening to run on my phone, and which is not the only device which needs my attention. There’s a whole bunch of similarly configured hardware (desktop, laptop, servers, …) of myself and others all running Linux, and manually installing each update is a bit tedious.

1 Like
#7

Chum is explicitly “wild west” so yeah - and this is in no way meant to diminish the efforts by original developers and the chum curators - I do regard it as a less quality software source than a proper Linux distro repo (more like an AUR or PPA all though the comparison might be unfair to the aforementioned).

One property of OBS is that there is no way back - once a package is published, its predecessors are gone. This is in contrast with most Linux distro repos where you usually can roll back.
So breakage if it happens is more permanent in the chum world.

Now all of this is wayyy better quality-wise than the Openrepos sources of course, but most users will have a couple of those enabled in addition to chum.

#8

Ah, modesty. False modesty. Let’s see: xtail :slight_smile: ok. youtube-dl. hmmm. someone ported nocache! What were we going to do with tsumego?

I’m just hoping SFOS moves to libzypp. I like it.

#9

I administer a ‘bunch’ of systems. Heterogeneous. With and without systemd. BSDs, too. It IS tedious, but I do a lot of manual intervention. I also no longer use puppet/chef/ansible and co. So, I’m obviously as far from the norm as you get.

But I prefer to do the maintenance. It’s like dusting. Hate it. But I hate dust more.

My last, ugly, update (a debian, 10->11) involved a package (fundamental to operations) which did not signal in any way that the update should be ‘of interest’. No security flags, just ‘fire and forget’. All my crypto lists stopped working. Ok, I had a backup software, installed an ready. Turns out, the list software maintainers had left out a db migration in the distributed package. On debian stable. Ah, ha. The ‘fix’ involved me manually writing SQL out of spite.

Unattended upgrades, even in conservative envs like debian, can cost you.

#10

I’ve been doing publishing too all stores, in part, for this reason. The long term, I’m trying to curate on openrepos (primarily for older SFOS versions) which still stresses the file store. I’m inclined to set up an archive server.

#11

True :slight_smile:
But what would you wish for? I’ve understood your “No unattended upgrades, ever.” to be the case even if automated upgrades would work out fine.

You did a full upgrade from Buster to Bullseye with unattended upgrades? Seems unlikely to me :slight_smile:
Even then, at some point (e.g. upgrades to a next OS release) you have to have some breaking changes. I like the idea to concentrate them at release upgrades, and have only bugfix updates to work flawlessly.

#12

Ok, I finally launch it manually every time to avoid some risk.
I had some cases on the PC where scripts didn’t work well into zsh.
In case the system relies on scripts, I thought it’s perhaps safer to keep the original shell as default.

Anyway, it’s a big enhancement for the shell use. I could copy all the .zsh… config files directly from the PC (+some adaptations).

For others newbies, in contrary of on the PC (where config files are/can be in /etc/zsh/), they need to be placed in /root and in the home directory.

Thanks again, SFOS term use became a pleasure!

#13

No, it was worse. The package made it into stable without having been tested. So a process which almost always works with little pain, dist-upgrade, was made hell by one package. Which happened to be important. That is why I do most upgrades by hand. I’m also a sloppy maintainer sometimes, so I don’t have the faith.