included libraries; recent xz-utils / liblzma compromise
mralusw opened this issue · comments
I ran
$ GVim-v9.1.0228.glibc2.29-x86_64.AppImage &
$ ls -d /tmp/.mount* # get auto-mounted AppDir
# /tmp/.mount_GVim-vRwbSEr
$ ldd /tmp/.mount_GVim-vRwbSEr/usr/bin/vim | grep -E 'lzma|systemd|perl|ruby|python|lua'
liblua5.3.so.0 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/liblua5.3.so.0 (0x00007efc1b9f4000)
libperl.so.5.30 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/libperl.so.5.30 (0x00007efc1b600000)
libpython2.7.so.1.0 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/libpython2.7.so.1.0 (0x00007efc1b200000)
libruby-2.7.so.2.7 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/libruby-2.7.so.2.7 (0x00007efc1ac00000)
libsystemd.so.0 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/libsystemd.so.0 (0x00007efc19cc2000)
liblzma.so.5 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/liblzma.so.5 (0x00007efc19c74000)
Two things to note here:
- The appimages do include
libruby
,llibperl
,liblua
and (interestingly)libpython2
(but not 3) which is different from what the release notes / documentation state. I had some release note PR's coming up in any case for unrelated stuff (AppRun.extracted
), so I ended up verifying and rewriting the docs. - by now I suppose everyone has heard of the
xz
/liblzma5
/sshd
backdoor (e.g. see the Debian fallout).- in short, Debian stable doesn't seem to be affected, and the vulnerability only seems to target Debian/Redhat-patched
sshd
anyway - because the
vim-appimage
's are currently built with Ubuntu 20.04, we probably link to (and "ship") even older versions. I thinkvim
can access compression algorithms (e.g. via its embedded languages) so this might still be a relevant point - the appimage compression algorithm (for the embedded
squashfs
) isgzip
, notxz
(see below)
- in short, Debian stable doesn't seem to be affected, and the vulnerability only seems to target Debian/Redhat-patched
$ GVim-v9.1.0228.glibc2.29-x86_64.AppImage --appimage-offset
193728
$ dd if=GVim-v9.1.0228.glibc2.29-x86_64.AppImage of=/tmp/x.squashfs bs=193728 skip=1
# ...
$ file /tmp/x.squashfs
/tmp/x.squashfs: Squashfs filesystem, little endian, version 4.0, zlib compressed # ...
yes, so we should not be affected. So anything to do for us here?
On the compromise, no, we should be more than OK (but I thought I'd check).
I'm trying to figure out what's going on with the embedded languages. We clearly ship some libraries as ldd
shows (and unlike what the release notes state).
- Python 3 apparently does not run out of the box (
:python3
yields E319). - Python 2 also does not work (
E887
) but it seems like it might be fixable by using the target's runtime (?) Lua
seems to work and fixed at 5.3Perl
at 5.30
I think the release notes are also wrong about installing those interpreters on the system — if they work at all, they will work with the builtin appimage version.
Findings: all interpreters are currently configured with --enable-*interp
. This means right now:
- all interpreters are "available" regardless of what's installed on the user's system
- but unless the user has Ubuntu 20.04, no interpreter will find their default packages
- in particular, Python 2 is enabled, but it can't actually run anything useful
- the others work to varying degrees (e.g. Lua doesn't seem to need anything)
I've reconfigured my builds to include this in scripts/build_vim.sh
CFG_OPTS+=( "--disable-pythoninterp" )
CFG_OPTS+=( "--enable-python3interp=dynamic" )
CFG_OPTS+=( "--with-python3-stable-abi=3.8" )
Only Python3 seems to have stable-ABI capabilities. On any system, one can set pythonthreedll=libpython3.11.so
or whatever, and appimage-vim will use it. To simplify things, I've written a vim script to auto-search for an the appropriate "dll" (link below); it seems to work on at least Debian derivatives.
For the other interpreters , vimhelp says this about */dyn
configurations:
The version of the shared library must match the $INTERP version Vim was compiled with.
… so for those, maybe non-dynamic is the least bad option.
What do you think should be done? I could
- turn on dynamic python3 and disable python2 with the
CFG
ops above - document the real state of affairs
- add a PR for
search-interpreter-dlls.vim
to the main branch, and -
- (maybe?) add it to the appimage-vim's default startup sequence, though this seems too much
fixed by #70