Category Archives: Linux

Linux Praxis: Remote Desktop Protokoll

Posted on by

Da ich kürzlich Gelegenheit bekam per Fernwartung in einer Firma mit Windowsclienten zu arbeiten, möchte ich Euch viel unnötiges Gesuche darüber ersparen, was geht und was nicht geht.

Windows 10 und RDP

Zunächst einmal, es geht um Windows 10 und dessen RDP Service. Das man den nicht einfach ins Netz exponieren kann, weil der PC sonst binnen Sekunden gehackt wird, sollte jedem spätestens seit BlueKeep und dessen Nachfolger, der sich gleich wurmartig fortpflanzen konnte, klar sein.

Wie macht man das jetzt, wenn man keine teure Firewalllösung einkaufen möchte, die dann vielleicht selbst zur ungepatchten Schwachstelle wird ( so wie die F5 ) oder nicht schnell genug die Signaturen aktualisiert?

Linux ist die Rettung

Man nehme ein gescheites Linux (Centos LTS mit Autoupdate würde reichen), und stellt es ins Intranet. Der SSH Port wird über DSL-Router nach außen exponiert, idealerweise nicht Port 22, was die Anzahl der Scans reduziert, und fail2ban-ed dann noch gleich die BruteForceangriffe weg 😉 . Das man den Zugriff nur per >=4K-SSH-Schlüssel und nicht mehr per PAM ( Passwort ) zulässt dürfte selbstverständlich sein, oder muß ich das extra erwähnen? 🙂

Wenn man Linux auch als Desktop hat, ist es jetzt ganz leicht den RDP Port des Windowszielrechners im Intranet auf 127.0.0.1 zu forwarden:

ssh -C -L 3389:192.168.178.33:3389 root@externe.dsl.ip

Kleiner Pro Tip: „-C“ nicht vergessen, dann komprimiert SSH die Daten zusätzlich noch, was gerade bei langsamen Verbindungen von Vorteil sein wird. Durch SSH wird die Verbindung über das Netz komplett verschlüsselt.

Wie verbindet man sich jetzt zu seinem mit TLS gesicherten RDP Service?

Jetzt kommen wir zum eigentlichen Problem mit Linux als RDP Clienten: kaum ein RDP Client taugt was.

Die kurze Liste der RDP Clienten unter Fedora lautet: RDesktop, gnome-rdp aka Vinagre und freerdp

RDesktop und Vinagre kann man gleich löschen. Der RDP Client der Wahl ist FreeRDP! Das ist nämlich der einzige, der überhaupt funktioniert. Vinagre baut zwar eine Verbindung auf, liefert aber nur ein Schwarzbild ab => fail. RDesktop war nicht mal dazu in der Lage.

FreeRDP hat neue Optionen

Im Netz findet man z.b. im Ubuntu-Forum Hinweise wie man FreeRDP erzählt, wo es hin soll und wie groß der Bildschirm sein. Leider muß man das angeben, sonst gibt es die Defaultwindowssession mit 1280×1024 😀 Das hatten wir dann auf dem 3k Display vom meinem Surface Pro als kleines Icon irgendwo in der Ecke vom Bildschirm liegen 😉 Ok,ok, Icongröße hatte es nicht ganz, aber da FreeRDP nicht DPI-Scaleaware ist, mußte man halt eine Lupe benutzen.

FreeRDP scheint seine CLI-Optionen umstrukturiert zu haben und man muß statt mit „-“ mit „/“ arbeiten. Beispiel: /size:WxH. Ob die sich an die Windows-DOSshell anwanzen wollten, wer weiß …

Windows failed beim DPI-Scaling

Es bliebt einem nichts anderes übrig als FreeRDP zu sagen, wie groß das Fenster denn sein soll, damit man dann einen größeren Font im Windows einstellen kann. Ab da wird es dann peinlich für M$, denn das DPI-Scaling funktioniert nur bei realen Bildschirmen, nicht bei Remote-Zugriffen per RDP 😀 Allen Versuchen zum Trotz blieb das Fenster ohne DPI-Scaling, auch als Windows behauptet hat, es würde 500%! skalieren 😉 Lustigerweise warnt einen Windows, daß es kein Vergnügen sein wird, ein 500% skaliertes Windows zu benutzen. Ich wäre schon froh über 200% gewesen 😀

Wenn man auf dem Windowsystem jetzt mit Browsern arbeiten muß, ist die Lösung denkbar einfach: das Browserfenster zoomen. Bei richtigen Anwendungen geht das natürlich nicht, was das Arbeiten auf einem 3k-4K Display nicht gerade vergnüglich macht. Da hilft es nur einen kleineren Bildschirm zu benutzen. Für ein FullHD Display könnte die Anweisung an FreeRDP so lauten:

xfreerdp /u:username /v:127.0.0.1 /size:1920×1020

