Ventoy: Verdacht auf Malware #2

2020-12-232021-11-12 axt

Was bisher geschah…Click! (…derzeit sind es 10/60.)

Vor einer Stunde hat longpanda ventoy 1.0.31 auf den Server gelegt (releases).

Kurz: ventoy-1.0.31-linux.tar.gz geht auf virustotal.com momentan mit 0/60 durch, während bei ventoy-1.0.31-windows.zip 1/66 ausgegeben wird.

Ich habe den Programmierer angeschrieben gehabt…und schon nach der 3. eMail (mit Verweis auf zu verlierende Reputation) hat er geantwortet gehabt, auch relativ detailiert (es sind wohl 3 namentlich aufgeführte Binaries, die er hinzugenommen hat, ich habe mir das jetzt nicht nochmal vorgenommen).

Allerdings hat sich mein Eindruck dort verstärkt, daß er nicht weiß, daß es Unterschiede zwischen virustotal.com und dem Check irgendeines Scanners auf einem lokalen System gibt. So wiederholt er die Whitelist-Story (Dateien seien möglicherweise in Whitelists aufgenommen worden, deren Inhalt habe sich aber geändert, sprich es sind andere Dateien, da sie aber denselben Namen haben, wäre es ja klar, daß es false positives gibt – so ein Unsinn, vor allem wenn es 3 zusätzliche Files sind, wie er geschrieben hat).

ventoy ist ein hervorragendes Tool, keine Frage, aber sowas hinterläßt einen Nachgeschmack und sollte unbedingt beobachtet werden.

Weitere Checks ↓ werde ich hier keine listen, vorausgesetzt, es gibt keine neuen Funde. D.h., selbstverständlich habe ich das weiter auf dem Schirm.

2021-11-12: Es geht weiter…Ventoy: Verdacht auf Malware #3.

Ventoy: Verdacht auf Malware

2020-12-122021-11-12 axt

Bei einer heute erschienenen ventoy-Version erkennen 7 von 59 Scannern Malware. Bis auf einen gewissen Stamm wechseln Scanner stetig, es sind ~70 (und die haben mit Sicherheit nicht alle eigene Engines und kupfern eher von großen ab), es arbeiten aber quasi nie sämtliche zum Zeitpunkt des jeweiligen Scans, daher in diesem Fall nur 59.

Genauer gesagt ist es ventoy-1.0.30-linux.tar.gz. Frühere Versionen und (ausgerechnet) ventoy-1.0.30-windows.zip werden nicht bemängelt, also auch nicht jetzt mit erneutem Scan.

Nun muß man sowas zu werten wissen. Schon die unterschiedlichen Ausgaben, PUP und Trojan sind in ihrer möglichen Gefährdung ja nun nicht gleich zu bewerten.

So fällt auf, daß bestimmte hierzulande unbekannte oft chinesische Scanner offenbar aus Prinzip manche Software als maliziös deklarieren, wenn diese vermutlich dortiger Politik ein Dorn im Auge ist. Manche behandeln bestimmte Software auch als bösartig, nur weil man damit wie mit jedem Werkzeug auch schädliches/kriminelles anfangen kann.

Ein gutes Beispiel ist upx, ein sehr guter Packer für ausführbare Dateien. Signaturbasierte Scanner können so natürlich nichts mehr erkennen. Die erkennen aber upx-gepackte Dateien und deklarieren die kurzerhand als infiziert, was so selbstredend Unsinn ist.

Gerade mit upx 3.96 habe ich mir das näher angesehen, natürlich in einer abgeschotteten VM. Einige Versionen sind als clean durchgegangen, andere von immer gleichen (unbedeutenden) Scannern bemängelt worden. Die upx-Binaries selbst sind upx-gepackt. Die entpackt und schon hat nur noch ein Scanner detected. Weiße Bescheid.

Zur vollständigen Funktion wie Stift-/Fingerbedienung sog. elektronischer Tafeln (Beamer mit Tafeln oder auch große Touchscreen-PCs) muß zugehörige Software installiert werden. Dort habe ich es erlebt, daß direkt nach Anstoß der Installation (logischerweise alles original vom namhaften japanischen Hersteller) Files nicht mehr gefunden worden sind. Hm? Kaspersky Endpoint Security hat etwas erkannt und kurzerhand alles in Quarantäne geschoben. Auf virustotal.com gecheckt hat grausiges ergeben, knapp 40 Scanner haben angeschlagen gehabt und diesmal eben auch die großen wie Kaspersky.

