Ubuntu Snap Store enthielt Malware

[KBDCALLS]

• Der Ubuntu Snap Store hat Snaps angeboten, die Malware enthielten, um per Crypto-Mining Hardware-Ressourcen der Anwender zur Erstellung von ByteCoin abzuzweigen.

Weiteres auf ProLinux

[uname]

Muss ja passieren, wenn man die Nachteile von Windows, Google Play oder App Store in die Linux-Welt portiert.

[Nice]

@uname.

Muss ja passieren, wenn man die Nachteile von Windows, Google Play oder App Store in die Linux-Welt portiert.

Exakt!

[MSfree]

@uname.

Muss ja passieren, wenn man die Nachteile von Windows, Google Play oder App Store in die Linux-Welt portiert.

Exakt!

Mal abgesehen vom Bedienkomfort, wo ist denn der Unterschied zwischen dem "Appstore" und einem Softwarerepository, das ich per apt... benutze?

[DeletedUserReAsG]

Wenn du sowas wie PPAs oder sonstige Fremdquellen einbindest und mit apt* benutzt: gibt keinen Unterschied.

[pferdefreund]

Mit apt geht es schneller und zuverlässiger - aber Konsole ist halt nicht per Fingertip bedienbar. Wer kennt heute noch CICS 3270-Terminals, TSO VTAM usw. War alles viel schneller zu bedienen wie jede grafische Oberfläche und zuverlässiger sowieso. NIcht ohne Grund laufen die Dinos auch heute noch da, wo es wirklich drauf ankommt.

[Nice]

@MSfree:

Mal abgesehen vom Bedienkomfort, wo ist denn der Unterschied zwischen dem "Appstore" und einem Softwarerepository, das ich per apt... benutze?

Think!

[KP97]

Wer kennt heute noch CICS 3270-Terminals, TSO VTAM usw.

Ich...habe ich auch mit gearbeitet...lang ist's her....

[spiralnebelverdreher]

... Wer kennt heute noch CICS 3270-Terminals, TSO VTAM usw. War alles viel schneller zu bedienen wie jede grafische Oberfläche und zuverlässiger sowieso. NIcht ohne Grund laufen die Dinos auch heute noch da, wo es wirklich drauf ankommt.

Ich kenn das IBM Zeugs noch von früher. Zuverlässig heißt aber nicht unbedingt, dass es da keine Sicherheitslücken gab; ich bin mal zufällig in den 80er Jahren darauf gestoßen, als ich einen Tippfehler bei einem Dateinamen machte und plötzlich Fragmente von anderen Dateiüberresten aus ganz anderen Anwendungen zu sehen bekam: Personendaten aus Bewerbungen für Hochschulzulassungen beispielsweise. Sogar Login Credentials waren dabei. Ob das seitens Big-Blue als "Bug" oder "Feature" geführt wurde kann ich nicht beurteilen.

[MSfree]

Mit apt geht es schneller und zuverlässiger

... und wenn es jemand gelingt, in die Repositoryserver verseuchte Softwarepakete einzuschleusen, hat man dann auch ganz schnell und zuverlässig Malware auf seinem Rechner. Es ist zwar schon lange her, aber auch das Debianrepository war schonmal kompromitiert (2003).

Auch im Sourcecode des Linuxkernels wurde bereits Schadcode eingeschleust.

Man kann sich zwar hinstellen und hämisch grinsen, daß es Ubuntu erwischt hat, aber Schadcode in Snappacks oder Flatpacks lassen sich auch unter Debian nicht ausschließen. Man kann die angebotenen Softwarepakete nur ständig kontrollieren und auf Anzeichen von Schadcode kontrollieren, was dann der Katz- und Mausjagd mit einem Virenscanner unter Windows entspricht. Zu behaupten, das könne unter Debian nicht passieren, wäre aber sehr vermessen.

[TRex]

NIcht ohne Grund laufen die Dinos auch heute noch da, wo es wirklich drauf ankommt.

Debian?

[Nice]

@MSfree:

... und wenn es jemand gelingt, in die Repositoryserver verseuchte Softwarepakete einzuschleusen, hat man dann auch ganz schnell und zuverlässig Malware auf seinem Rechner. Es ist zwar schon lange her, aber auch das Debianrepository war schonmal kompromitiert (2003)

