RIP: Runes of Magic

Tja, Game Forge hat es endlich geschafft. Nichts geht mehr. Der heute in Betrieb genommene neue „Launcher“ stellt zwar Behauptungen auf, kann aber das eigentliche Spiel nicht mehr starten.

RIP: Runes of Magic

Damit ist das Spiel für Linux dann wohl endgültig gestorben. Da der neue Launcher keine Vorteile für Spieler hat, außer das alles länger dauert, gibt es für dessen Existenz keine Berechtigung. Das stört Game Forge allerdings nicht.Schade um die 100kk im AH, aber das wars dann wohl endgültig. Ich glaube nicht, daß sich ROM 4 Linux davon nochmal erholen wird 🙁

Exim: neue mögliche RCE Schwachstelle gefunden

Toller Sonntag. Überall Regen und dann weckt mich noch die Meldung, das im Exim eine neue, nicht abwehrbare Schwachstelle gefunden wurde 🙁 ( wichtiges 13 Uhr Update unten )

Elysium ist gefallen

Es gibt einen neuen Bug, der auch bereits gefixt wurde, aber leider nicht mit einem Workaround abzuwehren geht. Das bedeutet für Euch, daß Ihr Updaten müßt.

Der Fehler liegt in einem Programmierfehler der Stringverarbeitung, die dummerweise bereits beim HELO/EHLO greift. Ein Angreifer kann einen Heap-overflow auslösen, in dem er einen überlangen ELHO String sendet.

An der Stelle des Codes wurden die Rootrechte zwar schon gedroppt, aber das hilft nur wenig, falls der Angreifer tatsächlich einen RCE hinbekommt, was nicht ausdrücklich ausgeschlossen ist, aber auch nicht 100% bestätigt wurde. Daher muß man davon ausgehen, daß es jemand früher oder später schafft: Worst-Case halt.

Betroffen sind alle Versionen < 4.92.3.

Also entweder Ihr patchted Euren alten Exim selbst, oder Ihr updated auf die neue Version. Eure Entscheidung.

Aktuelle CVE Nummer zu dem Exim RCE : CVE-2019-16928 .
(Passage geändert, vorher keine bekannt gewesen.)

13 Uhr Update

Fedora kompilierte Versionen sind nicht angreifbar. Der Exploit funktioniert einfach nicht.

Getestet auf: Fedora 29 64Bit gegen 4.92.2

Andere Distros könnten angreifbar sein. Es hängt auch ein bisschen damit zusammen, wie das angegriffene System konfiguriert ist. „Eylsium ist gefallen“ ziehe ich damit teilweise zurück .. das Fedosium steht noch :DDD

Der Exploitstring ist übrigens 11k lang, nur falls Ihr das bei euch mal selbst ausprobieren wollt, nehmt gleich 12k.

Außerdem wurde mitgeteilt, daß es im Rahmen der 4.92.x eingeführt wurde und mit 4.93 auch schon wieder draußen war. Die Exploitmeldung war leider etwas hastig formuliert worden. Allerdings sehe ich da keinen Schaden drin, weil „besser safe than sorry“ wie der Denglischer sagt 😉

 

OMG des Tages: Fulldisclosure ML bietet kein TLS an

Nicht das man es brauchen würde, aber in 2019 darf man doch von einer Securityliste erwarten, daß deren Mailserver TLS kann, oder? Nicht so bei NMAP.

seclists.org Mailserver bietet kein TLS an

Gerade wollte ich das Duplicator Pro Advisory an die  FullDisclosure Mailingliste schicken, da mault doch glatt mein Mailserver, daß er die Mail nicht schicken könnte, weil der Empfänger TLS verweigert. Ein OMG war die Folge:

CheckTLS Confidence Factor for „fulldisclosure@seclists.org“: 0

MX ServerPrefAnswerConnectHELOTLSCertSecureFrom
ack.nmap.org
[45.33.49.119:25]
0OK
(69ms)
OK
(151ms)
OK
(68ms)
FAILFAILFAILOK
(357ms)

2019-09-27 21:23:52 1iDvqI-0005NU-Mw == fulldisclosure@seclists.org R=dnslookup T=remote_smtp defer (-38) H=ack.nmap.org [45.33.49.119]: a TLS session is required, but the server did not offer TLS support

