snap boasts security risk in conjunction with 'command-not-found' tool on Ubuntu?!

[TitForTat]

Hey all,

I came across an article which claims:

"While 'command-not-found' serves as a convenient tool for suggesting installations for uninstalled commands, it can be inadvertently manipulated by attackers through the snap repository, leading to deceptive recommendations of malicious packages (...)"

Apparently the tool suggests packages, if what you try to install is not available. It than includes suggestions from snap AND apt.

As I understand, the main issue is with the 'command-not-found' tool and that snap can be used to upload malicious packages under false names. So snap does not get monitored in any way? Allegedly, up to 26% of apt-packages are prone to impersonation by malicious actors.

Now, is it only the tool that problematic or because snap seems to be an open field to publish any package? How about flatpak then? Could this happen there also, if used in conjunction with the aforementioned tool or are flatpaks monitored?

If anyone could give some more knowledgeable insight, that would be so awesome. Just wanting to understand the whole of it and I find the topic of it-security especially regarding linux highly interesting.

One more question: is that tool an ubuntu-only-tool? Is it used in Mint 21.3 or did the dev team remove it alongside with snap?

The article: https://thehackernews.com/2024/02/ubunt ... could.html

[xenopeek]

Let's link to the source article instead: https://www.aquasec.com/blog/snap-trap- ... on-system/

There's no security risk with command-not-found itself. What it does is simply: when your shell can't find a command you typed it searches your configured APT repositories for packages that have that command, and tell you how to install it. It does the search on your computer, using cached repository metadata. When you add the Snap store to your system - it is disabled on Linux Mint - that adds functionality to also search the Snap store. There is no such functionality for flatpak. You can confirm this for example by trying to run gedit on the command line - it is available from the default APT repositories, the Snap store and Flathub. command-not-found will only let you know for the APT repository, and the Snap store if you enabled it. Not for Flathub - which Linux Mint has enabled.

As the article details somebody submitting a Snap package could create it with limited permissions and that way avoid a manual review. They're saying it is possible, not that it happened. And searching the Snap store, using Ubuntu's software center, would be affected by the same so this isn't about a command-not-found problem. Possibly Ubuntu will review its Snap store review process for new submissions. Android and iOS app stores have suffered from fake and bad apps for a long time - malware with names similar to other apps to trick user to install them.

I'm not very familiar with the Snap store but taking gedit again as example this https://snapcraft.io/gedit page tells me nothing about the origin of the package or how it was built. Compare that with how Flathub shows it https://flathub.org/apps/org.gnome.gedit. Scroll down a bit, go to the Links tab and click on Manifest takes you to https://github.com/flathub/org.gnome.gedit. The .yml file there spells out how the package is built and what sources it uses. You can use that also to build the flatpak on your own system. So anybody can review the flatpak.

[TitForTat]

Let's link to the source article instead: https://www.aquasec.com/blog/snap-trap- ... on-system/

@xenopeek Thanks for adding the link, your explaination/clarification and examples. Definitely reading through this later on.

I am just wondering why they go with snap and eventually want to use it as their main package manager in the future. The "issues" seem not to be news (besides for me ).

Moreover, snap seems to be present in Ubuntu Pro as well, which (in my opinion) contradicts their promise on seemingly better security. Strange for a paid product mainly aiming for enterprise use (as they state themselves). Such issues can bee even more detrimental in a professional environment. Of course that is now a question regarding company/business decisions, which cannot be answered here. But it leaves me wondering even more.

[MikeNovember]

[...]
I'm not very familiar with the Snap store but taking gedit again as example this https://snapcraft.io/gedit page tells me nothing about the origin of the package or how it was built. Compare that with how Flathub shows it https://flathub.org/apps/org.gnome.gedit. Scroll down a bit, go to the Links tab and click on Manifest takes you to https://github.com/flathub/org.gnome.gedit. The .yml file there spells out how the package is built and what sources it uses. You can use that also to build the flatpak on your own system. So anybody can review the flatpak.