Unsinn. Meinen Rat "think" hast Du leider nicht befolgt.
Es geht doch nicht um absolute Bedingungen, sondern um Wahrscheinlichkeiten.
Und von daher ist eine offizielle Debian-Paketquelle um Einiges sicherer als ein Hinz-und-Kunz-freies-Snap.

[MSfree]

Zuverlässig heißt aber nicht unbedingt, dass es da keine Sicherheitslücken gab; ich bin mal zufällig in den 80er Jahren darauf gestoßen, als ich einen Tippfehler bei einem Dateinamen machte und plötzlich Fragmente von anderen Dateiüberresten aus ganz anderen Anwendungen zu sehen bekam:

Wer kennt noch den Klassiker schlechthin? Die Sicherheitslücke im Unix vi, bei der man über die Sicherheitskopie des editierten Doks, ein mit Rootrechten ausführbares Executable machen konnte?

An der Uni sollte ich vor vielen Jahren mal Software auf eine SGI-Kiste installieren, was natürlich root-Rechte benötigt, um in die betreffenden Verzeichnisse schreiben zu können. Das Paßwort wußte aber nur einer, der gerade für 6 Wochen in den Urlab gefahren war, und die Aktion sollte so schnell wie möglich durchgeführt werden. Mit der Irix Installations-CD konnte man in den Single-User-Modus booten und damit das Rootpaßwort neu setzen. Der Admin, den ich mir zur Sicherheit geschnappt habe, der mir dabei über die Schulter geschaut hat, war ganz baff, daß ich die Kiste innerhalb von 30 Sekunden geknackt habe, ohne wirklich Lücken und andere fiese Tricks auszunutzen.

[DeletedUserReAsG]

Zu behaupten, das könne unter Debian nicht passieren, wäre aber sehr vermessen.

Sofern man keine Fremdquellen nutzt, ist die Wahrscheinlichkeit aber ungleich geringer, als wenn man sich Kram von $irgendwoher drauftut. Und wenn man sich Kram von $irgendwoher drauftut, ist’s halt egal, ob man Installscripte oder Binaries oder neumodische Fatpacks von irgendwelchen Seiten oder „Shops” lädt, in denen jeder Kram hochschieben kann, oder Repos von irgendwelchen Leuten einbindet, die einem dann auch vorsetzen können, was sie wollen.

Mit der Irix Installations-CD konnte man in den Single-User-Modus booten und damit das Rootpaßwort neu setzen.

Nun ja, das kann man mit jedem (unverschlüsselten) Linuxsystem genauso machen.

[Nice]

@niemand:
Auch hier wieder (leider ) von mir ein für Deinen Post.
MSfree scheint absolute Forderungen von signifikanten Wahrscheinlichkeiten nicht unterscheiden zu können.
Wenn man so denkt, nivelliert man völlig unpragmatisch sämtliche bedeutungsvollen Unterschiede,

[MSfree]

MSfree scheint absolute Forderungen von Wahrscheinlichkeiten nicht unterscheiden zu können.

Ich glaube, ich kann ganz gut mit Wahrscheinlichkeiten und Statistik umgehen

Die Tatsache, daß das Debianrepo besser kontrolliert und abgesichert ist, bedeutet nur eine geringere Wahrscheinlichkeit, daß es einen erwischt. Eine Wahrscheinlichkeit, die nicht Null ist, bedeutet nunmal, daß es auch Debian möglicherweise erwischen kann. Und wenn es Debian dann doch erwischt, nützt einem eine Wahrscheinlichkeit von eins zu 100 Millionen nichts, wenn die Schadsoftware auf dem eigenen Rechner hockt.

In diesem unwahrscheinlichen Fall werde ich mir dann im Ubuntuforum die Debianhäme mit einem Eimer Popcorn bewaffnet durchlesen.

[Nice]

@MSfree:

Ich glaube, ich kann ganz gut mit Wahrscheinlichkeiten und Statistik umgehen.

Nicht mit dem, was Du hier im Thread schreibst.

Beispiel:

Eine Wahrscheinlichkeit, die nicht Null ist

... gibt es fast nie.
Solch ein Ansinnen - ich wiederhole mich - nivelliert alle Versuche verantwortlichen Handelns.