Damit ist das Fenster brauchbar in Cinnamon eingefasst. Da wir glücklicherweise zwei HighSpeed-DSL Anschlüsse nutzen, ist die Latenz der Pakete sehr niedrig und das Arbeiten ist (bislang) angenehm.

Windows ist in dem Szenario leider nicht das einzige Programm, das failed. FreeRDP müßte das Scaling eigentlich auch automatisch beachten. FreeRDP bietet als Optionen jetzt einen Scalingparameter an, leider funktioniert auch das nicht sofort.

xfreerdp /u:username /v:hostname /size:1920×1080 /scale:140 /scale-desktop:200

Obiges bringt dann die Lösung. Damit läßt sich der Desktop uns seine Anwendungen auch auf 3k/4K besser lesen. Offensichtlich muß man Windows erst von außen sagen, das es skalieren soll, interne Einstellungen zählen halt nicht.

Für FreeRDP gibt es übrigens noch die Rocket-GUI, so muß man nicht alles in der Bash machen. Allerdings ist das Programm recht simple und wird nicht allen Anforderungen an unser spezielles Problem gerecht.

Aus Gnome MPV wurde Celluloid

Posted on by

„Ins Hirn geschissen“ würden Bayern wohl zurecht sagen, wenn Sie von dem neuesten Streich wüßten, der die GTK Gui von MPV erwischt hat.

Aus GNOME MPV wurde Celluloid

Da über den Namenswechsel kaum berichtet wurde, und Google hat sich wirklich ins Zeug gelegt was zu finden, ist es jetzt auch leider zu spät sich dazu zu melden. Trotzdem soll nicht unerwähnt bleiben warum denn der Name geändert wurde:

Weil „GNOME MPV“ ein wenig uninformativ ist, wie GNOME Entwickler Tobias Bernard erklärt:

„Der aktuelle Name ist etwas unelegant und passt nicht wirklich zu anderen Anwendungen auf der GNOME-Plattform. Gute App-Namen sind in der Regel ein einzelnes Substantiv, das mit der Domäne der App zusammenhängt (z.B. „Fragments“ für eine Torrent-App oder „Peek“ für einen Bildschirmrekorder).

Also alleine schon die Auflistung der Beispiele ist ja wohl an den Haaren herbei gezogen! „Torrento“ wäre ein passender Name für eine Torrent-App, aber doch nicht „Fragments“. „Peek“, was soll das bitte sein? „to peek“ meint in der Übersetzung „gucken“, „spähen“, „nachsehen“, aber doch keinen Bildschirmrekorder.

Der alte Name „GNOME MPV“ macht genau das, was angeblich gefordert ist, er beschreibt was es ist: Eine Gnomeversion von MPV. Geht es eigentlich noch besser?

eine Rasenfläche mit Häusern

Um den hier gehts!

Also: Wieso nur?

Über die wahren Gründe kann ich nur spekulieren, aber die Assoziation „Celluloid/Zelluloid“ mit Film, Popkorn und „Rahmen“ ( kannste Dir nicht ausdenken sowas s.u. ) dürfte heutzutage hinken. Wo gibt es denn noch Kinos die analoge Projektoren haben? Im Museumsdorf? Wie alt muß man bitte sein um bei „Film ansehen“ als erstes an durchsichtige Plastikstreifen mit lustigen Bildern drauf und ein Mais-Butter-Komglumerat zu denken?

Ich habe dazu die „Diskussion“ dazu gefunden: https://github.com/celluloid-player/celluloid/issues/353

Wie jemand woanders meinte, könnte Celluloid als Name allein deswegen genommen worden sein, weil alles andere schon belegt war. Das fällt einem sehr schnell auf die Füße, wenn man doppelte Appnamen hat.

Wenn man sich die „Diskussion“ oben mal durchliest, merkt man gleich, daß das nur eine Handvoll Leute entschieden hat. Wenn die sich mal in 1-2 Jahren nicht wünschen werden, daß sie das mal lieber gelassen hätten. Wer jetzt nach MPV sucht, stolpert jedenfalls nicht mehr so leicht über den Player und wer RPMFusion aktiviert hat, wird eh nur leicht irritiert drein schauen und dann nur das reine MPV installieren.

Gesagt – Getan 🙂

Diese Arbeitshypothese habe ich gleich mal getested und dabei gesehen, daß das gnome-mpv Paket noch bei „dnf search mpv“ gefunden wird, weil es vermutlich als Baserpm noch im Repo vorhanden ist. Dabei fiel mir aber auch ein neuer Videoplayer auf MPV Basis auf : deepin-movie. Leider könnt Ihr Euch die Installation schenken, weil:

[marius@eve ~]$ deepin-movie
deepin-movie: symbol lookup error: deepin-movie: undefined symbol: _ZN3Dtk6Widget9DTitlebar7setIconERK7QPixmap