Jetzt braucht man natürlich keine Verschlüsslung, wenn eh an eine öffentliche Mailingliste Veröffentlichungen schickt, aber da laufen auch private Mailinglisten drüber z.b. über Bugs in NMAP und die sollten ja wohl verschlüsselt ankommen, oder?

Es kommt mir so bekannt vor…

Besonders prekär für die Admins des NMAP Mailservers ist der Umstand, daß deren Mailserver sehr wohl TLS beim Senden von Emails kann, sonst kämen die Emails nicht bei uns an:

2019-09-26 08:54:08 1iDNfD-00060F-Mj <= fulldisclosure-bounces@seclists.org H=ack.nmap.org [45.33.49.119] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=21878 id=6e00195f-664f-1d1c-0fb6-1333992ad574@sec-consult.com

Die große Ähnlichkeit zum BSI CERT-Bund Mailserver macht es natürlich nicht besser: BSI aktualisiert Mailserver auf TLS 1.2.. ABER .

Ich seh schon, mit dem TLS Gate habe ich noch auf Jahre jede Menge Spaß fürs Blog 😀

Hinweis: Duplicator Pro <= 1.3.14 hat eine fiese IFDC Schwachstelle. Bitte updaten!

Surface: TypeCover defekt :(

Gebrauchte Geräte sind so ein Ding, kann gut gehen, muß aber nicht. Deutlich zu niedrige Preise bei Ebay sind auch so ein Ding, kann ok sein, könnte aber auch Fake oder geklaut sein. Um das alles mit einem Linux Tablet zu verbinden, drehen wir die Zeit nochmal 7 Monate zurück….

Ein gebrauchtes Surface Pro 4

Aufgrund der Neukosten und Verfügbarkeit, ersteigerte ich im Guerillaverfahren im Februar ein gebrauchtes Surface Pro 4 auf Ebay. Ihr kennt die Geschichte ja. Im Juni setzte für einen Tag der Lüfter aus, weswegen es zu dem Geflimmer kam:  „Das wars dann mit dem Linux Tablet 🙁

Vor ein paar Wochen, ging plötzlich die Tastatur aus und ich meine aus, weil die Lichter der Tastaturbeleuchtung das deutlich zeigten. Ich hab erst gedacht, daß der USB-Hub nicht mehr will, und die Tastatur abgezogen und dann wieder dran gesteckt, was auch für wenige Minuten geholfen hat, bis die wieder ausgefallen ist. An dem Tag ging da nichts mehr, was komisch war.

Einen Tag später aka. zu Hause, ging die Tastatur dann wieder anstandslos! Technik halt. Ab und zu gabs mal einen kurzen Ausfall, aber ein Muster lies sich nicht ableiten. Um Kontaktschwierigkeiten auszuschliessen, wurden die Kontakte und Pins kurz geschliffen. Es änderte sich nichts. Egal wie man es knickte und kickte, es gab einfach keinen gezielten Ausfall. Damit war die Sache erstmal erledigt, weil Abziehen und wieder dranhängen half … bis Vorgestern. Da war Schluss. Ende, aus, tod.

Ihr erinnert Euch, ich hatte ein englisches Typecover mitbekommen, da fehlt die Taste mit dem „|“ Pipezeichen, was bei Linux ein echtes Problem bedeutet. Also habe ich mir bei Ebay ein gebrauchtes deutsches Typecover zugelegt. 12 Monate Garantie und unter 24h angekommen. Super.

Fazit

Bei Ebay gebraucht kaufen, kann durchaus klappen 🙂

Für Surface Pro Besitzer kann ich nur empfehlen, sich einen anderen Besitzer zu suchen und einfach mal die Typecovers umzuhängen. Geht es an beiden Geräten nicht, ist das TypeCover hin. Da die auch gebraucht nicht billig sind, da bekommt man einen schnellen Ryzen 1500 für, lohnt sich der Gang zum Surface Kollegen immer, egal ob der Windows oder Linux fährt.

Linuxtablet zieht Blicke auf sich

 

Grubby: wie man wieder einen Default Kernel setzen kann

Ihr habt ein Kernel Update eingespielt bekommen, aber der Default-Kernel ist immer noch der „alte“ Kernel? Willkommen in der digitalen Steinzeit der Grubby Bugs.

Wie man einen Default Kernel setzen kann

Per Mail erreichte mich eine Anfrage zu Grubby, das ist das kleine Tool, das sich um die Grub Booteinträge kümmert. In der Anfrage ging ein Kernel-Update schief und der Default Kernel lies sich nicht setzen. Die Ursache liegt in einem „Steinzeit“-Fehler: Der Grubenv Block ist wie in Stein gemeiselt genau 1024 Bytes lang, egal was sinnvolles drin steht 🙂

Jetzt ist der Bug an sich nichts neues, da reden der Redhat Support, die Fedora Maintainer und die Grubby Devs gefühlt schon eine Ewigkeit drüber. In etlichen Bugreports gibt es einen gemeinsamen Nenner: Grubby und nicht 1024 Bytes große grubenv Dateien 🙂

Wenn man jetzt versucht einen Default-Kernel zu setzen, kann man Opfer dieses Bugs werden und keiner sagt es einem, außer der schon gehässigen Regelmäßigkeit, mit der der alte Kernel gebootet wird. Beispiel:

[root@eve]# grubby --default-kernel
/boot/vmlinuz-5.2.7-100.fc29.x86_64
[root@eve]# grubby --set-default=/boot/vmlinuz-5.2.11-100.fc29.x86_64
[root@eve]# grubby --default-kernel
/boot/vmlinuz-5.2.7-100.fc29.x86_64
[root@eve]# cat /boot/grub2/grubenv
# GRUB Environment Block
saved_entry=Fedora (5.2.7-100.fc29.x86_64) 29 (Twenty Nine)
"

[root@eve#

Die Methode mit der man den Kernel als Default setzen will, spielt dabei keine Rolle:

[root@eve]# grubby --set-default-index=0
grub2-editenv: Fehler: Environment-Block ist zu klein.

Aber immerhin gibt es hier den Hinweis, der Block ist zu klein? Wie kann das sein, da steht doch min. der ALTE Kernel auch drin, wie kann der sich nur durch eine Nummer unterscheidene neue Kernel da nicht auch reinpassen?

Weil da wer von Hand rumgefummelt hatte …

Ja, ich gebs zu, ich habe mal irgendwann den Kernel von Hand da eingetragen, aber das war noch zu 4.20er Zeiten und seit dem gings doch auch, sonst wärs ja nicht 5.2.7 geworden. Die mögliche Antwort ist wenig schmeichelhaft: Grubby ist nicht ganz deterministisch veranlagt in letzter Zeit. Ich erwähnte ja, daß sich die Devs und Maintainer schon länger damit rumquälen, mal gehts, mal gehts nicht mehr. Die Bugreporter sind entsprechend genervt. Die Codebasis von Grubby will ich wohl besser nicht sehen.

Egal, eine Lösung muß her

Also, Ursache ist, daß Grubby nur dann das File erzeugt, wenn es GENAU 1024 Bytes lang ist. Keine Ahnung wieso und ich will es auch nicht wissen…. doch will ich, aber werde ich wohl trotzdem nie erfahren.

Sofern nichts außer dem Kernel in dem grubenv File steht, ist der Fix besonders einfach:

wahlweise mit EFI oder ohne :

rm -f /boot/grub2/grubenv
rm -f /boot/efi/EFI/fedora/grubenv

und dann den Block neu erzeugen lassen:

grubby –set-default-index=0

Fixed. Kniffliger wird es, wenn da noch andere Variablen drinstehen, denn dann dürft Ihr ungelogen mit einem Texteditor die Datei auf genau die 1024 Bytes trimmen/padden und dann abspeichern. Danach sollte grubby auch wieder den Default-Kernel da rein schreiben können.

Achtung:

ggf. sind /boot/grub2/grubenv und /boot/efi/EFI/fedora/grubenv  durch einen Symlink verbunden, schaut Euch das bitte vorher von Hand an, bevor Ihr Euch in Sicherheit wiegt. Es ist Eure Bootconfiguration, also lasst Vorsicht walten 😉 Bei Fragen, welche Datei zuständig ist, wendet Euch an die örtliche LUG, die freuen sich über Zulauf 🙂

Linux – Cannot find device „tun0“

Ihr wollt z.B. mit SSH ein VPN und dazu einen Tunnel aufbauen, könnt aber nicht, weil Ihr diese Fehlermeldung bekommt: Cannot find device „tun0“ ? Ja, na dann auf ins neue Netstackventure!

Tunneldevice mit Linux nutzen

Ihr erinnert Euch noch an den Artikel: SSH VPN mit den iproute2 Tools ? Da haben wir ein SSH VPN aus dem Hut gezaubert und mußten dazu mit Tunneln arbeiten. Da hat sich einiges getan, deswegen müssen wir uns leider erneut damit befassen.

Schritt 1 und 2 sind klar, ein TUN Modul laden und Device erzeugen, aber was ist das…?? :

[root@backup ~]# modprobe tun
[root@backup ~]# ip link set tun0 up;
Cannot find device "tun0"

Cannot find device „tun0““ ist ein echter Kopfschmerzenerzeuger, weil so unnötig. Also das Modul „tun“ ist wie der Name nahelegt, für Tunneldevices zuständig. Es sollte eigentlich ein Tunneldevice tun0 erzeugen, tuts aber nicht und mit normalen Fedora Bordmitteln ist das auch nicht so einfach machbar.

Ihr braucht das Paket „tunctl“ ( dnf install tunctl ) und müßt Euch erstmal ein tundevice bauen:

tunctl -t tun0

Wie man sieht, ist das nicht schwer. Jetzt, wo das Gerät persistent gemacht wurde, seht Ihr an der Ausgabe von dem Befehl oben, klappt das dann auch mit dem „ip link set tun0 up“ und Ihr könnt der Anleitung aus SSH VPN mit den iproute2 Tools weiter folgen. Ihr müßt nur dran denken, daß Ihr das auch bei Euch auf dem Client PC macht und nicht nur auf dem Server.

Eine Bewertung, wieso das nicht mehr defaultmäßig bei Fedora dabei ist, verkneif ich mir, es wird merkwürdige Gründe haben 🙂

Dell Venue 8 Pro Tablet mit Linux

Als Gastbeitrag gibt es heute einen Erfahrungsbericht von Malte ( BSLUG) zum Dell Venue 8 Pro Tablet und wie sich das mit Linux so schlägt. Da das Gerät schon in die Jahre gekommen ist, kann ich Euch leider nur Link zu Nachfolger anbieten: dell-venue-11-pro.

Abenteuer: Dell Tablet mit Linux betreiben

Ich klinke mich hier aus und wünsche Euch viel Vergnügen mit Maltes Abenteuerbericht:

Von der Begeisterung der Surface-Fraktion angesteckt, hatte ich irgendwann im Frühjahr beschlossen, mir auch ein Tablet anzuschaffen. Was ich wollte, war aber weniger ein Laptop-Ersatz (der funktioniert noch), als überhaupt mal ein Tablet auszuprobieren. Achtung, der Artikel wird lang…

Die Tablet Kaufentscheidung

Nach etwas Suche habe ich mich dann für das Dell Venue 8 Pro (5830) von 2013/14 entschieden. Von Werk aus ist ein „richtiges“ Windows 8 vorinstalliert. Das ist wichtig, weil das Tablet dank Intel-Prozessor technisch gesehen eher ein geschrumpftes Note- bzw. Netbook ist als ein aufgeblasenes Handy (wie die meisten Android-Tablets).

Das Tablet habe ich mit Hülle und Ladegerät für 60€ ersteigert, einen passenden Eingabestift für knapp 40. Damit ist mein Experiment „Tablet“ in Summe gerade noch unter 100€, viel besser für mein studentisches Budget als ein Surface. Außerdem, 100€ ist für „Spielzeug“ noch vertretbar.

Die Tablet Hardware

Leistungsmäßig darf man aber vom 2-Watt-Atom keine Wunder erwarten, und der Mangel an Anschlüssen (eine SD-Karte und eine Micro-USB-Dose, immerhin mit OTG-Support), RAM (2 GB) und ROM (32 GB) ist grenzwertig. Dafür ist das Tablet dünn und leicht (8 Zoll), und hält trotz Gebrauchtgerät je nach Nutzung 4-6 Stunden durch.

Wenn der Stift (Eigenentwicklung von Synaptics) mal funktioniert, dann ist er ganz okay, aber nicht mit Wacom oder N-Trig (z.B. im Surface) zu vergleichen. Man sollte darauf achten, einen Stift aus der 2. Serie zu bekommen (silber-schwarz statt nur schwarz), die erste war laut Internet häufig fehlerhaft. Meiner gab aber auch leider nach einigen Monaten intensiver Nutzung mit mechanischem Defekt auf. Wer weiß, wie man die silber-schwarze Version auf bekommt, soll sich bitte melden, im Internet ist nichts zu finden…

Immerhin hat Dell dem Tablet ein richtiges, klassisch grau-blaues BIOS spendiert. Das sieht zwar mit Touch etwas komisch aus, ist aber im Vergleich zu anderen Tablets extrem hilfreich.

Aussehen und Bios – Stift nur zum Größenvergleich. Diesen Stift bitte nicht benutzen 😉

Das Tablet mit Linux

Nachdem ich etwas mit dem installierten Windows gespielt (und ein Backup gemacht) habe, muss auf das Gerät zumindest mal auch Linux drauf, sonst wäre es ja hier auf dem Blog fehl am Platz 😉

Linux, das Positive

Fangen wir mal an mit dem, was geklappt hat: Linux läuft mit aktuellem Kernel (5.x) in der Regel stabil, erkennt Lage, Helligkeit, Video, Audio, Stift und nach Download der Firmware auch WLAN, und ist allgemein benutzbar. Je nach Distribution (z.B Fedora 29) ist die Installation genau so einfach wie auf einem Laptop: mit OTG-Adapter vom USB-Stick starten (Lautstärke-Wippe für Bios- bzw. Bootmenü) und Anweisungen folgen.

Desktopumgebung für Tablets

Die einzige richtig benutzbare Desktopumgebung für Touch ist Gnome 3. Punkt.

Korrigiert mich hier bitte, ich habe nichts besseres gefunden. Aber Gnome 3 ist LANGSAM. Das merkt man schon auf einem Desktop mit i5 und massig RAM, und das wird mit 2 GB RAM und einem 2-Watt-Prozessor nicht besser.

Einer der Gründe ist wohl, das Gnome mehr oder weniger ALLES in einem Thread erledigt. Unter Wayland beinhaltet das sogar Input-Events – wenn also gerade eine Animation „läuft“ bzw. kriecht, reagieren weder Maus noch Touch noch Tastatur. Bei Touch sorgt das für leichte Aggressionen, weil dann einfach „Dinge passieren“. Unter X11 reagiert wenigstens noch die Event-Verarbeitung. Mit dem RAM-Verbrauch von Gnome will ich erst gar nicht anfangen, sonst bin ich morgen noch nicht fertig.

Screenshots aus dem Betrieb, Gnome 3 mit Theme und Iconpack

KDE oder Cinnamon zeigen, dass es definitiv anders geht, sind aber mit Touch (noch) nicht vernünftig zu benutzen. Selbst Windows 10 war da schneller… wenigstens sieht Gnome mit den vielen verfügbaren Themes gut aus.

Ärger mit den Treibern

Hardwareunterstützung bei weniger bekannter Hardware ist unter Linux oft ein Problem, und so auch bei meinem Tablet: Es gibt es keinen passenden Kamera-Treiber für Linux (Stichwort „atomisp“), und der WLAN-Treiber für Linux kann weder Bluetooth, 5 Ghz oder gar Miracast. Gerade Miracast wäre für ein Gerät, was keinen Bildschirmanschluss hat, extrem nützlich. Als Workaround habe ich etwas mit Remote-Desktop von einem PC aus gebastelt, aber schön ist das nicht. Auch hat das WLAN Probleme mit dem Stromsparen: um unter Linux Paketverluste und eine Latenz von 400 ms (!) im lokalen Netz zu vermeiden, muss man hier eine gut versteckte Konfigurationsdatei ändern.

Auch nicht schön: Der Linux-Kernel auf einigen billigen Intel-Prozessoren läuft immer noch nicht stabil, das heißt, je nach Tagesform gelegentlich ein Total-Einfrieren. Kernel 5.2 sollte eigentlich Besserung bringen, ist aber auch nicht stabiler. Vielleicht ändert sich hier aber noch etwas.

Weiter haben die Live-USB-Sticks vieler Distributionen in der 64-bit-Version ein Problem mit der Kombination 32-bit EFI und 64-bit CPU (lassen sich aber, einmal gestartet, korrekt installieren). Löbliche Ausnahme ist hier Fedora. Hut ab 😉

Surfen mit Touch und Mini-CPU

Ärger gab es auch mit Firefox. Um unter X11 (mit Gnome deutlich schneller als Wayland, s.o.) mit Touch wie vom Handy gewohnt bedienbar zu sein (mit dem Finger scrollen, 2-Finger-Zoom, Rechtsklick etc.), muss man erst mal an geeigneter Stelle die Umgebungsvariable MOZ_USE_XINPUT2 auf 1 setzen.

Toll ist auch, dass Firefox unter Linux keine Hardware-Beschleunigung für Videos nutzt. Damit wird der arme Atom-Prozessor bei Youtube und Verwandtschaft in HD zur Heizplatte. Den entsprechenden Bugreport gibt es jetzt schon ein paar Jahre, aber das scheint keinen zu interessieren. Um trotzdem außerhalb des Kühlschranks Youtube schauen zu können, habe ich ein FF-Addon namens „ff2mpv“ ausgegraben, was mit etwas Tricksen dazu gebracht wurde, mit mpv in 720p mittels GPU zu spielen ( mpv –hwdec=vaapi –vo=vaapi –ytdl-format=“mp4[height<=720]“ $* ) – absolut intuitiv, oder?

Als Alternative zu Firefox sollte man übrigens mal Falkon (früher QupZilla) ausprobieren, der Touch-Support ist dank Chromium/QtWebEngine-Unterbau fast genau so gut und der schlanke Browser ist gefühlt etwas schneller. Nachteil ist die kleine Community und die fehlenden Addons.

Fazit

Ich habe das Tablet jetzt einige Monate mit dem Stift als Papierersatz in Vorlesungen und zu Hause benutzt, nutze das daneben zum Videos-auf-dem-Sofa-oder-im-Zug schauen oder zum Schnell-mal-etwas-suchen. Dafür hat es die perfekte Größe. Würde ich das nochmal kaufen müssen, würde ich mich wahrscheinlich für die 11-Zoll-Version entscheiden, 8 Zoll ist doch recht knapp.

Neben Fedora habe ich eine Reihe Distributionen ausprobiert, von denen aber eigentlich alle irgendeine Macke hatten. Hängen geblieben bin ich bei Debian, weil ich das einerseits auch auf dem Laptop habe und andererseits die etwas ältere Gnome-Version subjektiv etwas flüssiger läuft.

Das Tablet ist zwar kein Laptop-Ersatz, aber fühlt sich deutlich mächtiger an als ein noch so smartes Handy. Wer das nicht glaubt, der soll mal versuchen, auf Android z.B. mal mehrere Fenster gleichzeitig auf zu machen… oder mir sagen, wann sein Androide das letzte Mal ein Kernel-Update bekommen hat.

Und Linux?

Trotz allem, für Leute, die das Gerät „einfach nur nutzen“ wollen, bleibt zumindest bei diesem Tablet nur Windows, so leid mir das tut.

Auch wenn der Artikel ziemlich negativ klingt: Letztlich war das Experiment „Tablet“ mindestens ein Teilerfolg. Einmal habe ich das Gerät gerade auch zum Basteln gekauft, war also nicht überrascht. Zum anderen, wenn ich mir das nächste Mal einen Laptop kaufe, wird er wohl mindestens auch Touch haben.


Software und Links für Linux-Tablets

Xournalpp (https://github.com/xournalpp/xournalpp/) zum Schreiben und Zeichnen, muss man je nach Distribution ggf. leider selbst kompilieren, ist es aber gegenüber dem „normalen“ Xournal wert

Onboard (https://launchpad.net/onboard) als viel (!) bessere Tastatur mit konfigurierbarem Layout

Easystroke (https://github.com/thjaeger/easystroke/wiki) für erweiterte Gesten („wenn ich einen Kringel mit dem Stift male, dann…“)

https://www.studioteabag.com/science/dell-venue-pro-linux/ extrem hilfreicher Artikel zu Linux auf dem Venue 8 Pro, englisch, leicht veraltet

ff2mpv (https://addons.mozilla.org/de/firefox/addon/ff2mpv/) Um Online-Videos mit mpv hardwarebeschleunigt abzuspielen

Und noch der Beitrag zum Wifi-Powersaving im Networkmanager:

https://gist.github.com/jcberthon/ea8cfe278998968ba7c5a95344bc8b55

NetworkManager WiFi Power Saving

NetworkManager supports WiFi powersaving but the function is rather undocumented.

From the source code: wifi.powersave can have the following value:

  • NM_SETTING_WIRELESS_POWERSAVE_DEFAULT (0): use the default value
  • NM_SETTING_WIRELESS_POWERSAVE_IGNORE (1): don’t touch existing setting
  • NM_SETTING_WIRELESS_POWERSAVE_DISABLE (2): disable powersave
  • NM_SETTING_WIRELESS_POWERSAVE_ENABLE (3): enable powersave

Then I propose 2 files, only one of them needs to be put under /etc/NetworkManager/conf.d/.
One is forcing to disable powersaving, while the other one enable it.

Once you have put the file in the right folder, simply restart NetworkManager:

sudo systemctl restart NetworkManager

# File to be place under /etc/NetworkManager/conf.d
[connection]
# Values are 0 (use default), 1 (ignore/don't touch), 2 (disable) or 3 (enable).
wifi.powersave = 2

# File to be place under /etc/NetworkManager/conf.d
[connection]
# Values are 0 (use default), 1 (ignore/don't touch), 2 (disable) or 3 (enable).
wifi.powersave = 3

~ Malte

 

Surface: TypeCover defekt 🙁

Wieso DoH nicht gut für die Privatsphäre des User ist.

Mozilla will ja ab sofort in den USA DoH als Testballon starten. Der Rest der Welt soll später folgen. Ziel der Aktion ist es, daß DNS Anfragen nicht mehr von DNS-Servern wie Bind beantwortet werden, sondern, daß Webserver die DNS Informationen für den anfragenden Clienten per HTTPS beantworten. Bleibt die Frage, was und woher tunnelt er die Daten?

„Wäre es nicht die Wirklichkeit, es wäre ein Bestseller“

Ganz kurz umrissen, wird Firefox per HTTPS  die Cloudflare DoH-Webserver fragen, die holen sich DNS Antworten dann vom Cloudflare DNS-Servern und der von den korrekten  DNS-Servern. In der Endstufe war geplant, daß die besuchten Webserver die DNS Anfragen selbst beantworten, so daß wieder eine dezentrale Struktur entsteht.

Mozilla möchte damit erreichen, daß DNS Anfragen nicht mehr im Klartext durchs Netz gehen, weil ein Angreifer die bisherige DNS Information mit einer MITM-Attacke angreifen kann ( Man-in-the-Middle ). Nobel, aber sollte DNSSEC nicht genau das Problem lösen?

Und wer sagt uns, daß Cloudflare die Daten nicht manipuliert? Millionen von DNS-Webanfragen  würden bei Cloudflare durchgehen und wären so leichteste Beute für einen, der nicht will, daß Domain X erreichbar ist, oder Inhalt Y hat.

Wer schützt uns vor Zensur?

Das DNS System, denn es gibt Millionen DNS Server und Caches aus denen ich mir die Informationen zu einer Domain ziehen kann, inklusive der Autoritären-DNS des Domaininhabers.

Wie jetzt, Eurer Provider blockt externe DNS und erlaubt Euch nur seine eigenen DNS-Caches zu benutzen?

Lest das hier: UDP Traffic per SSH tunneln

Und wie sieht es mit dem Datenschutz aus?

Firefox sendet jetzt private Informationen in einem Ausmaß an ein amerikanisches Unternehmen, daß daraus leicht Profile bilden kann, und der Datenschutz sieht zu? Glaube ich kaum.

Was wollte Mozilla doch gleich mit DoH schützen?

Die Privatsphäre, ach ja, kommen wir mal dazu. Korrekt ist, daß ein DNS Betreiber in den Logfiles, so er denn welche erstellt, nachsehen kann, welche IP welche Domain hat auflösen wollen. Cloudflare kann das auch, niemand hindert sie daran. D.b. für die Privatsphäre ist es mit Cloudflare als derzeit einzigem DoH Betreiber, noch schlechter bestellt, als jetzt.

Derzeit kann ich mir aussuchen, welchen der vielen DNS Server ich frage, oder ob ich mir vielleicht gleich selbst einen eigenen DNS Cache hinstelle, der nur für mich arbeitet. Mit DoH geht das nicht mehr, außer ich betreibe einen DoH Server. Mangels Masse, eher unrealistisch derzeit.

Wie man seine eigenen DNS Anfragen auf möglichst viele DNS Server verteilt um bei keinem der DNS Betreiber ein sinnvolles Profil zu hinterlassen, findet Ihr in diesem früheren Beitrag von mir : Linux – DNS-DeTracking mit nscd

Fazit

DoH ist derzeit die leibhaftige Vision einen dystopische Zukunft, in der alle User bei einem einzigen Anbieter sind, so wie in den Terranauten, alle beim Energiekonzern Energie beziehen, vom Lebensmittelkonzern ernährt werden und auch ansonsten von Monopolen beherrscht werden. DoH ist im jetzigen Zustand nur eins: nicht akzeptabel.

Eine (von vielen) Alternative

DNS-Anfragen per TLS manipulationssicher zu machen, ist ok. Aber, wozu eigentlich der HTTP Overhead? Reicht es nicht, wenn Bind einen TLS Port bereitstellen würde und der zuerst gefragt wird? Das hätte zur Folge, daß der Server durch den SNI im TLS auch domainbasierte Zertifikate benutzen kann, also auch beweisen könnte, daß er er ist und nicht ein MITM-Angreifer.

Zugegeben, der Overhead dabei wäre aufgrund der möglichen Schlüssellängen ziemlich heftig, aber dafür könnte man z.b. kleinere, mit dem Zertifikat des Domaininhabers signierte, DNS Zertifikate einsetzen. Lets Encrypt könnte das z.B. gleich mit erzeugen und ausliefern, wenn das Hauptzertifikat erzeugt wird.

DNS-Caches könnte man dann gleich daran erkennen, daß sie ein Zert anbieten, daß nicht zum Domainnamen paßt. Anhand der bekannten Root–Zertifikate könnte man auch gleich die Ketten verifizieren. Es ist etablierte Technik, es gibt etablierte Bibliotheken, systemische Schwachstellen sind bekannt, und durch die kürzeren Zerts wäre der Performanceeinbruch nicht so stark. Würde man zudem mehrere DNS Anfragen in einer TCP Sesssion durchführen, so denn sinnvoll möglich, würde der Overhead weiter sinken.

Es gibt also Methoden, die eine derzeit zentrale Instanz wie Cloudflare nicht benötigen, warum also  dann DoH durchziehen?  In einer dystopischen Zukunft wären die Gründe wie immer: Machtgeilheit, Geldgier und, daß eine Gruppe von wackeren Helden den Schurken in einem effektvollen Kampf schlagen kann.

In dem Sinn: „Avengers, Assemble!“

und gleich die nächste Timing Attacke auf Intel-CPUs: NetCAT

Niederländische Forscher der Vrije Universität in Amsterdam haben die Schwachstelle entdeckt. Vom Typ her eine Timing-Attacke, die man übers Netzwerk ausführen kann. .

NetCAT – Remote Attacke auf Intel CPUs dank DDIO

DDIO ( Data-Direct I/O ) gibt Netzwerkkarten und anderen Peripheriegeräten direkten Zugriff auf das CPU Cache. DDIO ist seit 2012 bei fast allen INTEL Server CPUs eingeschaltet, also eher schlecht für die Leistung, wenn man das abschaltet.

Die Lücke taugt zum Abgreifen von Tastatureingaben z.b. in SSH, weil man durch die Latenzunterschiede der Pakete vom Angreifer zum Server messen kann, welche Tasten gedrückt wurden. Schuld ist der Zustand der CPU-Caches, der in Abhängigkeit was man tut, eben schneller oder langsamer reagiert.

Wie auch schon bei Lauschangriffen auf Tastatureingaben, kann man aus den Abfolgen der Zeitunterschiede auf die Tasten rückschließen, weil es unterschiedlich lange dauert, mit dem Finger von A nach P zu kommen, als von A nach S.

Die Forscher haben zur Genauigkeit der Attacke über Netz folgendes zu sagen:

„Compared to a native local attacker, NetCAT’s attack from across the network only reduces the accuracy of the discovered keystrokes on average by 11.7% by discovering inter-arrival of SSH packets with a true positive rate of 85%.“

Meint: Das Netz macht es nur geringfügig ungenauer. Danke Intel!

Apros Intel, was sagen die dazu: „Pfff.. Klappt in der Realität wohl eher weniger, nicht so wichtig. Hier Forscher, ein kleines Dankeschön fürs Mitspielen.“

Gegenmaßnahmen

DDIO abschalten. Viel Spaß damit.

Oder man benutzt gleich Schlüssel zum SSH Login, dann ergibt sich das Problem gar nicht erst.

Quelle: https://thehackernews.com/2019/09/netcat-intel-side-channel.html