P.S,:
Auch Sprüche wie "Popkorn", "AluHut" etc. sind in diesem Zusammenhang Tinnef.

[TomL]

Wer kennt heute noch CICS 3270-Terminals, TSO VTAM usw.

Ich...habe ich auch mit gearbeitet...lang ist's her....

Ich auch... Roscoe... *ööörks*... mannomann... sind wir schon alt... ... ...

[KP97]

CICS runterfahren...Band einhängen...Backup machen...
Wir sind alt...und OT...

[breakthewall]

... und wenn es jemand gelingt, in die Repositoryserver verseuchte Softwarepakete einzuschleusen, hat man dann auch ganz schnell und zuverlässig Malware auf seinem Rechner. Es ist zwar schon lange her, aber auch das Debianrepository war schonmal kompromitiert (2003).

Auch im Sourcecode des Linuxkernels wurde bereits Schadcode eingeschleust.

Sicherlich ist früher so einiges passiert, doch gerade unter Debian hat man seither sehr daraus gelernt. Das würde mich sehr wundern wenn das jemals wieder möglich sein sollte. Das hätte doch längst passieren müssen. Und dank starker Kryptographie und verteilten Git-Repositories, ist eine Manipulation am Linux-Kernel so ziemlich nutzlos. Das letzte Mal konnte das schnell und problemlos wiederhergestellt werden, und dann ging es auch schon zum Regelbetrieb über.

Man kann sich zwar hinstellen und hämisch grinsen, daß es Ubuntu erwischt hat, aber Schadcode in Snappacks oder Flatpacks lassen sich auch unter Debian nicht ausschließen. Man kann die angebotenen Softwarepakete nur ständig kontrollieren und auf Anzeichen von Schadcode kontrollieren, was dann der Katz- und Mausjagd mit einem Virenscanner unter Windows entspricht. Zu behaupten, das könne unter Debian nicht passieren, wäre aber sehr vermessen.

Nun ja es ist sehr auffällig wie oft sich Canonical in dieser Hinsicht präsentiert, wobei es nicht mal konkret um Ubuntu geht. Dennoch ein No-Go diese mangelnden Prüfungen im Snap-Store. Bei Flatpaks bzw. Flathub, stehen Upstream-Pakete im Vordergrund, und maßgeblich proprietäre Software aus bekannten Quellen. Da kann nicht einfach jeder ankommen und beliebige Flatpaks hochladen. Und davon abgesehen kann man Flatpaks auch direkt beziehen, wie man am Beispiel Gimp sieht.

Doch der Vergleich mit Windows hinkt dennoch stark, da hier weder zentrale Repositories existieren, noch einheitlich aktualisiert werden kann, noch auch nur irgendein Programm von Haus aus, stark mittels Sandboxing isoliert wird. Und läuft zudem noch Wayland im Hintergrund, dann können grafische Flatpaks noch besser isoliert werden, was es so unter Windows gar nicht gibt. Auch wenn man fairerweise sagen muss, dass die Situation unter Windows etwas besser ist, als unter einem X-Server unter GNU/Linux. Dennoch ist die Isolation grafischer Programme, unter allen Betriebssystemen gleichermaßen beschissen. Umso besser das sich das nun zum Teil verbessert.

Letztlich muss ich auch sagen, dass das Konzept der Snaps und Flatpaks an sich funktioniert, und auch schützt, doch Krypto-Miner sind wieder ein Fall für sich. Denn im eigentlichen Sinne ist das ja keine typische Schadsoftware, und greift ebenso intensiv auf Systemressourcen zu wie ein legitimes Programm. Die Frage ist wie man das vorab erkennt, und insbesondere ohne Quellcode je nachdem. Da muss auch der Nutzer mit arbeiten, indem nicht einfach Snaps/Flatpaks aus dubiosen Quellen, und von unbekannten Entwicklern bezogen werden. Andererseits muss man das alles auch nicht nutzen.

[breakthewall]