Nachdem die deutsche Abteilung auf meine Anfrage nicht reagiert gehabt hat, habe ich den Support in Japan angeschrieben gehabt (mit Zaunspfahl, daß noch mehr Tafeln angeschafft werden sollen, eigentlich…von denen). Die haben sich genauso in Schweigen gehüllt, aber wie durch ein Wunder hat zwei Wochen darauf bei denselben Archiven nur noch eine Handvoll Scanner angeschlagen, sämtliche bedeutenden haben durchgewinkt. Man hat also reagiert und offenbar “false positives”-Erkennungen korrigiert.

Bei dieser ventoy-Version wissen wir’s noch nicht. Ich habe den Programmierer in China angeschrieben. Solange es keine Klärung gibt, sollte besagtes Archiv nicht verwendet werden. Die bisherige Version tut’s auch.

An der Stelle mal ein Lob an René Mach. Ich habe ihn August voriges Jahr wegen einer virustotal.com-Erkennung in TV-Browser angeschrieben gehabt. Er hat direkt und zeitnah geantwortet, er bzw. das Team haben verantwortungsvoll reagiert und die schon sehr lange bestehende externe und auch in vielen Java-Projekten anderer verwendete Komponente in TV-Browser entfernt.

2021-11-12: Es geht weiter: Ventoy: Verdacht auf Malware #3
2020-12-23: Siehe auch Ventoy: Verdacht auf Malware #2

CUPS: Drucker nicht mehr angezeigt

2020-11-242020-11-26 axt

Wenn seit etwa einer Woche (in Abhängigkeit, welche Distribution installiert ist, ob man in arch testing aktiviert und wann geupdatet hat) keine Drucker mehr als installiert angezeigt werden, fängt man nicht unlogisch an, die neu installieren zu wollen, auch cups nicht.

Mit CUPS als solchem liegt man jedoch nicht falsch, man checkt, ob der Service läuft:

$ systemctl status cups
● cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: ● cups.socket
       Docs: man:cupsd(8)

Also nicht, richtig vermutet. Kann man den Daemon mit

1	# systemctl start cups

starten, sprich funktioniert das Drucken wieder (aber nur für diese eine Session), weiß man schon mal, alles ist richtig installiert. Bis auf die Kleinigkeit, daß eben der Daemon nicht automatisch gestartet wird. Sieht man selbstverständlich bei Updates hin, sollte aufgefallen sein, daß sich kürzlich bzgl. cups etwas geändert hat. Man prüft in den Changes. Ab Zeile 190 “# rename the systems service files” wird man bestätigt, daß 5 Files “org.cups.cups*.*” in “/usr/lib/systemd/system/” umbenannt worden sind. Nun sollte man wissen, daß auf diese über Softlinks zugegriffen wird. Die zeigen aber auf nicht mehr existente Files.

Man sollte den Daemon nochmal stoppen, auch, um hernach gleich zu sehen, ob’s funktioniert hat:

1	# systemctl stop cups

Da man sauber arbeitet, löscht man zuerst die toten Links:

1	# systemctl disable org.cups.cupsd

Nun legt man die neuen Softlinks an:

1	# systemctl enable --now cups

Mit der Option “now” wird erreicht, daß das Gewünschte sofort aktiv ist, kein Reboot oder extra Start nötig.

Status-Check:

$ systemctl status cups
● cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2020-11-23 18:10:42 CET; 31s ago
TriggeredBy: ● cups.path
             ● cups.socket
       Docs: man:cupsd(8)
   Main PID: 859 (cupsd)
     Status: "Scheduler is running..."
(...)

Done.

doas, das kleine sudo

2020-10-282020-12-09 axt

sudo (Akronym für “substitute user do” und nicht falsch “superuser do”) sollte jeder Linux-User kennen, auch wenn der eine oder andere administrative Tätigkeiten vielleicht doch mit root-Account durchführt.

devil geht in seinem Blogpost auf doas (“do as”), adaptiert von OpenBSD, ein.

In den Debian-, Ubuntu-, Fedora-Repositories liegt es nicht, auch nicht in Ubuntu-PPAs, wohl aber als opendoas in den Arch-Repositories. Upstream-URL linkt auf einen Fork eines anderen seit Jahren nicht mehr angefaßten github-Repos. Beim Fork passiert seit 9 Monaten aber auch nichts mehr. Das muß die eine sagenumwobene Software sein, die absolut fehlerlos und nicht verbesserbar ist.

