Hello,
I have a simple question
How do I completely remove this snapcraft system from my Linux system(s)?
Before I get “you just do not know how awesome it is”
I will make the following statement(s)
I know how awesome it IS making work for me until the end of the year in forensic auditing on top of my regular workload! we are talking 7 days a week!
1.) One system is Known to have been back-doored by a script kiddie using flatpack and snap updates last night through a simple systemd exploit ( still doing the forensics )
2.)Only been using Linux since 1993, SUN since 1988, BSD since 1994 so maybe some others know more than I thus the post…
3.) When looking at mounts the concept of having a bunch of blobs and symlinks is not system updates this is a old concept we abandoned vs loop mounting and linking them in a new weird format
Troubleshooting is easier when you only have EIGHT (8) mount points showing… not THIRTY EIGHT(38)
when managing thousands systems trusting a process running as root or with elevated privilege is a scary thought
Knowing what is mounted
Knowing what mounted it
Knowing what it is doing
Then the most important part (being able to unmount it)
Lastly Cleaning up after it – “properly done this step is a non issue”, but not snap snapd snapcraclkepop system being pushed
The concept of snapd mounting up images then symlinking ( reminds be of 1998 SCO 2.x so.lib linking for upgrades and sticky bits )
SNAP_CRACKLE_POP whatever it wants to be called is more trouble then value and I do not care who the designers are related to it was a bad idea that got an even worse implementation…
I am more akin to going back to doing pkg -add or snapshots via tar.cpio on BSD vs snapcracklepop.
Honest advice look at BSD tarsnap and jails might just find some useful information to salvage this venture because outside this echo chamber 70+% disapproval for the execution and management of this “package” approach.
Hi. Please publish the flatpak or snap package’s name that contains this malware.
I’m not sure that I understand your argument against snaps quite right; are you implying that the possibility of installing untrusted software is unique to those systems?
They used an exploit I am tracking though the logs to find which, but I can see the threads then they called “supporting packages in snapd which were trusted to enable toolsets and circumvent even having root”
You will have the data once I dd the hdd and move it to a point where I can work it out offline.
currently I am auditing the whole farm because of this little maneuver they pulled.
My point is not about the trust I see what is being attempted, but it is opening more doors and I will be more capable of telling which doors when I get through the events form 13 hours ago
Respectfully,
For context, I think you’re referring to classic packages, i.e. applications that do not run in snapd’s confinement. Such applications are still subject to the usual Unix permissions. Elevating privileges beyond those of the user would need authorization (i.e. sudo) or an exploit in snapd/apparmor/…
I’m very interested in your results. Especially if it’s an attack vector unique to snapd!
Hi @Nosnapd when you do identify the source of this, please send us an email with details at security@ubuntu.com first so we can take a look at any possible currently undisclosed vulnerabilities the attacker may have used.
We obviously take security very seriously both for Ubuntu and snapd specifically and want to ensure that whatever has happened to your machines does not happen to any other users, and disclosing the details in a private, responsible manner will ensure we can roll out any potential security fixes to users before any vulnerabilities are able to be exploited more.
