AsmBB: eine leichtgewichtige Web-Forum-Engine in Assemblersprache

 (asmbb.org)
3 Punkte von GN⁺ 2024-01-15 | 1 Kommentare | Auf WhatsApp teilen
  • AsmBB ist eine schnelle, leichtgewichtige Web-Forum-Engine von JohnFound, die dank ihrer Architektur auf Basis von Assemblersprache und SQLite den Betrieb eines Forums auch auf kleinen Servern ermöglicht
  • Auf x86-Linux-Servern werden sowohl 32 Bit als auch 64 Bit unterstützt; sie läuft ohne vorab installierte zusätzliche Bibliotheken auch auf VPS oder Shared Hosting mit FastCGI-Unterstützung
  • Bei der Sicherheit setzt AsmBB auf wenige Abhängigkeiten und internes Design; dazu kamen die verschlüsselte Datenbank SQLeet in v2.7 und die Unterstützung von SQLite3MultipleCiphers in v3.0
  • Der Funktionsumfang wurde um Themes, Template-Anpassung, MiniMag/BBCode, Anhänge, Threads mit beschränktem Zugriff, Echtzeit-Chat, Atom/RSS, SSE-Benachrichtigungen, mehrsprachige UI, YouTube-Einbettung und Thread-Ranking erweitert
  • v3.0 enthält inkompatible Änderungen an Datenbank- und Template-Struktur; beim Upgrade von v2.9.1 sind Entschlüsselung, Backup, Schemaänderungen sowie der Austausch der Binärdateien und von templates/ erforderlich

Architektur und Laufzeitumgebung von AsmBB

  • AsmBB ist eine Web-Forum-Engine; auch das Forum AsmBB.org läuft auf AsmBB
  • Sie ist vollständig in Assemblersprache geschrieben und nutzt SQLite als Datenbank-Backend
  • Hervorgehoben wird, dass auch schwache Hosting-Umgebungen viele Besucher ohne Verzögerung bedienen können
  • Die Laufzeitanforderungen sind eher niedrig
    • x86-Linux-Server erforderlich
    • Unterstützung für 32 Bit und 64 Bit
    • Keine speziell vorinstallierten Bibliotheken nötig
    • Auch auf dem kleinsten oder günstigsten VPS möglich
    • Bei FastCGI-Unterstützung auch auf Shared Hosting möglich
    • Ein Webserver mit Unterstützung für die FastCGI-Schnittstelle ist erforderlich
  • Getestete Webserver sind Nginx, Apache, Lighttpd, Hiawatha, RWASA

Sicherheit und verschlüsselte Datenbank

  • AsmBB strebt eine sichere Webanwendung an, gestützt auf internes Design und wenige Abhängigkeiten
  • Für höhere Sicherheit wird optional eine verschlüsselte Datenbank unterstützt
  • Die wichtigste Änderung in v2.7 ist die Unterstützung verschlüsselter Forum-Datenbanken
    • Verwendet wird das SQLite-Plugin SQLeet
    • Laut Spezifikation unterstützt es PBKDF2-HMAC-SHA256-Schlüsselableitung, 16-Byte-Salt und 12.345 Iterationen
    • Verwendung der ChaCha20-Streamchiffre und eines Einmalschlüssels
    • Verwendung von Poly1305-Authentifizierungs-Tags
  • Die Verschlüsselung kann im neuen Tab Encryption im Admin-Einstellungsbereich ein- und ausgeschaltet werden
  • Der Verschlüsselungsschlüssel wird nicht auf der Festplatte gespeichert, sondern nur temporär im RAM gehalten
    • Ziel ist eine Konfiguration, die eine Offenlegung der Forum-Datenbank, Kontoeigenschaften und persönlichen Daten verhindert, selbst wenn Webserver, Backup-Server und Backup-Medien schwer kompromittiert werden
  • Eine bekannte Einschränkung ist, dass der Verschlüsselungsschlüssel nach jedem Neustart der Engine erneut über das Webinterface eingegeben werden muss
    • Bei einem unbeabsichtigten Serverneustart kann der Zugriff auf das Forum für eine Weile blockiert sein
    • AsmBB beschreibt sich als langlebige und stabile Anwendung, bei der solche Situationen nur alle paar Monate oder Jahre auftreten
  • Bei Nutzung einer verschlüsselten Datenbank ist SSL/TLS zwingend erforderlich