Hi,

You just forgot one information: https://snapcraft.io/gedit tells you publisher is Canonical,

Regards,

MN

[xenopeek]

gedit was just a random example that I know to be available from all 3.

[TitForTat]

It seems that snap is verifying accounts, which are at the same time "publishers". So it is up to the user having the choice if a package should be installed from an unverified account/publisher or not. But this is only true, if you use a gui. It seems not to display on the terminal in any way or form (so falling back on the issue that "command-not-found" facilitates that snap problem). And yes... no origin of that app. Interesting, that they know about it since 2016... love that friendlyteddy example

So there seems to be manual review processes when an alias is requested, but they only check, if it lines up with the program. As I understand this, it is only a check for conclusiveness?!

Anyway... let's hope Canonical fixes the whole process asap and before they launch Ubuntu with only snap packages. I guess disabling the tool for now is the safest way, if snaps have to be used. Other than that... just dont use snap Good thing Mint users don't need to worry about this but I still worry about the enterprise side of Ubuntu, if some half knowledgeable person is supposed to do something.

Imagine you pay for Ubuntu Pro couple of thousands, with snap enabled by default, and you run in that exploit... Your company server gets encrypted and a terminal middle finger flies over your screen. That lawsuit I don't want to see... and want to see (just kidding... that would be much more complicated I suppose).

In the end, I do understand those people, who stay away from snaps and flatpaks entirely. Not only due to possible problems with things breaking after updates but for concerns like that. I guess the luxury of added choice of apps from third parties comes with some risk afterall.

Edit: Just found that other topic discussing that security incident from Sep. '23 regarding malicious snaps. Thats where the manual review process comes from, I suppose. So it happend in the past already (also in 2018), just not via the "command-not-found" tool.

[RWMills]

When you add the Snap store to your system - it is disabled on Linux Mint - ...

Is there any way you can check (in a Bash/Ksh script or Conky) that Snap is disabled?

[xenopeek]

If you run the command dpkg -s snapd it should reply this:

Code: Select all

dpkg-query: package 'snapd' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files

The 1st line confirms it is not installed and is not available to install either. Linux Mint blocks snapd by default: https://linuxmint-user-guide.readthedoc ... ux-mint-20

[MikeNovember]

gedit was just a random example that I know to be available from all 3.

Hi

I just wanted to remark that the snap publisher is mentioned.

If the publisher is Canonical, you can trust the snap, as you trust Ubuntu provided debs.
If the publisher is not Canonical, you have to decide if you trust it or not.

There is a similar problem with flatpaks: some are published by the original developer (example: flatpak Firefox is published by Mozilla). Most are published by independent developers that just package the app in flatpak.

Of course, the links allow you to reach the GitHub site of flatpak packagers and make some checks.
However, if you can find very detailed information, like with gedit, you are in the same case as comparing source with a deb: without compiling the source you can't say the deb is authentic, and without creating the flatpak from the yml, you can't say it is authentic.

Moreover, on some flatpak apps, the information provided by the packagers is very low.

Trust or not... this is the question as soon as you use anything else than the packages from the distro you trust!

Regards,

MN

[xenopeek]

without creating the flatpak from the yml, you can't say it is authentic.

That's not the case. Flathub uses a buildbot to build the flatpak from the yml file - it's not built manually by a maintainer. Each PR is built by the buildbot and links to the build log.

[MikeNovember]

Hi,

There is also an automatic build process for snaps, see https://snapcraft.io/build

I agree that it is easy to find the GitHub project behind a flatpak, since it is given in the links as "manifest", while it is not mentioned for a snap.

Note also that the use of bot (for flatpak) or automatic build (for snap) are widely used but they remain options: you can still produce your flatpak or snap on your computer, then publish it.

It is sure that more transparency on Canonical snap store is needed to favour snaps use. However, when the publisher is Canonical or a well known company, there is no risk to adopt a snap.

Regards,

MN

[xenopeek]

