Linux installieren mit der BSLUG

Es ist mal wieder soweit, die BS LUG lädt bislang mit Linux unterversorgte Besucher ein, sich selbiges installieren zu lassen \O/

Die Aktion findet am 23.1.2019 ab 18 Uhr im Haus der Talente, Elbestraße 45, Braunschweig-Weststadt statt.

Vorbeibringen kann man alles, was  mehr als 1 GB RAM hat, 64 Bits benutzen kann und beim Anfassen nicht gleich eine Staubexplosion auslöst. Stromkabel, Tastatur, Maus, Monitor nebst Käbelin, sind mitzubringen!

Von Daten ist vorher ein Backup zu fertig, wir bekommen von Ihnen schriftlich, daß „das weg kann“ was drauf ist. Nicht, daß am Ende jemand heult, weil seine 3 Milliarden in Bitcoins weg wären 😉

Mehr Infos und Updates gibts dann hier von der LUG: https://bs-lug.de/activitys/partys/20190123.ip

Zwei Sicherheitslücken auf die wir lange warten mußten!

Darauf mußten wir lange, lange warten:

THN: 36 Jahre alte Sicherheitslücke in SCP entdeckt!

Wie die Hacker News berichten, gibt es in SCP eine 36 Jahre alte Lücke, die es einem böswilligen Server erlaubt, beliebige Files beim Benutzer zu überschreiben.Da fast alle Implementierung vom alten Originalcode abstammen, sind sehr viele Anwendungen davon betroffen. Es können z.B. verstecke Bash-Files im Home (eines Unix/Linux/Macusers ) erzeugt werden, die als ANSI Codes übermittelt werden. Möglich wird die mangels guter Prüfung des erhaltenen Contents durch SCP. Da scp üblicherweise in der Shell eingesetzt wird, könnte das praktische ausnutzen der Schwachstelle in der Regel schwierig werden, da man sich nur zu bekannten Server mit SCP verbindet. Jemanden da per Spam hin zu bekommen, könnte schwer fallen.

Auch lange warten mußten wir auf diese Meldung, die nicht minder prikär ist, vielleicht sogar noch schlimmer:

heise.de : Forscher brechen aus Docker-Container aus

Ich persönlich warte ja schon länger auf diese Meldung, aber verwundern wird sie wohl keinen. Die Hauptkritik an Container ist ja, daß die darin enthaltene Software nicht aktuell gehalten sein wird, weil sonst könnte der Entwickler die Anwendung ja auch prima auf einem normalen System starten. Natürlich gibt es noch andere Gründe für einen Container: Transferierbarkeit, Skalierbarkeit  usw. aber uns interessiert die Sicherheit natürlich mehr. Wenn ich jetzt Software von Anno Schnee in einem Container habe, der nicht aktualisiert wird, weil „wieso, geht doch!“, das übliche Argument der Neulandmanager halt, dann habe ich jetzt endlich den Exploit, der mir bisher fehlte, um aus dem Schrott auszubrechen. VMs sind übrigens nicht anders, nur einer VM kann ich ( ICH!! ) sagen, daß das System dadrin aktualisiert werden soll. Bei „Docker“ ist das ein Heckmeck sondergleichen, wenn die Funktion nicht vorgesehen ist.

Die „Play with Docker“ Containerumgebung wird nicht die Einzige sein, die mit „wieso, kann doch keiner ausbrechen“ als Argument, die Anwendung mit erhöhten Rechten laufen läßt. Es wird also spannend werden, wenn man Docker einsetzt. Eine Lücke mehr, die man stopfen muß. Das sollte man sich vor Augen halten.

Elite Dangerous … mit Wine 4.0.0

Oh… schaut was da auf der Platte materialiserte 😀

Elite Danergous mit Wine 4.0.0-rc2 auf Fedora 28Jetzt bräuchte man nur noch einen Game-Code und die Reise in die Galaxy könnte losgehen 🙂

Die Installation war nicht ganz so schwierig, wie man denken sollte. Es dauerte halt einer Weile, eine neue 64Bit Wine Umgebung aufzubauen, da Elite Dangerous nur mit 64bit funktioniert. Schwieriger wars eine Elite Dangerous Version zu bekommen, die man installieren konnte: (Ich hasse Steam!)

http://hosting.zaonce.net/elite/Client-Installer-DX11.exe

Obiger Downloadlink stammt aus der Lutris Installationsanleitung . Laut Virustotal ist die Datei ok , hoffen wir mal, daß das stimmt.