Wie auch immer, ich hab’s eben mal spaßeshalber (verwenden werde ich’s nicht) aus https://github.com/Duncaen/OpenDoas in einer noch herumliegenden LBionic-VM kompiliert, aber im letzten Schritt des bekannten “Dreisatzes” Ubuntu-typisch mit checkinstall statt “make install” (ist auch unter Debian möglich). So erhält man ein .deb-File.

Wer’s unter Ubuntu(-Derivaten)/Debian selbst ausprobieren möchte:

Installation zum Kompilieren nötiger Pakete:
1
sudo apt install build-essential checkinstall git byacc
sudo apt install build-essential checkinstall git byacc
Es ist darauf zu achten, tatsächlich byacc zu installieren, mit btyacc bricht make mit errors ab.
Clonen des Source Codes aus dem git-Repository mit der Tiefe 1:
1
git clone git://github.com/Duncaen/OpenDoas --depth 1
git clone git://github.com/Duncaen/OpenDoas --depth 1
Ins Verzeichnis wechseln:
1
cd OpenDoas/
cd OpenDoas/
Der “Dreisatz”:
1 2 3
./configure make -j2 sudo checkinstall -D --install=no --backup=no --maintainer=user --pkgname=opendoas
./configure make -j2 sudo checkinstall -D --install=no --backup=no --maintainer=user --pkgname=opendoas
“-j 2” steht für 2 dafür zu verwendende Kerne, man könnte stattdessen bspw. auch “-j $(nproc)” für saemtliche setzen oder die Option auch weglassen. Das Ganze hier ist aber dermaßen klein, da genügt auch ein “halber”. ;)

Gäbe es bereits ein Paket namens opendoas in der Distribution, sollte man das eigene anders benennen (z.B. mit einem kurzen Zusatz) oder eine höhere Version setzen. Das nur als generellen Nebenhinweis, falls man auch andere Pakete kompilieren will.
Installation:
1
sudo dpkg -i opendoas*.deb
sudo dpkg -i opendoas*.deb
Sich selbst bzw. den gerade eingeloggten User der Konfigurationsdatei hinzufügen:
1
echo "permit :$USER" | sudo tee /etc/doas.conf
echo "permit :$USER" | sudo tee /etc/doas.conf
Statt der Variable $USER kann man natürlich den Usernamen direkt einsetzen, auch einen anderen, der fürderhin doas-berechtigt sein soll.

Ein testweises “doas nano” funktioniert, manpage, sofern während der Kompilierung nicht abgewählt, auch:
1
man doas
man doas

arch: “-bash: append_path: command not found”

2020-10-272020-11-13 axt

Über ssh auf ein arch-basiertes System eingeloggt bringt folgende Ausgabe, ggf. auch mehrfach untereinander:

-bash: append_path: command not found

Check auf profile* in /etc:

/etc$ ls -la profile*
-rw-r--r-- 1 root root  811 Aug  6  2018 profile
-rw-r--r-- 1 root root 1020 Sep  3 00:30 profile.pacnew
 
profile.d:
(...)

Bei einer Aktualisierung ist ein neues profile geschrieben, aber sicherheitshalber unter verändertem Filename gespeichert worden. Dies sollte man vergleichen. Entscheidet man sich für die neue Konfiguration, ist profile zu löschen (oder meinetwegen zu sichern) und dann profile.pacnew in profile umzubenennen:

/etc$ sudo mv profile{,_old}
/etc$ sudo mv profile.pacnew profile

snap oder richtig

2020-10-262020-10-30 axt

Wie gesagt, als Stichwortgeber taugt jenes Forum noch…

Wer Ubuntu fährt, sollte aufpassen, welche Pakete bzw. woher er diese installiert. Bemängelt wird vom Hilfesuchenden, er fände keinen Download für das PlugIn, um aus gimp heraus xsane zu starten.

Nebenbei, unter arch ist es ein separates Paket namens xsane-gimp. Etwas in der Art gibt es in den Ubuntu-Repositories nicht (mehr), das Plugin jedoch noch sehr wohl. In Sekunden findet man heraus, es ist Bestandteil des Pakets xsane.

Nun behauptet er, sowohl gimp als auch xsane installiert zu haben. Das glaube ich ihm sogar, nur hat er sehr wahrscheinlich nicht die .deb-Pakete aus den Ubuntu-Repositories installiert. Ich meine dabei nicht vordergründig .deb aus Fremdquellen wie PPAs, sondern das unsägliche Canonical-Eigengewächs snap. Dieses Zeug integriert sich eben nicht ordentlich ins System, es ist nicht “nur” Gift für das Paketsystem, die Interaktion ist nicht wirklich gegeben. snap-Pakete sind Fremdkörper.