Note also that the use of bot (for flatpak) or automatic build (for snap) are widely used but they remain options: you can still produce your flatpak or snap on your computer, then publish it.

Can I recompile an app from the snap store with my patches applied? Must be the greybeard in me but I'm accustomed to fixing annoyances in apps with a small patch and recompile. I hit a dead end on https://snapcraft.io/build, that just looks to be for uploaders - not users who want to apply a patch to an app from the snap store.

I can recompile system packages, I can recompile flatpaks. If it's possible with snaps it's hidden for me.

when the publisher is Canonical or a well known company, there is no risk to adopt a snap.

Tedious work to find those needles in the haystack. Canonical has just 100 snaps. Most of them server stuff, some few APT package replacements: https://snapcraft.io/publisher/canonical

On Flathub verified apps are clearly marked as such - so as a user you don't need to look at the publisher and figure out if/how they are the apps' developers, just look for the blue verified checkmark next to the name - and there's almost 900 of them now: https://flathub.org/apps/collection/verified/

It is sure that more transparency on Canonical snap store is needed to favour snaps use.

They are not going to cut holes in the hedges in their walled garden

[MikeNovember]

Hi,

If you look at the contents of flatpaks or snaps you will find Linux executables, and some dependencies.

The remaining dependencies are found in runtimes or cores.

You can change the content of the flatpaks or snaps, replacing some of the files.

You cannot "recompile" all flatpaks, since a large part are made not from sources but from binary packages (example, see FreeFileSync flatpak); same thing for snaps, they are not all built from source (one kind of snap applications is repackaging oldware as snaps, in order to get them available again).

Finally, the main difference is universality: flatpaks, using bubble wrap sandboxing, can be used on any distro, using SELinux or AppArmor.

Snaps make an heavy use of AppArmor and work well on Debian and derivatives, but they don't work well on Redhat and derivatives: SELinux and AppArmor cannot well be used at the same time, and the more snaps running when SELinux is enabled, the less is snaps security.
Canonical has not yet found a way to solve this problem.

A side remark: there is an open issue about Timeshift not able to restore correctly a system with snaps (empty snap directory after restore).
Is this problem solved?
This decreases the confidence in Timeshift: if it is not able to restore snaps, how can we be sure it is able to correctly restore an operating system?

Regards,

MN

[TitForTat]

Quite a late reply, but good to see all the banter

I checked their respective documentation. For snap, a manual review takes place for apps using "classic confinement" only. As for the incident in sep. 2023, it seems that the temporary manual review is now a permanent one. To my understanding, there is no review at all regarding apps using the "strict confinement", so proper containerization. If you ask me, thats a bit "meh". Sure, it is less "dangerous" since it is not directly accessing the system as apps in "classic confinement" do. But no oversight at all (manual/human in this case... there seems to be an automated tool that does some reviewing... but poorly)?! Adding the alias/name registration process and clever typosquatting, you still could end up with fake apps that dont have system access, as they are published in a strict confinement. But they still trick users in believing they installed the right thing, giving away user sensitive/confidential data. Sure, one could argue, that a huge portion of user error is at play, since the user did not check twice, if it is the actual app from the "true" publisher/from the "right" source. But providing such opportunity is still a security flaw in my books.

Coming to flatpaks. Such an app, that could seem harmless and still steal user data by tricking them about the actual functionality of the app, cannot be 100% avoided (as I see/understand it). BUT as for the flatpak documentation, they state that you have to make 1) a pull request which is 2) followed by a review by volunteers. This indicates, that there is a manual review behind each damn app that seeks to be published. I was not able (yet) to find any statements how the review process looks like (e.g. only checking for app duplicates to avoid fake apps or actually checking/building the app to see if there is some unusual stuff going on while using it).

A more in-depth review leeds to slow(er) publishing speed but taking into account how much damage could be done, taking the slow but thorough approach is the way to go (imo).

