Games – 1 Mio. $ Schlacht, oder doch nicht ?

Letzte Nacht fand in dem mit Linux spielbaren MMORPG EVE Online der als „1 Mio. $ Schlacht“ angekündigte Kampf um eine Pandamic Horde Keepstar statt. Dummerweise  blieb der Schaden weit runter den ankündigten 1 Mio. Dollar .

Was war passiert ?

Wie in keinem anderen MMO, kann man in EVE Online tatsächlich Werte aufbauen, etwas besitzen und es von anderen Spielern verloren bekommen, wenn die diese Werte vernichten. Da man dazu die Hilfe von anderen braucht, gründen Spieler  Firmen und bilden Allianzen im Spiel, damit sie mehr erreichen und besser geschützt sind.

Die Allianzen wiederum bilden mit unter Machtblöcke. Zwei dieser Machtblöcke sind letzte Nacht im System 9-4RP2 in der Region Cloud Ring aufeinander getroffen. Die Koalition des Nordes mit NC., Pandamic Horde und Pandamic Legion verteidigte die größte aufstellbare Struktur , einen Keepstar, gegen die Kräfte des Südens: Test & Goons. Natürlich hat jede dieser Allianzen noch Anhängsel mitgebracht, so daß am Ende mehr als 6000 Kämpfer in 9-4RP2 gleichzeitig am kämpfen waren.

Das keine Seite viel Spaß haben würde, war EVE Spielern bewußt, denn was bei soviel Aktion passiert ist, daß der Server das nicht mehr in Echtzeit bearbeiten kann. Der sogenannte TIDI setzt ein und das Spiel wird für alle Spieler in dem System langsamer. So dauerten Flüge von wenigen Kilometern in Echtzeit Stunden. Wer einen Disconnect hatte, brauchte schon 45 Minuten um wieder einzuloggen.

Der Grund des Kampfes

Normalerweise reiben sich so große Machtblöcke nicht an einander, wie sich im Laufe des Abends aber herausstellte, hatte Pandamic Legion (PL) ein Abkommen mit der TEST Allianz gebrochen und eine kleinere Version des Keepstars, namens Fortizar, in der Region Catch plaziert. TEST hat das als Beginn einer Invasion gewertet und zum Gegenschlag ausgeholt.

Durch einen kleinen Fehler der Pandamic Horde, welcher der Keepstar gehört, ergab sich für den Süden ein Angriffsfenster das entsprechend genutzt wurde. Nun kann man so einen Keepstar nicht einfach von Feld ballern. Es gibt gewisse Regeln die das weltweite Zeitzonenproblem ausgleichen sollen, um zu verhindern das jemand von Australien ausnutzt, daß man selbst im Bett ist. Diese Regeln verlangen insgesamt drei Kämpfe: einen zum erstmaligen Reinforce, da ist der Verteidiger meistens nicht so präsent, es folgt der Armortimer einen Tag später und eine Woche später der finale Kampf. Um so einen finalen Kampf ging es gestern. Den Armortimer hatte PL durch eine ungeschickte Taktik verloren.

Der Kampf

Nach 22 Uhr unserer Zeit konnte man endlich den Keepstar angreifen, was die „Imperiumsflotte“ von Goons und TEST dann auch gemacht hat, indem sie Fighter (kampfkräftige Dronen) von Ihren Strukturen zum Keepstar geschickt hat. Die Verteidiger haben eine Welle Anti-Fighter losgeschickt, um die Fighter des Imperiums abzuwehren. Durch eine Reihe eher fragwürdiger Entscheidungen, kam das Kommando über eine Verteidigerflotte in die Hand eines unerfahrenen Fleetcommanders, der in einer Panikreaktion eine Verteidigerflotte von 250 Schlachtschiffen vom Keepstar weggewarpt hatte.  Diese Schlachtschiffe waren auf ECM / Elektronische Gegenmaßnahmen ausgerüstet und sollten die Fighter daran hindern den Keepstar unter Feuer zu nehmen. Zu allem Überfluß drücke der Spieler, der die Verteidigungswaffen des Keepstar bediente gleich mehrfach auf den falschen Kopf. Statt den Fleetcommander der Angreifer mit seinen Waffen aus dem Verkehr zu ziehen, traf er damit unglücklich ein paar kleinere Schiffe, die zwar zerstört wurden, aber keinen Wert darstellten. Damit waren seine mächtigsten Waffen für 1,5 Stunden verstummt. Als wenn das nicht gereicht hätte, drücke der Gleiche nochmal einen Knopf und vaporisierte eine seiner eigenen ECM Frigflotten (Griffin ECM Frigatten), die grade am Keepstar aktiv im Kampf gegen die Fighter und damit der Pointdefence ausgeliefert waren.