Anpassung und Installationswege

  • AsmBB ermöglicht über ein Template-System die Anpassung des Forums, ohne den Code direkt ändern zu müssen
  • Das Binärpaket ist unter asmbb.tar.gz erhältlich; dieser Link verweist auf das aktuelle Binärpaket
  • Fortschritt verfolgen, Bugs melden und den Source klonen ist über das AsmBB source repository möglich
  • Die Installationsdokumentation für eigene Server wird als Tutorial zur Installation mit NGINX und systemd bereitgestellt
  • Mit RWASA ist eine Installation in unter 2 Minuten möglich; dazu gibt es ein Video-Tutorial und ein YouTube-Video

Aktuelle Änderungen am Forum

  • Im aktuellen Forum wurden die Themes Glass, Neumor, Poly, Brutal, Joly, Tailwind, Snes hinzugefügt
  • Das Einfügen von URLs über den MiniMag-Button verwendet den ausgewählten Text als Ankertext
  • E-Mail-Verifizierungen werden entsprechend der eingestellten Standardsprache verschickt
  • Es wurden Korrekturen rund um MiniMag vorgenommen
  • Eine page-Funktion für Kontaktseiten, TOS und Ähnliches wurde implementiert
  • Eine API wurde implementiert

Wichtige Änderungen in v3.0 und Hinweise zum Upgrade

  • v3.0 bringt mehrere neue Funktionen
    • Bilder können direkt eingefügt und als Anhänge hinzugefügt werden
    • Unterstützung für eingebettete YouTube-Videos
    • Einführung eines einheitlichen Beitrags-/Thread-Editors, der Code und Templates vereinfacht
    • Thread-Ranking hinzugefügt
  • Der Skin Modern wurde wegen niedriger Qualität aus dem Projekt entfernt
  • v3.0 enthält inkompatible Änderungen gegenüber früheren Versionen
    • Änderung der Datenbankstruktur
    • Änderung der Template-Struktur
  • Wegen der Einstellung des SQLeet-Projekts wurde Unterstützung für die Verschlüsselungserweiterung SQLite3MultipleCiphers hinzugefügt
    • Das Binär-Release-Paket wird mit dieser Erweiterung kompiliert
  • Gefundene Bugs und Schwachstellen wurden behoben
  • Beim Aktualisieren der Datenbank von v2.9.1 auf v3.0 ist die Reihenfolge wichtig
    • Vor Änderungen an der bestehenden Datenbank ist eine Entschlüsselung nötig
    • Die neue SQLite3MultipleCiphers-Bibliothek wird in einem Modus verwendet, der nicht mit der bisherigen SQLeet-Bibliothek kompatibel ist
    • Vor der Migration auf v3.0 kann die Datenbank entschlüsselt und anschließend mit der neuen Bibliothek wieder verschlüsselt werden
    • Für den Fall von Problemen ist ein Backup nötig
    • Das bereitgestellte SQL zur Schemaänderung muss in der SQLite-Konsole ausgeführt werden
    • Nach der Änderung des Datenbankschemas muss die Engine gestoppt werden, und die Binärdateien engine, ld-musl-i386.so und libsqlite3.so müssen ersetzt werden
    • Während die Engine gestoppt ist, muss das gesamte Verzeichnis templates/ durch die neue Version ersetzt werden
    • Nach dem Neustart der Engine sollte geprüft werden, ob es im aktualisierten Forum Probleme gibt
    • Wenn alles normal aussieht, kann die Datenbank auf der AsmBB-Einstellungsseite wieder verschlüsselt werden