Da passen wohl das exe und die referenzierten Libs nicht ganz zueinander.

Kleiner Rework gefällig?

Wenn man GNOME MPV wieder als Namen haben will, kann sich entweder eine eigene DesktopDatei nach Schreibtisch kopieren oder gleich die systemweite Desktpdatei anpassen:

[marius@eve ~]$ cat /usr/share/applications/io.github.celluloid_player.Celluloid.desktop 
[Desktop Entry]
Version=1.0
Name[bg]=Gnome MPV
Name[ca]=Gnome MPV
Name[cs]=Gnome MPV
Name[da]=Gnome MPV
Name[de_DE]=Gnome MPV
Name[eo]=Celuloido
Name[es]=Gnome MPV
Name[fr]=Gnome MPV
Name[hr]=Gnome MPV
Name[hu]=Gnome MPV
Name[it]=Gnome MPV
Name[ja]=Gnome MPV
Name[nl]=Gnome MPV
Name[pl]=Gnome MPV
Name[pt_BR]=Gnome MPV
Name[pt_PT]=Gnome MPV
Name[ro]=Gnome MPV
Name[ru]=Gnome MPV
Name[sr]=Gnome MPV
Name[sr@latin]=Gnome MPV
Name[sv]=Gnome MPV
Name[tr]=Gnome MPV
Name[zh_CN]=Gnome MPV
Name[zh_TW]=Gnome MPV
Name=Gnome MPV
...

Ein paar Sekunden nachdem Speichern der Änderungen, aktualisiert sich das Menü und alle Appnamen in Nemo und Nautilus. Bis auf den „Celluloid“ Namen im Fensterrahmen, wärs damit erstmal wieder in grünen Bereich 😉

In dem Sinne: gute Nacht.

KDE-Desktop: RCE Schwachstelle durch .desktop Dateien

Posted on by

Wie die Hacker News heute morgen berichten, ist im KDE 4/5 Plasma Desktop eine Schwachstelle enthalten, die durch das reine Herunterladen von manipulierten Desktopdateien ( erkennbar an den Endungen .desktop und .directory)  ausgelöst werden kann.

Schwachstelle im KDE Desktop Indexer für Plasma

Die Ursache liegt im unsicheren Indexer, der neue Dateien analysiert und für die Suchfunktion des Desktops aufbereitet.

Dabei werden Umgebungsvariablen aus der analysierten Datei übernommen, was dazu führt, daß ein Angreifer seinen Schadcode ausführen kann. Auch das Auspacken von Archiven triggert den Indexer an, so daß auch dies die Schwachstelle auslöst.

Securityforscher Dominik Penner, der die Lücke direkt an die Hacker News geschickt hat, statt sie dem KDE Security Team zu senden, schreibt dazu:

„When a .desktop or .directory file is instantiated, it unsafely evaluates environment variables and shell expansions using KConfigPrivate::expandString() via the KConfigGroup::readEntry() function,“ Penner said.

„Wenn eine .desktop oder .directory Datei instanziiert wird ( A.d.R.: muß wohl gelesen heißen ), werden auf unsichere Weise Umgebungsvariablen und Shellerweiterungen ausgewertet, in dem die Funktion KConfigPrivate::expandString() via KConfigGroup::readEntry() genutzt wird“ schreibt Penner.

Diese Schwachstelle erinnert extrem stark an die kürzlich gefundenen Schwachstellen in Exim, wo auch die  Inhalte von fremdeingelieferten Strings ausgewertet werden und zu einem Root-Exploit eskalieren.

Bis auf weiteres muß man bei Downloads und dem Auspacken von aus unbekannten/unsicheren Quellen stammenden Archiven extrem vorsichtig sein. Das KDE Team hat einen Patch angekündigt, fertig ist der aber noch nicht.

Wenn ich mich recht entsinne, hatte der Gnome Index auch kürzlich erst so eine Schwachstelle.

Kleines Update: (10:24 Uhr)

Es gibt ein Youtube Video, daß das Problem zeigt. Allerdings wird man als unbedarft neugieriger erstmal unverständlich davor sitzen. Daher möchte ich dazu eine kleine Einleitung geben:

In dem Shellfenster rechts startet Penner „nc -lp 31337“  ( 31337 = „elite“ in L33T-Speak 🙂 ). nc startet also einen Dämon und wartet auf Verbindungen. Plötzlich wird nc beendet und wirft eine Fehlermeldung aus. Das liegt daran, daß das Desktopfile, daß per Firefox runtergeladen wird, sich bzw. ein dadurch gestartetes anderes Programm zu besagtem Port 31337 verbindet.

Das zusammen demonstriert das Problem. Man kann in den Desktopdateien natürlich auch „rm -rf /“ unterbringen, oder den Download von Illegalem Filmmaterial starten.