Hier hätte man bereits den Schlußstrich ziehen können, denn solche Fehler bestraft der Gegner normalerweise sofort. Im Tidi dann halt Stunden später 😉  Zunächst sah es auch so aus, als wenn der Keepstar fallen würde. Gegen 1.20 Uhr unserer Zeit waren bereits 25% der Struktur zerstört und alle 3 Minuten kam 1% dazu. Das gegen 3.40 Uhr dann, der Keepstar doch noch gerettet wurde, konnte noch keiner erklären. Der Kampf dauerte noch bis 8 Uhr morgens an.

Die Bilanz

Zunächst mal das Berechnungsmodell für die realen Schäden. Spieler können sich Spielzeit für Realgeld kaufen. Diese Spielzeit können sie im Spiel gegen Spielwährung tauschen. Hier sind 12 -15  € pro 1,5 Milliarden ISK anzusetzen, kommt immer drauf an, ob man das direkt bei CCP oder einen Zwischenhändler kauft. Das macht im günstigsten Fall 0,8 Cent pro Million ISK. Genauer ist das nicht nötig.

Laut Zkillboard, dem derzeit einzigem  Weg zu ermitteln, wieviele Schiffe und damit Werte zerstört wurden, liegt die Summe für den kompletten Januar für das System 9-4RP2 bei 619 Milliarden ISK.  Das entspricht einem Kurs von 4952 € realem Geld und liegt damit weit unter den Schäden die für diese Schlacht angesetzt waren.

Allein CCP, der Gamehersteller, wird am Ende sagen können, wieviel ISK wirklich zerstört wurde. Die Zahl wird sicherlich noch etwas steigen, weil nicht alle zerstörten Objekte auf dem Killboard gelandet sind, oder in benachbarten Systemen vernichtet wurden. Alleine der Keepstar wäre 300 + X Milliarden ISK wert gewesen.

Kernel 4.14.14 OOPSt rum

Heute soll es einen kleinen Bericht aus der Praxis mit den neuen Kernelpatchen geben. Seit 2 Wochen bauen die Kernelentwickler an den Patches für Spectre & Meltdown rum. Vermutlich schon länger, aber seit 2 Wochen sind die Ergebnisse im Umlauf 😉 Nach anfänglichen Erfolgen gegen den Angriff, wurden schnell die Probleme zu Tage gefördert, die durch den Patch verursacht werden.

Massenbetatests

Da ich auf unserer Serverfarm die neuen Kernel ausprobiert habe, habe ich die gefundenen Fehler an Redhat gemeldet. Das war vor 14 Tagen, als die Patche rauskamen. Seitdem sind „wir“ (an dem Bugreport sind viele Leute beteiligt) im ständigen Dialog und testen die neuen Kernel unter „real“(tm) Bedingungen aus.

Stand ist, die Kernel funktionieren soweit stabil. Aber einzelne Prozesse in der Virtualisierung und bei JAVA führen immer wieder zu Fehlern. Zwei von den vielen Fehlern, habe ich Euch mal mitgebracht:

Jan 21 06:04:21 xxx kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
Jan 21 06:04:21 xxx kernel: IP: 0x99cf048
Jan 21 06:04:21 xxx kernel: PGD 461b067 P4D 461b067 PUD 57fd067 PMD 0
Jan 21 06:04:21 xxx kernel: Oops: 0002 [#3] SMP NOPTI
Jan 21 06:04:21 xxx kernel: Modules linked in: nfsv3 nfs fscache fuse nfsd auth_rpcgss nfs_acl lockd grace xt_owner xt_multiport ip6table_filter ip6_tables cfg80211 rfkill xenfs xen_privcmd sunrpc edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xen_netfront xen_blkfront crc32c_intel
Jan 21 06:04:21 xxx kernel: CPU: 0 PID: 6020 Comm: xenstore-read Tainted: G D W 4.14.14-201.fc26.x86_64 #1
Jan 21 06:04:21 xxx kernel: task: ffff880005708000 task.stack: ffffc90000d18000
Jan 21 06:04:21 xxx kernel: RIP: e030:0x99cf048
Jan 21 06:04:21 xxx kernel: RSP: e02b:ffffc90000d1bfd0 EFLAGS: 00010206
Jan 21 06:04:21 xxx kernel: RAX: 0000000000000003 RBX: 0000000000000003 RCX: 00000000099cf048
Jan 21 06:04:21 xxx kernel: RDX: 0000000000000002 RSI: 00000000099cf048 RDI: 0000000000000000
Jan 21 06:04:21 xxx kernel: RBP: 00000000ffddc0a8 R08: 0000000000000000 R09: 0000000000000000
Jan 21 06:04:21 xxx kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
Jan 21 06:04:21 xxx kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Jan 21 06:04:21 xxx kernel: FS: 00007f8761262b40(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000
Jan 21 06:04:21 xxx kernel: CS: e033 DS: 002b ES: 002b CR0: 0000000080050033
Jan 21 06:04:21 xxx kernel: CR2: 0000000000000003 CR3: 0000000003556000 CR4: 0000000000000660
Jan 21 06:04:21 xxx kernel: Call Trace:
Jan 21 06:04:21 xxx kernel: ? switch_to_thread_stack+0x21/0x40
Jan 21 06:04:21 xxx kernel: Code: Bad RIP value.
Jan 21 06:04:21 xxx kernel: RIP: 0x99cf048 RSP: ffffc90000d1bfd0
Jan 21 06:04:21 xxx kernel: CR2: 0000000000000003
Jan 21 06:04:21 xxx kernel: ---[ end trace 50c257ff957ddb5b ]---
Jan 21 08:17:31 xxx kernel: invalid opcode: 0000 [#4] SMP NOPTI
Jan 21 08:17:31 xxx kernel: Modules linked in: nfsv3 nfs fscache fuse nfsd auth_rpcgss nfs_acl lockd grace xt_owner xt_multiport ip6table_filter ip6_tables cfg80211 rfkill xenfs xen_privcmd sunrpc edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xen_netfront xen_blkfront crc32c_intel
Jan 21 08:17:31 xxx kernel: CPU: 0 PID: 7087 Comm: xenstore-read Tainted: G D W 4.14.14-201.fc26.x86_64 #1
Jan 21 08:17:31 xxx kernel: task: ffff88007a873c00 task.stack: ffffc900008c8000
Jan 21 08:17:31 xxx kernel: RIP: e030:0xffd9af11
Jan 21 08:17:31 xxx kernel: RSP: e02b:ffffc900008cbfd0 EFLAGS: 00010206
Jan 21 08:17:31 xxx kernel: RAX: 0000000000000004 RBX: 0000000000000003 RCX: 00000000ffd9af11
Jan 21 08:17:31 xxx kernel: RDX: 0000000000000022 RSI: 00000000ffd9af11 RDI: 0000000000000000
Jan 21 08:17:31 xxx kernel: RBP: 00000000ffd99b58 R08: 0000000000000000 R09: 0000000000000000
Jan 21 08:17:31 xxx kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
Jan 21 08:17:31 xxx kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Jan 21 08:17:31 xxx kernel: FS: 00007f2cc2baeb40(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000
Jan 21 08:17:31 xxx kernel: CS: e033 DS: 002b ES: 002b CR0: 0000000080050033
Jan 21 08:17:31 xxx kernel: CR2: 00000000088bb004 CR3: 0000000079d66000 CR4: 0000000000000660
Jan 21 08:17:31 xxx kernel: Call Trace:
Jan 21 08:17:31 xxx kernel: ? switch_to_thread_stack+0x21/0x40
Jan 21 08:17:31 xxx kernel: Code: Bad RIP value.
Jan 21 08:17:31 xxx kernel: RIP: 0xffd9af11 RSP: ffffc900008cbfd0
Jan 21 08:17:31 xxx kernel: ---[ end trace 50c257ff957ddb5c ]---

Die sind vom Kernel 4.14.14, also von gestern 🙂 und wie man an dem Datum sehen kann, sind die Kernel OOPS von heute morgen. Die Beschreibungen die gleich kommen, sind extra simple gehalten, da wohl die wenigsten wissen, was ein IP oder eine NULL POINTER Dereferenz ist. Wer schonmal in Assembler programmiert hat, dem wird das sofort was sagen, dem Rest eher nicht 🙂

Ein Opcode ist eine definierte Bitfolge, welche die CPU als Assemblerbefehl interpretiert und dann macht, was der Befehl meint.

„invalid opcode: 0000 [#4] SMP NOPTI“

Meint, daß die CPU über eine Anweisung gestolpert ist, die nicht definiert ist, in dem Fall eine 0x0000 = 0W . 0W meint den Wert Null (0) auf einer Bitbreite von 16 Bit (= 1 WORD daher das W von 0W => 00000000 00000000. 0L wäre Null(0) auf 32bit auch bekannt als LONGWORD = 00000000 00000000 00000000 00000000).

Das kann nur passieren, wenn ein IP ( Instruction Pointer ) im Speicher wohin gezeigt hat, wo „NICHTS“ war. Das da NICHTS war, war gut so, weil sonst hätte die CPU womöglich die dortigen Bits&Bytes als Befehle interpretiert und wäre Amok gelaufen.

Trivia: Wenn man eine CPU dazu bekommt, so einen Fehler zumachen während sie einen fremden Prozess(z.b. für root) ausführt UND bestimmen kann, WO im Speicher weitergemacht wird, hat man einen EXPLOIT geschafft, also einen ANGRIFF durchgezogen. Das ist dann immer das, was in den Medien landet 🙂

NULL pointer dereference

kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
kernel: IP: 0x99cf048
kernel: Oops: 0002 [#3] SMP NOPTI

Das ist eine NULL POINTER Exception. Da ist die CPU über einen falschen IP(siehe oben) zu einer Adresse im Speicher gesprungen, wo ein weiterer Zeiger(Pointer) hätte sein sollen, es stand aber nur „0L“  dort.

Das ist eigentlich ein Programmierfehler, denn man müßte Zeiger genau auf „0L“ prüfen, bevor man sie benutzt. Da stellt sich jetzt die Frage, reagiert der Kernel seit den Patchen empfindlicher auf den Fehler ( der womöglich schon seit Jahren da war) oder ist der Fehler durch den Patch entstanden?

IMHO:

Es zeigen sich jetzt lustige Programmierfehler in allen möglichen Sachen/Kernel, weil der schlampige Stil jetzt nicht mehr hinhaut 😀 In C und C++, worin die Masse des Kernelcodes und der Anwendungen geschrieben ist, gibt es das Konstrukt des Doppelzeigers, also einem Zeiger auf einen Zeiger. Natürlich gibt es dafür eine Abkürzung im C Code die auch gern genommen wird, nur daß dabei der Code nicht prüft, ob da 0 als Zeiger steht. Das würde nämlich Performance kosten und genau die will man ja damit erreichen. Der Code geht also davon aus, daß die Zeiger immer stimmen, also optimistische Grundeinstellung des Entwicklers. Seit dem Patch kann man sich da wohl nicht mehr drauf verlassen.

Fazit

Aber zurück zur Situation, wenn man unbedingt muß, kann man die 64Bit Kernel benutzen. Für daheim ist das eh kein Problem, so weit ich das von meiner Serverfarm ableiten kann, betrifft es nur VM und JAVA Prozesse (z.b. Jitsi / Tomcat usw.). Die 32Bit Kernel sind besonders anfällig und derzeit noch nicht zu empfehlen, aber wer braucht auch noch 32bit ?

Die meisten werden die neuen Kernel also ohne Probleme fahren können.

Wer den 4.14.14 Kernel für Fedora 26 haben will :  https://koji.fedoraproject.org/koji/taskinfo?taskID=24303894

Eure Distros werden ähnliche Buildumgebungen haben, wo die aktuellen Testkernel gebaut werden.

 

Signieren von npm Paketen

Zur Einleitung eine kleine Geschichte zu einem Projekt, daß ich mit einem unserer Kunden umgesetzt habe. Da das Projekt mangels Benutzer jüngst eingestellt wurde, ist wohl die Floskel „Es war einmal…“ angebracht 🙂

Die Geschichte von Lord Uglify

Also.. Es war einmal .. ein tolles webbasiertes Firmenspiel für das jede Menge Javascriptcode erzeugt wurde, weil es ja im Browser zu spielen war. Nun sollte das ellenlange Javascript eingedampft werden mit „Uglify“ einem node.js Tool zum Schrumpfen und Verschleiern von Javascriptcode.

Nun sollte jemand Uglify irgendwo installieren und es dafür benutzen. Das war der erste Fehler. Nachdem Node.Js aus dem Repository installiert wurde, tat es natürlich nichts sinnvolles, denn Uglify hat wie so viele andere Node.js Programme, einen Abhängkeitsbaum, der milde betrachtet, bis zum Mond reicht. Mit NPM, dem Node.Js Paketmanager, kann man die Abhängkeiten befriedigen, glaubten wir zumindest. Das war Fehler Nummer 2. Denn die Abhängigkeiten von den Abhängigkeiten der Abhängigkeiten von den Abhängigkeiten der Abhängigkeiten von den Abhängigkeiten die keine Ende nehmen wollten, brauchten geschlagene 30 Minuten sich zu installieren. Na gut, jetzt wird es ja wohl endlich starten. Das war der dritte Fehler.. allerdings dann auch der letzte, weil ich keinen Bock mehr hatte mich von so einem Witzprogramm verarschen zu lassen.

Ich habe dann einfach „jsmin“ genommen: klein,schnell,effektiv,läuft überall, keine Abhängigkeiten und einfachst zu bedienen. Kurzum, ein Programm wies sein sollte.

Was hat das jetzt mit dem Signieren von Paketen zu tun ?

Tja, wie man oben lesen kann, sind Node.js Programm extrem modularisiert, sprich, mal eben selbst was schreiben ist praktisch nicht, weil man erst mal jede Menge an Paketen installieren muß. Im Gegensatz zu Java, wo eine Fülle von Klassen mitgeliefert werden, kommen die Pakete per NPM ins Projekt rein.

Diese Pakete sind nicht signiert, die von Java zwar auch nicht, aber die kommen ja auch aus einer definierten Quelle gleich mit. Signieren ist im NPM auch nicht vorgesehen. Daher hat jemand in Australien ( Details bei Heise ) gemeint, er müßte das ändern und hat ein Signaturtool für Node.js Pakete gebaut.

Die Begründung war, das neulich diverse Pakete aus dem NPM Repo auf merkwürdige Art verschwunden sind, zwischenzeitlich durch gleichnamige Pakete ersetzt wurden, um dann funktional mit den früheren Paket  zu kollidieren, sprich, was anderes zu machen, als das Original.

Da jeder Pakete in das NPM Repo laden kann, würde das Signieren also den Prozess mit den Paket-Abhängigkeiten sicherer machen, weil wenn sich so ein Vorgang wie eben beschrieben passiert, würde ja die Signatur nicht mehr passen und dem Entwickler würde dann auffallen, daß da gerade was schief läuft. Nun, das mag sein.

Das eigentliche Problem

Das eigentliche Problem löst das natürlich nicht: 100 Abhängigkeiten im Projekt, und den von den Entwicklern hat noch nie einer gehört. Ob die da Schadcode einbauen oder nicht, kann man nicht an der Tatsache einer gültigen Signatur erkennen.
Alles was dieses Signaturen bieten, ist ein Verwechslungsschutz, das aber auch nur, wenn der lange verschollene Author doch nochmal gefunden wird 🙂

Ich halte das für nichts, was man an die große Glocke hängen sollte, denn das hier kann man damit nicht vermeiden:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

Es lohnt sich bis zum Ende zu lesen, weil Ihr sonst einen falschen Eindruck von der Sache bekommt. Wenn Ihr damit fertig sein, hier ein Zitat von „blog.fefe.org“ unser aller Weltverschwörungsguru 😉 passend zum Thema :

[l] Ein Einsender kommentiert die Webfrontend-Warnung:

  • lass‘ uns als kleine Veranschaulichung, wie breit und tief die Güllegrube npm sein kann, eine Webanwendung anfangen. Natürlich mit Angular und dem aktuellen Standard-Build-System @angular/cli:

    $ npm i @angular/cli
    $ node_modules/.bin/ng new webkid --directory=.

    Das Ergebnis ist ein Skeleton mit einer Hello-World-Seite und:
    31 direkten Abhängigkeiten
    974 Abhängigkeiten insgesamt
    305 MB in node_modules

    Davon sind 158 Pakete Duplikate von bereits installierten Paketen mit einer anderen Versionsnummer. Bei so vielen Abhängigkeiten ändern sich die Zahlen natürlich schnell, also am besten sofort anfangen mit dem Audit!“

    “ [Ende des Zitats]  Aufgrund der Struktur von Fefes Webseite, müßt Ihr selbst den „Wed Jan 10 2018“ suchen 😉

 

Dem Kommentar kann man sich nur anschließen. Keine Signatur der Welt macht das irgendwie sicherer!

Davon ab, keine Ahnung wie jemand auf die Idee kommt, dafür zu Entwickeln. Da braucht man ja Stunden um anzufangen. Leute nehmt was vernünftiges, nehmt Java. Eclipse auf. Neues Javaprojekt aufmachen und einfach losschreiben 😉

Java kommt übrigens leer mit knapp 105 MBye aus 😉 und das wäre dann auch für alle Projekte und nicht PRO Projekt 😀

Quelle: heise.de – Open Source Tool zum Signieren von npm Paketen veroeffentlicht