Notice about vulnerabilities in libappimage (and appimaged)

[Scarlett Moore]

On Thursday, September 17, 2020 1:41:26 PM MST Scarlett Moore wrote:
> On Wednesday, September 16, 2020 2:19:04 PM MST TheAssassin wrote:
> > Hello everyone,
> > 
> > in July 2020, we've fixed vulnerabilities in libappimage [1] and
> > appimaged [2], two projects maintained by the AppImage team. Both
> > projects have been fixed upstream in the meantime.
> > 
> > libappimage didn't validate some non-trustworthy strings it embeds into
> > filenames, read from desktop entries embedded in AppImage. This could be
> > exploited into overwriting arbitrary files with malicious contents. The
> > issue was fixed in PR #146 [3]. We consider this bug to be of "medium"
> > severity.
> > 
> > Combined with a design decision in appimaged (which is, to automatically
> > integrate all files in specific directories, including ~/Downloads),
> > we've found appimaged to be especially easy to exploit. The reporter of
> > the issue managed to create a file that is not AppImage at a first
> > glance (an .mp3 file, to be precise), which however was indeed a
> > functional AppImage that was recognized by appimaged and integrated
> > automatically via libappimage. You can imagine that it's not too hard to
> > make people download e.g., .mp3 files, and they might not expect those
> > may install malware on their computers. Therefore, we consider this
> > issue to be of "high" severity.
> > Using a fixed libappimage with any version of appimaged fixes the issue
> > there, too. As far as we are concerned, the issue was therefore fixed by
> > rebuilding our official appimaged packages (which automatically fetch
> > the latest libappimage version).
> > 
> > The vulnerability in libappimage was assigned CVE-2020-25265, the issues
> > in appimaged were assigned CVE-2020-25266. According to the reporter of
> > these issues, the initial request was apparently lost, and the
> > resubmitted one received a response over 6 weeks after we fixed the
> > issue already...
> > We also forgot to notify distributions who might ship our software. The
> > CVEs have not been published yet to allow everyone to ship updates first.
> > 
> > Anyway. I see there's still lots of outdated/unsafe libappimage (and
> > some appimaged) packages out there, for instance:
> > 
> > - Debian stable, testing and unstable (via Repology [4])
> > - all distros which inherit packages from Debian (Ubuntu, Devuan, Kali,
> > Parrot, PureOS, Raspbian, ...)
> > - KDE neon (via Repology [4])
> > - openSUSE Leap 15.0-15.2 and Tumbleweed (via Repology [5])
> > - Nitrux (as far as I can see, e.g., Nitrux Software Center)
> > 
> > Please update libappimage, backport the fix or rebuild your appimaged
> > packages. Updates appreciated, so we know when to publish the CVEs.
> > 
> > Feel free to contact me if you have any questions.
> > 
> > Kind regards
> > The AppImage team
> > 
> > P.S.: A detailed analysis, based on the correspondence I had with the
> > reporter, will be published on my blog as soon as the CVEs will be
> > published.
> > 
> > [1] https://github.com/AppImage/libappimage/
> > [2] https://github.com/AppImage/appimaged/
> > [3] https://github.com/AppImage/libappimage/pull/146
> > [4] https://repology.org/project/libappimage/versions
> > [5] https://repology.org/project/appimaged/versions
> 
> Sorry, just saw this, somehow missed my INBOX. Working on patch, new release
> delays due to lack of manpower.
> Scarlett



Hi all,
I have commited this but I am unable to upload any packages, not even ones I 
am DM. It needs to be backported to stable ( same version ) .
Thanks,
Scarlett


-- 
Scarlett Moore
gpg: 7C35 920F 1CE2 899E 8EA9  AAD0 2E7C 0367 B9BF A089
Software Engineer @ Blue Systems
Debian Maintainer developer in training.
Netrunner PM
KDE Developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-kde-talk/attachments/20200918/56421d66/attachment.sig>