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.

 

 

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 🙂