Die Tatsache, daß das Debianrepo besser kontrolliert und abgesichert ist, bedeutet nur eine geringere Wahrscheinlichkeit, daß es einen erwischt. Eine Wahrscheinlichkeit, die nicht Null ist, bedeutet nunmal, daß es auch Debian möglicherweise erwischen kann. Und wenn es Debian dann doch erwischt, nützt einem eine Wahrscheinlichkeit von eins zu 100 Millionen nichts, wenn die Schadsoftware auf dem eigenen Rechner hockt.

Richtig. Doch mindestens genauso wichtig sind erweiterte Sicherheitsmaßnahmen, anstatt sich nur darauf zu verlassen, dass seitens des Repository schon alles sauber ist. Nicht umsonst gibt es VMs, SELinux, AppArmor, Sandboxing in vielerlei Hinsicht, und Möglichkeiten auch Root einzuschränken. Hier und da kann es auch nicht schaden, eine Test-Installation zu haben, bevor man sich sein reales System mit Schadsoftware ruiniert. Anhand einer VM würde man schon sehen, wenn hier urplötzlich massiv Systemressourcen verbraucht werden. Und gegen Krypto-Miner im Browser, hilft ja bekanntlich NoScript und dergleichen.

[MSfree]

Doch der Vergleich mit Windows hinkt dennoch stark, da hier weder zentrale Repositories existieren, noch einheitlich aktualisiert werden kann, noch auch nur irgendein Programm von Haus aus, stark mittels Sandboxing isoliert wird.

Nunja, unter Windows hat es sich allgemein durchgesetzt, daß auf jedem Rechner ein "Wächter" (AKA Virenscanner) läuft, der aufpaßt, daß Schadsoftware sich gar nicht erst einnistet.

Wie sonst soll man denn Softwarepakete vor der Installation auf mögliche Schadsofteware untersuchen?

Die Debianantwort lautet halt: vertrau den Repositories und halte dich von Fremdsoftware fern.

Das erste Problem ist, daß man dabei den Debianrepositories vertrauen soll. Bisher ist wenig passiert und die Auswirkungen von kompromitierter Software waren gering. Aber auch der SSH-Fehler, der nur im Debianrepository aufgetreten ist (fehlende Entropie hatte die Zahl der generierbaren SSH-Schlüssel auf 65536 limitiert), war nicht ganz ohne, bis zur Entdeckung und Behebung ist damals gefährlich viel Zeit vergangen. Es kommt also nicht nur durch gezielte Angriffe zu Sicherheitslücken, auch Unfälle gibt es immer wieder, und dagegen helfen auch keine Virenwächter.

Das zweite Problem ist, daß man manchmal eben Software braucht, die nicht in den Repos ist. Natürlich sollte man jeder Software ein gesundes Maß an Mißtrauen entgegen bringen, und Software, die nur zur Unterhaltung dient, kann man in der Regel problemlos meiden. Wenn es aber um produktive Software geht, bleibt nur das Vertrauen, daß es schon gut gehen wird. Mit einem Virenscanner könnte man hier zumindest auf bekannte Schadsoftware testen, aber das ist eben ein Katz- und Mausspiel, das man letzten Endes nur verlieren kann.

Versteh mich nicht falsch, ich bin kein Befürworter von Virenscannern. Die Viren, die mich bisher unter Windows angreifen wollten, habe ich mit Brain 1.0 erkannt, wo der installierte Virenscanner noch tagelang ahnungslos war, bevor die Signaturupdates dann doch zu einer Erkennung geführt haben.

Und läuft zudem noch Wayland im Hintergrund, dann können grafische Flatpaks noch besser isoliert werden,

Isolation ist in diesem speziellen Fall eines Cryptominers aber ziemlich wirkungslos. Der Miner hat ja in der Regel gar nicht zum, Ziel, das System anzugreifen, der will "nur" Rechenkapazität stehlen und das klappt auch in der Isolation ganz gut. Hier hilft nur, daß Verhalten das System wirklich gut zu kennen und unerwartet hohe CPU/GPU-Last rechtzeitig zu erkennen und zu analysieren. Auf Servern, die auch ohne Schadsoftware am Lastlimit arbeiten, ist die zusätzlich Aktivität eine Miners aber nicht unbedingt einfach und schnell erkennbar, erstrecht, wenn der Miner sich geschickt tarnt.

Wie gesagt, mir gefällt die Häme nicht, die man Ubuntu gerade entgegen bringt. Wer im Glashaus sitzt, sollte im Dunkeln kacken.