Die Installation an sich war ok, nur das ominöse DXVK wollte Winetricks nicht kennen, naja startet auch so.

Die Probleme des Launchers sind bekannt und sind wohl eher schlechter HTML Programmierung geschuldet, denn dem Umstand, daß es Wine ist.

Ihr könnt ja mal Euren Kommentar oder einen 14 Tage Testgamecode da lassen, dann teste ich das Spiel aus : versprochen 😉

Fedora 28: Planet Crash

Mit Fedora 28 ist es grade, als wenn man in einen Topf Farbe getreten ist und jetzt die Farbe überall verteilt. Egal wo man hinschaut Bugs, Bugs und noch mehr Bugs.

Heute:  ProjectM-PulseAudio

Für alle die ProjectM nicht kennen, das ist ein Audio-Visualisierungs-Plugin, das langweilige Musikabende optisch aufhübschen soll, idealerweise im Takt der Musik.

Scheinbar ist das bei Fedora auf dem absteigenden Ast gelandet, meint, es ist als verweist markiert. Es gibt also keinen Maintainer und Redhat muß selbst ran, und genau da haperts bei Redhat grade. Das Problem liegt in der Speicherverwaltung, was zu einem „Double Free“ Fehler führt. Für Nichtentwickler, daß bedeutet, daß ein Speicherbereich zwei(++)mal freigegeben werden soll. Das ist ein schwerwiegender Programmierfehler und wird besonders oft von C-Entwicklern gemacht, weil das Speichermanagement von C schlicht nicht vorhanden ist. Einem Java-Programm kann das nicht passieren, da die JVM das Speichermanagement komplett übernimmt.

Ich wette Fefe, wüßte jetzt, auf welchem Platz der häufigsten Programmierfehler in C der DoubleFree steht, aber ich kann nur raten. Gefühlt in den Top 3, direkt nach Buffer-Overflow und „Zeiger auf Zeiger verdengelt“ 🙂

Also falls Ihr mit ProjectM rechnet, seid nicht enttäuscht, wenn es nach 5 Sekunden crasht.

Update:

Nachdem ich mit auf Github einen BugReport erstellt habe, stellt sich raus, daß Fedora eine uralte Version zur Verfügung gestellt hat. Es wird dringend dazu geraten, ProjectM selbst zu kompilieren, nur ist das, wie sich zeigt, nicht so einfach. Das Configure Script vermeidet bewußt zu sagen, was ihm zum Ausführen am QT Libs genau fehlt, ohne QT unterdrückt das make einfach mal die Fehler beim Bau von projectM-pulseaudio und sagt am Ende, daß alles fehlerfrei geklappt hat. Natürlich ohne irgendwas brauchbares erstellt zu haben.

Das kann man zwar nicht direkt als Bug bezeichnen, zeigt aber auf, wo da wohl das Problem seitens Redhat liegt, eine aktuelle Version zusammen zu häkeln.

Aus der Schmunzelecke von Bugzilla

Für Euch mal was zum Schmunzeln, das erlebt man auch nicht so oft, daß sich der Maintainer bei den Bugreportern dafür entschuldigt, in den Urlaub gefahren zu sein 😉

--- Comment #3 from Zdenek Dohnal <zdohnal@redhat.com> ---
Hi,

thank you for reporting the issue! I'm deeply sorry for inconvenience, I pushed
the update without cross checking if new net-snmp is already in the stable (I
wasn't able to add hplip to net-snmp update) and I went on vacation after that.
You can install previous version from koji for now
https://koji.fedoraproject.org/koji/buildinfo?buildID=1163784 .

Der Fall stellt sich so dar:

Der Maintainer von hplip, hat als Abhängigkeit net-snmp drin und haut sein Update ins Stable Repo, ohne zu checken, ob den auch die Version von net-snmp im Stable ist, die er braucht. Wars nicht, also hat DNF zu Recht rumgeheult, daß es nicht updaten kann, weil gibt es nicht ja nicht im Repo, was das Paket so braucht. Das kommt übrigens öfters vor, als man denkt. Sind halt alles nur Menschen 😀 Aber die Entschuldigung im Bugtracker ist ein Unikum 😀

Falls Euch das auch mal unterkommen sollte, ich hab die neue Version von net-snmp dann im UPDATES-TESTING Repo von Fedora vorgefunden und ein : dnf –enablerepo=updates-testing update net-snmp* hats dann gelöst. Da müßt Ihr dann natürlich die Euch fehlende Abhängigkeit benutzen, nicht net-snmp 😉