Also sprach Zarathustra:

sudo apt purge snapd

snap-Pakete fliegen damit ebenfalls ‘raus (sie würden ohne den Daemon ja auch nicht mehr laufen), entsprechende .deb-Pakete müssen bei Bedarf installiert werden.

Hier kommt der Ubuntu-User freilich an den Punkt, daß manche/immer mehr in Ubuntu gar nicht mehr angeboten werden (sollen), prominentes Beispiel seit 18.10 ist chromium, ausgerechnet. Canonical will das immer mehr umbauen. Ubuntu? Auch andere Mütter haben schöne Linux-Töchter. Oder sagen wir besser schönere, keine absichtlich mißgestalteten. Und auch nicht solche alten (gimp in Ubuntu 20.04 “LTS” und dem gerade erst erschienenen 20.10 → 2.10.18, aktuell ist seit 3 Wochen 2.10.22, das wird in releaseten Ubuntu-Versionen auch nicht hochgehievt).

Btw., es gibt auch kein Paket “xsane-doc”, die doc-Files liegen als .html im Paket xsane-common (unter arch im Paket xsane), das bei der Installation von xsane automatisch als Abhängigkeit mitinstalliert wird. Einfach mal selbst suchen, statt vorsetzen lassen wollen. Unter Linux setze ich das voraus.

Nachtrag 2020-10-29: Eben noch mal obig verlinkten Forum-Thread gecheckt, was da so den Tag nach meinem Blogpost geschrieben worden ist. Tja, sag ich doch. ]:-)

Ventoy: mehrere Images auf USB-Stick

2020-10-012020-12-12 axt

Um .iso-Files, gemeint hier Installations-Images, boot-fähig auf USB-Sticks zu ziehen, benötigt man ein entsprechendes Tool.

Unter Linux ist und bleibt das dd (auch, wenn es nicht für jedes Image verwendet werden kann und hinterher der Stick für normale Nutzung erstmal wieder “geputzt” werden muß).

UNetbootin sollte man wie die meisten anderen Tools dieser Art nicht verwenden, das verändert unübersehbar.

Ein recht neues Tool ganz anderer Arbeitsweise ist Ventoy (chin.), ein Spitzending. Es richtet auf einem Stick 2 Partitions ein, eine zum Booten, eine, auf die .iso-Files simpel kopiert werden können (exFAT für Kompatibilität und > 4-GiB-Files), soviele, wie jeweils Platz ist.

Das reine Kopieren solcher Images geht allein schon sehr viel schneller als das Flashen immer nur eines Images auf einen Stick. Enorme Zeit- und Platzersparnis.

Bei den häufigen Ventoy-Updates wird stets nur auf die Bootpartition geschrieben, die Images-Partition wird nicht angetastet. Ist man gezwungen, das unter Redmond OS zu machen, sollte man tunlichst solches im Hintergrund automatisch laufendes Zeug, das ungewolltes Überschreiben von Bootblocks verhindern soll, beenden, sonst wird der Stick (erstmal) geschrottet (das zu beheben, braucht es Wissen und Zeit und spätestens dann Linux, tja).

Da (Sub-)Directories unterstützt werden, kann man der Ordnung halber ein Verzeichnis iso erstellen, Images darin ablegen. So kann man weiteren Platz in einem anderen Verzeichnis für zusätzliche Files nutzen (z.B. kumulative Updates, wenn man auch solche…Betriebssysteme installieren muß).

Im übrigen habe ich über Ventoy gebootet kürzlich mit einem Hybrid-Image eines älteren FTS-Mainboards dessen UEFI geflasht (ob man solcherlei riskiert, muß man natürlich selbst abwägen).

2020-12-12: Ventoy: Verdacht auf Malware

arch: qbittorrent startet nicht

2020-09-212020-09-23 axt

Wer arch/testing aktiviert hat, kann derzeit qbittorrent nicht nutzen. Wenn scheinbar nichts passiert, ruft man ein Programm in einem Terminal auf und erhält in diesem Fall folgendes:

$ qbittorrent 
qbittorrent: symbol lookup error: qbittorrent: undefined symbol: (...)

Über einen Bugreport kommt man zum Hintergrund und findet auch eine Diskussion dazu. Bis die eigentliche Ursache behoben ist, kann man sich mit einem Workaround behelfen: man installiert die derzeitige Version aus stable (oder man nutzt transmission).