Release-Verlauf von v2.x

  • v2.9: Urban Sunrise und Verbesserungen der Editor-Erfahrung

    • Das neue responsive Theme Urban Sunrise wurde hinzugefügt
    • Ziel ist eine Verbesserung des Erscheinungsbilds des Forums
    • Im Beitragseditor ist eine Formatierungshilfe integriert
    • Beitragseditor und Echtzeit-Chat unterstützen Unicode Emoji nativ
    • Unterstützung für Syntax-Highlighting von Quellcode über eine JS-Bibliothek
    • Der Echtzeit-Chat kann mehrzeilige Beiträge einschließlich Quellcode annehmen
    • Gemeldete Bugs in der AsmBB-Engine und der FreshLib-Bibliothek wurden behoben

  • v2.8: Bugfixes und Schutzfunktionen

    • Mehrere Bugs wurden behoben, darunter einige kritische
    • Das neue Theme Modern wurde hinzugefügt
    • Für seltene Fälle, in denen AsmBB die Anfragerate nicht bewältigen kann, wurde DDOS-Schutz implementiert
    • Für die MiniMag- und BBCode-Parser wurde ein URL-Analyzer hinzugefügt, um XSS-Angriffe über Nutzerlinks zu verhindern

  • v2.6: Deutsche UI und SSE-Erweiterung

    • Dies ist die erste offizielle Version mit deutscher UI-Übersetzung
    • Auch andere Übersetzungen wurden mit Hilfe der Community verbessert
    • Über Atom/RSS-Feeds kann das gesamte Forum, ein bestimmtes Tag oder ein bestimmtes Theme abonniert werden
    • Die Verarbeitung von Server-Sent Events (SSE) wurde von Grund auf neu geschrieben
    • SSE kann nun nicht nur für Echtzeit-Chat, sondern auch für Benachrichtigungen über verschiedene Forum-Ereignisse wie neue Beiträge und Nutzeraktivität verwendet werden
    • Alle Clients werden in einem einzelnen Thread verarbeitet, wodurch viele Besucher gleichzeitig bei geringer Serverlast bedient werden können
    • Die neuesten Versionen von SQLite und der MUSL-Bibliothek sind im Binärpaket enthalten

  • v2.5: Mehrsprachige UI und BBCode

    • Internationalisierung der Benutzeroberfläche wurde eingeführt
    • Nutzer können die Sprache der Forum-UI auswählen
    • Die angebotenen Sprachen sind English, Bulgarian, Russian, French
    • Als zweite Markup-Sprache wurde ein BBCode-Parser hinzugefügt, sodass sowohl MiniMag als auch BBCode verstanden werden
    • BBCode hilft beim Erstellen von Skripten für Migrationen aus anderen Forum-Engines
    • E-Mails können über externe Programme wie sendmail versendet werden

  • v2.4: Anhänge, eingeschränkter Zugriff und Chat-Performance

    • Dateien können an Beiträge angehängt werden, und die Berechtigung für Anhänge wird pro Nutzer verwaltet
    • Limited access threads ermöglichen es dem Thread-Eigentümer, eine Liste zugriffsberechtigter Nutzer festzulegen
    • Nutzerberechtigungen können auf der Admin-Seite bearbeitet werden
    • Berechtigungen für anonyme Nutzer können separat festgelegt werden, sodass geschlossene Foren erstellt werden können, die nur registrierte Nutzer lesen können
    • Der Echtzeit-Chat-Dienst wurde so refaktoriert, dass alle Verbindungen in einem einzelnen Thread verarbeitet werden
    • Nach Optimierungen am Template-Rendering-Engine, am Datenbankschema und an SQL-Requests ist AsmBB etwa 20 % schneller als frühere Versionen

  • v2.3: Wartung und Barrierefreiheit

    • Ein Wartungs-Release, das zwei schwerwiegende Bugs behebt
    • Aus Gründen der Barrierefreiheit wurden Hintergrundbilder durch <img>-Tags mit alt-Text ersetzt
    • Das Forum ist auch nutzbar, wenn Bilder deaktiviert sind
    • Der JS-Code für den Chat wurde bereinigt und etwas schneller gemacht

  • v2.2 und v2.1: Login, Wiederherstellung und Navigation

    • Enthält dauerhafte Anmeldung, Passwortzurücksetzung, Nutzerliste und Chat-Verbesserungen
    • Dauerhafte Anmeldung ist standardmäßig deaktiviert
    • Die Passwortzurücksetzung erfordert eine gültige E-Mail-Adresse und ist über einen Link im Login-Formular erreichbar
    • v2.2 fügt eine auf dem Tag-System basierende Categories-Navigation hinzu
    • Funktionen zur Aufbewahrung und Wiederherstellung der Bearbeitungs-/Löschhistorie von Beiträgen wurden hinzugefügt

  • v2.0: Performance und Codesicherheit

    • Der Template-Renderer render.asm wurde durch render2.asm ersetzt
    • Die neue Implementierung nutzt stärker assembly-typische Algorithmen, ist schneller und verbraucht weniger Speicher
    • Ketten von Stringvergleichen beim URL-Parsing wurden durch eine Hash-Tabelle ersetzt
    • Die Geschwindigkeit von AsmBB wurde ungefähr verdoppelt
    • Schwachstellen, die mit Testwerkzeugen wie OWASP ZAP und Tinfoil security gefunden wurden, wurden behoben
    • Ressourcen- und Speicherlecks, die bei intensivem Fuzzing und quasi-DDOS-Lasttests gefunden wurden, wurden behoben
    • Ein Debugging-Tool wurde implementiert, das Ressourcen- und Speicherallokationen sowie -freigaben sammelt und als Webseite berichtet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-15