[Nice]

@MSfree:

Wie gesagt, mir gefällt die Häme nicht, die man Ubuntu gerade entgegen bringt.

Kein Mensch hier im Thread hat irgendwie Häme gegenüber Ubuntu gezeigt...
Was schreibst Du nur für einen Unsinn.
Es ging um Snap und dessen schlechte Pflege/Qualitätssicherung.

[breakthewall]

Nunja, unter Windows hat es sich allgemein durchgesetzt, daß auf jedem Rechner ein "Wächter" (AKA Virenscanner) läuft, der aufpaßt, daß Schadsoftware sich gar nicht erst einnistet.

Das Antivirenprogramm das Windows mehrfach durch sehr ernste Sicherheitslücken in Bedrängnis brachte? Ich würde dem nicht vertrauen.

Wie sonst soll man denn Softwarepakete vor der Installation auf mögliche Schadsofteware untersuchen?

Die Debianantwort lautet halt: vertrau den Repositories und halte dich von Fremdsoftware fern.

Hier ist eben primär der Maintainer gefragt. Und unter Debian hätte man noch das Audit-Team, was insbesondere den Quellcode wichtiger und gefährdeter Pakete, mittels automatisierter Programme durchforstet. Ist zumindest ein Ansatz um Sicherheitslücken aufzudecken. Und was unliebsame Verhaltensweisen angeht, so ist der Zeitraum bis ein Paket das Stable-Repository erreicht ziemlich lange, womit vieles recht wahrscheinlich zuvor auffallen wird. Bislang scheint es zu funktionieren. Ansonsten kann der Nutzer selbst mit erweiterten Sicherheitsmaßnahmen arbeiten, um etwaige Probleme einzudämmen.

Aber auch der SSH-Fehler, der nur im Debianrepository aufgetreten ist (fehlende Entropie hatte die Zahl der generierbaren SSH-Schlüssel auf 65536 limitiert), war nicht ganz ohne, bis zur Entdeckung und Behebung ist damals gefährlich viel Zeit vergangen.

Selbst heute gibt es absurder Weise noch vereinzelte Systeme die dafür anfällig sind. Nur diese sind bei allem Verständnis selbst schuld, wenn man solange nicht aktualisiert bzw. Schlüssel wechselt. Aber das Problem zeigt auch deutlich, dass Kryptographie sehr komplex ist, und das es nicht ausreicht lediglich programmieren zu können. Denn Code kann noch so sauber und technisch fehlerfrei sein, und in kryptographischer Hinsicht dennoch katastrophale Auswirkungen haben.

Versteh mich nicht falsch, ich bin kein Befürworter von Virenscannern. Die Viren, die mich bisher unter Windows angreifen wollten, habe ich mit Brain 1.0 erkannt, wo der installierte Virenscanner noch tagelang ahnungslos war, bevor die Signaturupdates dann doch zu einer Erkennung geführt haben.

Wenn man unter Windows gewisse Regeln beachtet, kann man selbst hier weitestgehend frei von Schädlingen bleiben. Bin aber ohnehin ein Verfechter präventiver Sicherheitsmaßnahmen, da ich wenig Sinn darin sehe hinterher aufzuräumen, wenn das Antivirenprogramm mal wieder versagt hat.

[uname]

Nunja, unter Windows hat es sich allgemein durchgesetzt, daß auf jedem Rechner ein "Wächter" (AKA Virenscanner) läuft, der aufpaßt, daß Schadsoftware sich gar nicht erst einnistet.

Auf dem Client ist der Virenscanner doch nur notwendig, da die Softwarequelle (das ganze Internet) nicht ordentlich gescannt werden kann. Auch Windows versucht auf einen Store zu setzen. Debian und Ubuntu nutzen Repositories und auch Snap Store, Google Play und App Store sind Softwarequellen mit einen beschränkten Umfang von einigen Tausende Softwarepaketen. Somit reicht es wenn der Hersteller (z. B. Google beim Play Store) das Virenscanning durchführt. Niemand braucht einen dezentralen Virenscanner, wenn er nur aus "vertraulichen" Quellen installiert. Der eigene Virenscanner wird immer schlechter sein als die Bemühungen des Store-Betreibers.