$ sudo pacman -S "libtorrent-rasterbar=1:1.2.8-1"
[sudo] password for axt: 
warning: downgrading package libtorrent-rasterbar (1:1.2.10-1 => 1:1.2.8-1)
(...)

Damit die nächste Aktualisierung das nicht gleich wieder zunichte macht, muß man das Paket auf hold setzen:

$ sudo nano /etc/pacman.conf

Hier fügt man “libtorrent-rasterbar” hinzu:

IgnorePkg   = libtorrent-rasterbar

Probe auf’s Exempel:

$ sudo pacman -Syyu
(...)
:: Starting full system upgrade...
warning: libtorrent-rasterbar: ignoring package upgrade (1:1.2.8-1 => 1:1.2.10-1)
 there is nothing to do

Vergessen kann man’s so nicht. Man sollte die Sache natürlich im Auge behalten, d.h., bei einem Fix das Paket wieder auf unhold setzen.

Update 2020-09-23: “1:1.2.10-2” enthält einen Fix, funktioniert → libtorrent-rasterbar wieder aus IgnorePkg entfernen!

Ubuntu: snap verhindern

2020-06-162020-06-17 axt

Von Anbeginn bedient sich Linux Mint an Ubuntu (Mint-User faseln seit jeher etwas von “dem besseren Ubuntu”, um zeitgleich in ubuntuusers.de Support zu verlangen, was entsprechende Sympathiewerte…einbringt).

Man könnte sagen, endlich gibt Mint Ubuntu nun etwas zurück, ungewollt und indirekt.

Der Reihe nach. Mint sperrt die Installation von Paketen des unsäglichen Canonical-Eigengewächses snap, indem der Daemon snapd nicht nur nicht vorinstalliert ist, sondern dessen Installation verhindert wird. Diverse Websites wollen nun ausgerechnet diese positive Entscheidung aushebeln, indem sie groß und breit erklären, wie man eine bestimmte Datei löscht. Meine Güte!

So versteigt sich omg!ubuntu in “Nemo as a super user”, um dort das File zu löschen. Ein grafischer Filemanager mit root-Rechten wird dann auch noch als “the good ol’ fashioned way”, die gute altmodische Art, verkauft.

Was steht nun drin und kann man’s nicht erst recht in Ubuntu(-Derivaten) setzen?

Mit einem Editor schreibt man in ein File “/etc/apt/preferences.d/nosnap.pref”:

Package:	snapd
Pin:		release a=*
Pin-Priority:	-10

Mit “sudo apt purge snapd” wird der Daemon gepurget, mit “sudo apt update” aktualisiert man Paketquellen und Paketquelleninhalte.

Sollte man nun snapd wieder installieren wollen, pff, meldet z.B. synaptic unerfüllte Abhängigkeiten, apt erzählt dagegen etwas von “E: Package ‘snapd’ has no installation candidate”.

Über die Nachteile dieses snap-Craps, das wie andere dieser gegenseitig konkurrierenden App-Systeme bestehende Linux-Paket-Management-Systeme konterkariert, muß man sich nicht mehr groß auslassen. In Foren fällt auf, daß unbedarfte User gar nicht merken, ob sie da gerade ein .deb oder so einen Müll, der sich auch nicht sauber ins System integriert, sprich nicht oder nicht vollständig mit anderer Software interagiert, installieren. Fällt bei fehlendem snapd flach.

Das Wesentliche, was dann unter Ubuntu nicht mehr installiert werden kann, weil es schlicht für nach 18.04 nicht mehr in den Repositories liegt (mit fadenscheiniger Begründung seitens Canonicals), ist freilich chromium. Man könnte in den sauren closed-source-Apfel beißen und chrome installieren…oder einfach zu einer vernünftigen Linux-Distribution greifen.

Neo2 unter Xubuntu

2020-06-112020-06-17 axt

Man (also ich, grin) löst bekanntlich gern IT-Probleme anderer. Als Stichwortgeber dazu kann uude sehr vereinzelt noch herhalten (dessen Forum ist ansonsten längst nicht mehr auf absteigendem Ast, sondern schlichtweg im Loch, muß nur noch wer zuschaufeln, das einstmals gute Wiki verödet auch nur noch).

Ein User kann das sehr spezielle Keyboard-Layout Neo2 unter Xubuntu 20.04 nicht laden, weder live noch im installierten System. Bereits für XBionic hat er dazumal einen Bugreport verfaßt gehabt.

axebase.net

Rechner sind viel zu schnell viel zu langsam.

Category: linux