Hacker-News-Meinungen

  • Das ist wirklich cool, aber der folgende Satz wirkt sehr fragwürdig:
    „AsmBB ist dank seines internen Designs und der reduzierten Abhängigkeiten eine sehr sichere Webanwendung.“
    Es hat großen Wert, gut geprüfte Abhängigkeiten zu nutzen, und selbst Chuck Norris würde Bugs produzieren, wenn er komplexe Software in Assembly schreibt.
    Besonders dann, wenn wie bei diesem Projekt viel String-Verarbeitung nötig ist.

    • Genau derselbe Gedanke kam mir als Erstes, als ich den Titel sah.
      Dasselbe Gefühl hatte ich auch, als es früher einmal als CTF-Aufgabe auftauchte, bei der einfach die aktuelle Version dieses Projekts gehostet wurde; während des Wettbewerbs wurden mindestens 8 Schwachstellen gefunden.
      https://ctftime.org/task/24399
    • Der Satz hat mich auch etwas gestört. Normalerweise wirkt so eine Behauptung wie ein Warnsignal, aber der ursprüngliche Autor scheint kein englischer Muttersprachler zu sein und hat vielleicht übersehen, dass man die Formulierung etwas abschwächen sollte.
      Etwa „AsmBB legt beim Design Wert auf Sicherheit und ist weniger abhängig von Dependencies“ wäre wohl besser gewesen.

  • Gefällt mir, und beeindruckend, dass es konsequent in Assembly umgesetzt wurde. Weniger Abhängigkeiten reduzieren zwar die Angriffsfläche, aber allein dadurch kann man es nicht als „sicher“ bezeichnen.
    Statistisch senkt das die Wahrscheinlichkeit von Exploits, aber Assembly bietet keinerlei Speichersicherheit oder andere Garantien und kann das Risiko daher auch erhöhen.
    Ich kann nicht sagen, welche Seite stärker wiegt, aber Assembly-Anwendungen haben trotzdem ihren Reiz. Als Bonus könnte man es nach aarch64 transpilen und dann einen Pi Zero oder Pi W in einen Wandadapter stecken und darauf laufen lassen.
    Nebenbei habe ich mich immer wieder mit verteilten Foren beschäftigt. Nachdem Usenet verdrängt wurde, sind solche Foren zum Mainstream geworden, aber ein Ersatz sollte meiner Meinung nach sowohl die Verteilungs-/Replikationsfunktionen von Usenet als auch die User Experience von phpBB mitbringen.
    Es verteilt und eventual consistent zu machen, ist eine großartige Aufgabe für verteilte Systeme und macht als Puzzle Spaß. Falls jemand etwas Ähnliches gebaut hat, würde ich es sehr gern sehen.

    • Ich denke, die Kombination aus Assembly und Linux-Kernel-ABI kann sicherer sein als der traditionelle C/C++-Stack, weil man deutlich weniger undefiniertem Verhalten ausgesetzt ist.
      Signed Integer Overflow und Underflow verhalten sich wie erwartet, und mit mmap + MAP_ANONYMOUS allozierter Speicher wird wie erwartet mit Nullen initialisiert.
      Greift man auf nicht gemappte Adressbereiche zu, einschließlich Adresse 0, bekommt man wie erwartet SIGSEGV.
      Ein Assembler trifft viel weniger Annahmen als ein C-Compiler und versucht weniger clever zu sein, daher ist es wahrscheinlicher, dass etwas bei einem Fehler sofort kracht, statt stillschweigend Erwartungen zu verletzen.

  • Laut Footer ist die Verarbeitungszeit absurd schnell. Aber es dauert 500–1000 ms, bis das Dokument nach Dänemark übertragen ist.
    In diesem Fall wäre ein CDN wohl besser als besonders performanter Code, aber es ist trotzdem eine beeindruckende Arbeit.

    • Selbst von den Azoren mitten im Atlantik aus wurde es in unter 500 ms geladen.
    • Aus meiner Sicht als jemand, der bei einem großen Tech-Unternehmen Verbesserungen der Antwortzeiten vorangetrieben hat, tut 1 Sekunde schon ziemlich weh.
      Natürlich dürfte die Übertragungszeit einen großen Anteil ausmachen, aber wenn das als „gut“ gilt, wirkt das etwas schwierig.

  • Ich frage mich, wie man aus Assembly-Code eine Verbindung zur Datenbank herstellt. Gibt es so etwas wie Assembly-Bibliotheken?
    Theoretisch verstehe ich es, aber der Aufwand, solche „einfachen“ Dinge selbst zu schreiben, dürfte enorm sein.

    • Es ist weniger kompliziert, als man denkt. Man folgt der C-Aufrufkonvention und ruft die Funktionen der SQLite-C-Bibliothek auf.
      Der relevante Code ist hier: https://asm32.info/fossil/asmbb/file?name=source/sqlite3.asm...
    • C wird normalerweise auch zuerst nach Assembly kompiliert.
      In Assembly zu programmieren bedeutet im Grunde, die Arbeit des Compilers selbst zu erledigen, und man kann dieselben Bibliotheksfunktionen aufrufen, die auch C-Code aufrufen kann.
      Man muss allerdings die Aufrufkonvention der jeweiligen Architektur einhalten, was umständlich und mühsam ist, aber keineswegs nahezu unmöglich.
      x64 ist bei Funktionsaufrufen lästiger geworden, weil zuerst Register verwendet werden und erst danach auf den Stack ausgewichen wird. x32 war viel bequemer, weil es nur den Stack nutzte, aber die x64-Konvention kann schnelleren Code erzeugen, weil Werte in Registern gehalten werden.
    • Da die Datenbank SQLite ist, sieht es so aus, als würde einfach gegen die SQLite-Bibliothek gelinkt.

  • Es ist nicht nur in Assembly geschrieben; dahinter steckt auch SQLite. Wie bei vielen Anwendungen dürfte der Engpass eher I/O als die CPU sein.

    • Oft nimmt man an, die Sprache sei der Engpass, während tatsächlich I/O oder das Datenbankdesign der Flaschenhals ist.
      Natürlich verstehe ich angesichts des PHP-Codes, den ich gesehen habe, warum sich das so anfühlt. Aber das ist eher eine Frage der Nutzung als der Sprache selbst.
    • Auch RAM ist ein Faktor. Ich habe einige Programme in C für Arduino geschrieben, bei denen Stack und C-Aufrufkonvention völlige Verschwendung waren und die gut zu Assembly gepasst hätten. Zum Beispiel Fälle ganz ohne rekursive Funktionen.
      Das Problem ist die Portabilität. Ich mag AVR-8, aber wenn die Anforderungen wachsen, gibt es für AVR-8 kaum einen Weg weiter, außer vielleicht als FPGA-Softcore.
      Mit C kann man auf ARM-Mikrocontroller wechseln, was persönlich weniger Spaß macht, aber bessere Performance liefert.
      Das Problem von AsmBB ist ebenfalls, dass es an eine bestimmte Architektur gebunden ist.
    • Gilt das auch im WAL-Modus, wenn PRAGMA synchronous auf NORMAL steht? Ich bin überhaupt kein SQLite-Experte und schaue es mir gerade für ein Projekt an.

  • Dort heißt es außerdem, Unicode-Emoji-Zeichen würden „wirklich nativ“ unterstützt; dazu hätte ich mir eine genauere Erklärung gewünscht
    Ich weiß nicht so recht, was „wirklich nativ“ bedeuten soll, und unklar ist auch, worin der Unterschied zu einer „ein bisschen nativen“ Unterstützung bestehen soll

    • Im Assembly-Code von AsmBB scheint es keinerlei Emoji-Verarbeitung zu geben, es sieht also eher danach aus, als würden sie nahezu unverändert durchgereicht
      Allerdings hebt der Live-Chat Emojis in JS-Code hervor, der Teil des Templates ist:
      function formatEmoji(text) {
      var emojiRegEx = /(\u00a9|\u00ae|[\u2000-\u3300]|\ud83c[\ud000-\udfff]|\ud83d[\ud000-\udfff]|\ud83e[\ud000-\udfff])/g;
      return text.replace(emojiRegEx, '$1');
      }
      Vermutlich sollte damit U+00A9, U+00AE, U+2000..3300 und U+1F000..1FBFF erfasst werden, aber selbst das ist schon viel zu breit, und auch der reguläre Ausdruck ist keine vollständige Umsetzung
      Wenn man die korrekte Lösung sucht, kann man emoji-regex [1] oder das neuere Pattern /\p{RGI_Emoji}/v [2] verwenden
      [1] https://unpkg.com/browse/emoji-regex/index.js
      [2] https://caniuse.com/mdn-javascript_builtins_regexp_unicodese...
    • Nur eine Vermutung, aber manche Websites wie Twitter verwenden ein eigenes Emoji-Set; hier könnte gemeint sein, dass man genau das nicht tut, sondern das Standard-Emoji-Rendering des Betriebssystems nutzt

  • Im Header gibt es einen Button, um Live-Benachrichtigungen auszuschalten
    Nebenbei: Nicht angemeldeten Besuchern eine Liste der Forennutzer zu zeigen, wirkt nicht besonders gut. Ist das konfigurierbar?

    • Auf Mobilgeräten konnte ich keinen Button finden, um Live-Benachrichtigungen auszuschalten
    • Foren waren früher ohnehin so, und vermutlich ist es auch konfigurierbar

  • Konzept und Umsetzung sind wirklich gut. Allerdings werden die Live-Benachrichtigungen schnell überwältigend viele, daher bräuchte es wohl irgendeine Form von Rate Limiting

    • Dinge wie @User123 has entered the thread hätten in kleinen Foren, in denen sich alle kannten, gut gepasst
      Aus demselben Grund zeigten phpBB/vBulletin eine Liste „Benutzer, die diesen Thread lesen: ...“ an, und es gab auch beliebte Plugins, die anzeigten, dass @Foo und @Bar gerade eine Antwort in diesem Thread verfassen
      Gerade bei hitzigen Diskussionen ließ das den Raum lebendiger wirken, und es hatte auch etwas für sich zu wissen, dass die Gegenseite gerade den nächsten langen Beitrag schreibt, der die eigene Aussage Zitat für Zitat widerlegt
      Aber jedes Mal eine Benachrichtigung zu bekommen, wenn ein nicht registrierter Gast einen Thread anklickt, wirkt für niemanden nützlich
    • Über das Glocken-Icon kann man Live-Benachrichtigungen ausschalten

  • Man könnte etwas Ähnliches auch in C bauen und auf die Standardbibliothek verzichten. Man könnte es so machen, dass es außer Systemaufrufen keine Abhängigkeiten gibt
    Abgesehen vom intellektuellen Training sehe ich keinen zwingenden Grund, das unbedingt in Assembly zu machen

  • Im Titel fehlt, um welche Assembly es geht, und sogar, auf welchem Betriebssystem es läuft
    „x86 asm“ plus „on linux“ ist auch nicht länger als „assembly language“