Unfortunately, I am not as knowledgeable as you guys, when it comes to the technical side, but it seems to be obvious that canonical is taking some shortcut where they shouldnt. At least flathub is ticking some more boxes when it comes to security, flatpaks come only containerized ("strict" as in snap terms) and they still get a manual review treatment. At least thats what I understand... there is no counter part to snaps "classic confinement" at flathub.

Let see how canonical is going forward with this!

Sorry for any grammar mistakes... my english seems to be broken today.

[MikeNovember]

[...]
Unfortunately, I am not as knowledgeable as you guys, when it comes to the technical side, but it seems to be obvious that canonical is taking some shortcut where they shouldnt. At least flathub is ticking some more boxes when it comes to security, flatpaks come only containerized ("strict" as in snap terms) and they still get a manual review treatment. At least thats what I understand... there is no counter part to snaps "classic confinement" at flathub.
[...]

Hi,

Flatpaks applications can't, in any way, write in the operating system: the maximum capability they can have is "filesystem", and with this they can read/execute files in "/", read/write/execute files in "/home" and in removable devices.

Flatseal can be used to adjust these permissions, particularly to reduce write permissions in "/home".

Regards,

MN

[MiZoG]

An even more entertaining one...
A Snap package from Canonical's Snap store stole digital coins from its user

[TitForTat]

Hi,

Flatpaks applications can't, in any way, write in the operating system: the maximum capability they can have is "filesystem", and with this they can read/execute files in "/", read/write/execute files in "/home" and in removable devices.

Flatseal can be used to adjust these permissions, particularly to reduce write permissions in "/home".

Thanks for explaining! I wonder, why and when you need to have read/write permissions for what in /home... but I may do some reading on that next couple of days myself. I wonder, if one could "seal" the container in which the app is running and allow only files to put into the container. So everytime the app needs extra data/files, the user has to choose it manually after getting asked by the app (or the user can give permanent permission to one specific file/folder permanently until read/write rights are revoked). But I guess thats exactly what flatseal is there for. The main concept I have in mind is, rather not limiting access (expansion of the applications rights) but "injecting" necessary data by the user into the "sealed" invironment when it is needed. Again, I do some reading later. I should check some eu it-security legislation like nis2 etc. to see what the legal framework looks like on security procedures etc.

An even more entertaining one...
A Snap package from Canonical's Snap store stole digital coins from its user

Yes I saw that too. It just keeps goining. Lack of security measurement up front and apparently no measurements after the discovery of the malicious app. You can keep the program on the system. Canonical is just having a blog post, notifying users and removing the app from the store (at least they do that). Maybe they should implement a popup while using ubuntu, notifying that you have an malicious app on your system (name of the app, the security flaw and the implications for the user) and providing a button the remove the app and related packages from the system, just by clicking on it. If the user decides to keep it (for what ever stupid reason) they just can close the window after ticking a box to confrim, that they/users received proper notification/information and an option to remove the app but choose not to and take all risks and possible damages on themselves (a lot of legal stuff going on in the background than).

Just read about the desktop security center app that canonical is developing. So strange! Maybe fix the issues with snap first and improve further on the security app later on. But I guess ubuntu want to go on the fast lane with snap for the snap only implementation/release of ubuntu.

https://www.omgubuntu.co.uk/2024/02/fir ... ity-center

[xenopeek]

Flathub's blog had some relevant news this week https://docs.flathub.org/blog/improved-build-validation:

We have also started moderating all permission changes and some critical MetaInfo changes. For example, if a build adds or removes a static permission (as seen in the finish-args array in the manifest) or changes the app’s user-facing name, it will be withheld for manual human review.

[TitForTat]

Flathub's blog had some relevant news this week https://docs.flathub.org/blog/improved-build-validation:

We have also started moderating all permission changes and some critical MetaInfo changes. For example, if a build adds or removes a static permission (as seen in the finish-args array in the manifest) or changes the app’s user-facing name, it will be withheld for manual human review.

Thx for sharing and good call by the flathub team.

I must say... some parts I still find confusing on how things work/work together but as I mentioned before, I adress that later. That may take a while actually I definately keep my eyes peeled for any further news