KomplexitĂ€t đŸ€œđŸ€› IT Sicherheit: 2 interessante Beispiele

BeschĂ€ftigt man sich regelmĂ€ĂŸig mit IT Sicherheitsthemen – etwa in dem man jede Woche den Security Now Podcast hört – gibt es immer wieder Momente in denen man völlig davon ĂŒberzeugt ist, dass das Internet nur von Kaugummi und Klebeband zusammengehalten wird. Aber oft sind es auch Themen, die tief in die unheimlich komplex gewordenen Infrastukturen und Technologien fĂŒhren, mit denen wir tĂ€glich hantieren. Das sind zwei Beispiele aus den letzten Wochen, die ich besonders spannend fand:

Trojan Source – UTF-8 und Tricks mit dem bidi Encoding 🔀

Aus Security Now 843: Zwei britische Forscher haben ein spannendes Paper mit dem Titel ‚Trojan Source: Invisible Vulnerabilities‚ veröffentlicht, welches im Endeffekt diese Kernaussage hat:

Bei der PrĂŒfung eines Programmcodes kann man nicht mehr davon ausgehen, dass der Code, den man vor sich auf dem Bildschirm sieht, der gleiche Code ist, der spĂ€ter vom Compiler ‚gesehen‘ und in ein Programm ĂŒbersetzt wird

So wie das Trojanische Pferd auch nicht das war, was es zu sein schien…Wenn man darĂŒber einen Moment nachdenkt zieht es einem nach und nach das Fundament unter dem FĂŒĂŸen weg, auf dem die ÜberprĂŒfung von SoftwarequalitĂ€t und -sicherheit von jeher stand:

Ein Mensch schaut sich in einem Editor den Quellcode, den ein anderer Mensch – oder inzwischen auch eine Maschine – geschrieben hat, versucht ihn zu verstehen und vergleicht ihn mit der Funktion, die der Code laut Pflichtenheft oder Eigenbeschreibung oder Stack Overflow Kommentar haben soll.

Im Paper werden nun unterschiedliche Verfahren beschrieben, wie man in Quellcode, der als Unicode gespeichert ist, subtile TĂ€uschungen einschmuggeln kann. Und dabei kommt die KomplexitĂ€t moderner Zeichensatzcodierungen, die den Anspruch haben letztlich jedes relevante Schriftsystem der Welt – und möglicherweise auch extraterrestrische – korrekt darstellen zu können, uns die Quere:

Neben vergleichsweise simplen Ticks wie dem EinfĂŒgen von breitenlosen und damit unsichtbaren Leerzeichen (Zero Width Space ZWSP), die Stringvergleiche scheitern lassen können, oder der Verwendung von Homoglyphen, die etwa zur EinfĂŒhrung alternativer Methodenaufrufe genutzt werden können, sind es die Nutzungen der Bidirectional Commands und davon gibt es einen ganzen Block:

Tabelle mit den UTF-8 Zeichen fĂŒr Richtungswechsel. Quelle: https://www.w3.org/International/questions/qa-bidi-unicode-controls

Die lassen sich sogar verschachteln und Àhnlich wie bei einem Stack in der Programmierung gibt es POP Anweisungen um Verschachtelungen wieder zu beenden und damit eine Schachtelungsebene nach oben zu gehen:

Tabelle mit den UTF-8 Zeichen fĂŒr Richtungswechsel. Quelle: https://www.w3.org/International/questions/qa-bidi-unicode-controls

Gerade mit dem Isolates, die komplette Gruppen von Zeichen als gemeinsames Element behandeln, und Kombinationen von BiDi Anweisungen lassen sich leicht FĂ€lle konstruieren, bei denen etwas, dass im Quellcodeeditor so aussieht:

...
/* Wenn SicherheitsprĂŒfung bestanden, dann return; */
if (check == true) 
     return;
else 
     throw new Exception("Keine Berechtigung!");

fĂŒr den Compiler hingegen so erscheint:

...
/* Wenn SicherheitsprĂŒfung bestanden, dann */ return;
if (check == true) 
     return;
else 
     throw new Exception("Keine Berechtigung!");

Hier wird also aus dem scheinbaren Kommentar am Ende eine Programmanweisung, die die Logik komplett aushebelt. Das solche subtilen Änderungen manchmal weitreichende Probleme verursachen, dafĂŒr ist der goto fail;-Bug ein gutes Beispiel, den Apple vor Jahren in seinem Betriebssystem hatte. Hier sah der fehlerhafte Abschnitt so aus:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
	goto fail;
	goto fail;

Richtig wÀre aber diese Variante gewesen:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
	goto fail;
goto fail;

Die dritte Zeile durfte also nicht eingerĂŒckt sein. Manchmal reicht schon ein TAB um den Unterschied zu machen und in diesem Fall gab es Vermutungen, dass vielleicht jemand dafĂŒr bezahlt worden sein könnte diesen subtilen Fehler an einer entscheidenden Stelle einzubauen. Das Risiko der Entdeckung wĂ€re gering gewesen und man hĂ€tte sich leicht damit herausreden können, dass es sich um einen Tippfehler gehandelt hat. Mit Hilfe der BiDi-Trickserei wĂ€re dieser Fehler nicht einmal bei einem sehr sorgfĂ€ltigen Code Review sichtbar gewesen.

Da die Forscher bereits reale Beispiele fĂŒr die Anwendung dieser Technik gefunden haben ist das keine rein theoretische Bedrohung. Da sich solcher Code sogar per Copy-and-Paste ĂŒbernehmen lĂ€sst sind beliebte Vorgehensweisen in der modernen Softwareentwicklung ebenfalls gefĂ€hrdet. Also noch mehr gefĂ€hrdet, als sie es immer schon waren 🙈

Was kann man tun?

GrundsĂ€tzlich wird man wohl abwarten mĂŒssen bis die Werkzeuge wie Editoren, Compilier und vielleicht auch Linter sich dieses Problems annehmen. Bis dahin gibt es vielleicht diese Faustformeln:

  • Gerade in den Quellcode eingebrachte Texte wie Kommentare und Strings sind Einstiegspunkte fĂŒr diese Art von Angriff
  • Die Auswirkung der bidi-Tricksereien enden beim nĂ€chsten Zeilenumbruch. Eine einheitliche Quellcodeformatierung, die z. B. eingebettete Kommentare nicht in der gleichen Zeile stehen lĂ€sst wie Code, kann ein paar Varianten vermutlich aushebeln
  • Bei der Nutzung von fremden Programmcodes muss man noch stĂ€rker als bisher schon auf deren QualitĂ€t achten. Was immer schon notwendig, und immer schon schwierig war

HTTP Request Smuggeling đŸ§±â›ïž

Aus Security Now 846: Auch dieses Problem wird durch KomplexitÀt verursacht, aber auf einer ganz anderen Ebene: Hier geht es darum, dass zwei oder mehr hintereinander geschaltete Webserver, die am Bedienen eines Webrequests beteiligt sind, das dabei verwendete HTTP Protokoll nicht einheitlich interpretieren.

Und im Endeffekt unterschiedliche Vorstellungen davon haben, welche Webrequests sie eigentlich gerade verarbeiten.

Dieses Problem ist kein ganz neues Problem, aber heute noch relevanter, da es inzwischen gÀngige Praxis ist, dass mehr als ein Server am Ausliefern einer Seite beteiligt ist:

  • Proxy Server werden vor den eigentlichen Applikationsserver geschaltet, um die Last zu verringern
  • Webserver wie Apache oder nginx liegen vor den Applikationsservern um TLS zu terminieren oder Loginfunktionen – z. B. Shibboleth – zu ĂŒbernehmen
  • Loadbalancer sind Netzwerkkomponenten, die die Zugriffe auf nachgelagerte Server verteilen, um Lasten gleichmĂ€ĂŸig verarbeitbar zu machen
  • Dienste wie Cloudflare bieten ihren Kunden durch vorschaltete Systeme Schutz vor Denial of Service Angriffen, die eigentlichen Server sind nicht mehr direkt erreichbar
  • Und alle denkbaren Kombinationen davon….

FĂŒr die effiziente Kommunikation zwischen diesen Servern werden verschiedene Webrequests gerne hintereinander gehĂ€ngt, damit sie sich schnell ĂŒber die gleiche Verbindung ĂŒbertragen lassen.

Aber wie schafft man es dem einen Server etwas anderes vorzugaukeln, als dem spĂ€ter drankommenden Server? In dem man die zwei Optionen, die der HTTP Standard als Mittel bietet um die LĂ€nge eines Request zu definieren – und damit bei hintereinander gehĂ€ngten Requests zu definieren, wo der eine aufhört und der andere beginnt – so trickreich nutzt, dass die beteiligten Server zu unterschiedlichen Ansichten darĂŒber gelangen, wo die Grenze zwischen zwei Requests liegt. Auch wenn es laut dem Standard eigentlich klar wĂ€re, wie vorzugehen ist:

“According to the HTTP/1.1 standards, if both Content-Length and Transfer-Encoding headers are passed, Transfer-Encoding takes precedence.”

Quelle auf Medium

Auf diese Weise kann es bei anfĂ€lligen Serverkombinationen – und laut diesem Paper sind das viele – gelingen einen Zugriff auf einen Backend Server abzusetzen, der eigentlich von den davor geschalteten Servern gefiltert werden sollte. Das kann insbesondere dann relevant sein, wenn die vorgeschalteten Server das Login- und Rechtemanagement ĂŒbernehmen.

FĂŒr eine bestimmte Variante des Request Smugglings vulnerable Serverkombinationen laut diesem Paper

Auch hier ist es nicht leicht etwas zu tun. Wie immer muss man natĂŒrlich seine Server aktuell halten, so gibt es z. B. fĂŒr Tomcat inzwischen einen Patch fĂŒr CVE-2021-33037, der auch mit HTTP Request Smuggeling zu tun hat. Aber auf das Verhalten vieler Komponenten, wie z. B. Loadbalancer, hat man wenig bis keinen Zugriff.

Eine Lösung ist es vielleicht die kritischen Entscheidungen einer Applikation – also die Rechte- und Zugriffskontrolle – möglichst weit nach hinten zu verlagern, bis in die Applikationsserver. Das nimmt einem Optimierungsmöglichkeiten, aber dafĂŒr ist der Server, der am Ende die Requests verarbeitet, auch derjenige, der entscheidet welche Requests zulĂ€ssig sind.

Der IE geht – eine kurze Erinnerung an die Browserkriege ⚔

Das die Tagesschau ĂŒber Software berichtet ist in einer Zeit, in der die IT die Gesellschaft allmĂ€hlich völlig durchdrungen hat, nicht ungewöhnlich. Aber wenn es um eine so alte Software geht dann doch: Der Internet Explorer geht in Rente und das nach einer 25-jĂ€hrigen Geschichte.

Logo des Internet Explorers

Ich kann mich nicht mehr erinnern jemals ein aktiver Nutzer des IEs gewesen zu sein und bilde mir heute ein nach ersten Schritten im WWW mit Mosaic im Studium relativ schnell auf den Netscape Navigator gewechselt zu haben, und dann ohne ‚Umweg‘ auf das freie Folgeprodukt Mozilla Firefox. Seit dem Erscheinen von Google Chrome ist dies bis heute mein Hauptwebbrowser.

Aber als Webentwickler kam man lange nicht am Internet Explorer vorbei, jedenfalls fĂŒr die Zeit, in welcher der IE – insbesondere in der ‚ewigen‘ Version 6 – die absolute Dominanz im Web hatte:

Graphik Browser Wars, Von Wereon - Image:Browser Wars.png, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1128061
Von Wereon – Image:Browser Wars.png, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1128061

Bis 2002 hatte Microsoft mit seinem Browserprodukt durch die spĂ€ter von Gerichten bestrafte BĂŒndelung mit dem Windows Betriebssystem den zuvor dominierenden Netscape Browser vom Markt gedrĂ€ngt, damit den ersten Browserkrieg gewonnen und danach die Weiterentwicklung faktisch eingestellt und so die Fortentwicklung des Webs quasi eingefroren. FĂŒr viele Webentwickler*innen war es daher die einfachste Lösung Webseiten zu entwickeln, die sich nur auf diese Webbrowser konzentrierten. Noch heute findet man Seiten mit diesem damals allgegenwĂ€rtigem Hinweis:

Webseite mit dem Hinweis 'The layout of these pages is optimized for Internet Explorer 800 x 600'

In Deutschland war die Dominanz nie ganz so stark, insbesondere nicht im Umfeld der Hochschulen, da sich hier viele Verfechter von Open Source Produkten fanden und finden, und daher Firefox teilweise bis heute der Standardwebbrowser ist. Trotzdem konnte es einem auch in den 2010er Jahren noch passieren einem Bankberater gegenĂŒber zu sitzen, der den Kreditvertrag in seiner Bankingsoftware in einer alten Version des Internet Explorers bearbeitete, da gerade im Finanzbereich die proprietĂ€re ActiveX Technologie, die sich nur im IE nutzen ließ, im Einsatz war.

Auch der 2. Browserkrieg ist vorbei

Mit dem Aufstieg von Chrome begann der 2. Browserkrieg, der ebenfalls schon lange beendet ist, wie ein Blick in die heutige Verteilung der Webbrowsernutzung zeigt:

Verteilung der Webbrowser Nutzung

By StatCounter generated image - https://gs.statcounter.com/browser-market-share#monthly-202011-202011-bar, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=96191667
By StatCounter generated image – https://gs.statcounter.com/browser-market-share#monthly-202011-202011-bar, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=96191667

Microsoft hat nach letzten, gescheiterten Versuchen mit einem eigenstÀndigen Browserprodukt die alte Dominanz zu erhalten mit dem aktuellen Edge Browser ebenfalls auf die Chromium Basis aufgesetzt, wie es der Opera Browser bereits seit 2013 tut. Jenseits der Apple Welt sind damit die Chromium-Browser heute Àhnlich dominant, wie es vor langer Zeit der IE war. Allerdings ohne den Versteinerungseffekt, nun wird das Web in 6-Wochen-Zyklen weiterentwickelt, bald sogar alle 4 Wochen.

Tomcat 10 bringt EE9 – und den Big Bang weg von javax.servlet.*

Bei der kleinen Docker-Bastelei im Anti-DoS-Valve-Projekt wollte ich das Projekt ‚gerade mal eben‘ auf Tomcat 10 hochziehen und bin direkt ĂŒber eine wesentliche Änderung gestolpert, die mir bisher entgangen war:

Was bisher

import javax.servlet.*;

war muss nun

import jakarta.servlet.*;

sein 😼 Da sich das mit meinen Gehversuchen mit Docker ĂŒberschnitt hat es einen Moment gebraucht um zu verstehen, wo eigentlich das Problem lag…

Was ist der Hintergrund

NatĂŒrlich das Urheberrecht und Oracle’s Wille die mal mit dem Kauf von SUN an Java gewonnenen Rechte auf keinen Fall Preis zu geben. Die entscheidenden Weichenstellungen sind dabei schon weit vor der Niederlage gestellt worden, die Oracle letztlich Anfang April 2021 in der Auseinandersetzung mit Google ĂŒber die Java Nutzung in Android erlitten hat. Hier sind ein paar Quellen:

Der Artikel der Eclipse Foundation enthĂ€lt diese Passage, die das Ende der Verwendung von javax.* ankĂŒndigt:

‘..Eclipse and Oracle have agreed that the javax package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications.’

Selbst der Name Java darf nicht mehr in den Spezifikationen wie JPA verwendet werden, die die Eclipse Foundation weiterentwickelt. Bei der Frage wie es nach EE8 weitergehen kann deutet sich die Entwicklung schon an:

‘What happens beyond Jakarta EE 8?

The guiding principle for Jakarta EE 9 will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.  This will most likely involve two key topics: migration of some or all of the Jakarta EE specification source to a new namespace for future evolution; means to provide backwards compatibility with javax at a binary level, allowing old applications to run on Jakarta 9 implementations with some form of build or runtime tooling.

So while there will be a point in time where future versions of specifications will have to go through a source code incompatible change with respect to the previous javax based packages, this will be a straightforward transformation.’

Eine Frage war es dann ob die Migration weg von javax.* inkrementell erfolgen wĂŒrde – also nur der Teile, die VerĂ€nderungen unterliegen – oder als Big Bang gemacht wird. Die Antwort liefert der vergleichende Blick in die Javadocs der Servlet 4 und 5 APIs:

Der Post Jakarta EE 9 Delivers the Big Bang im Life at Eclipse Blog beschreibt das Vorgehen noch einmal zum Start von EE9. Die Logik dahinter – es wird ein klarer Schnitt gemacht – finde ich durchaus nachvollziehbar. Aber was macht man nun mit Anwendungen, die auf großen Codebasen sitzen und diverse externe Pakete verwenden, die alle noch nicht umgestellt sind?

Was tun mit den Altanwendungen (in Tomcat)

Alles was vor EE9 an Webanwendungen entwickelt wurde ist damit nun plötzlich eine migrationsbedĂŒrftige ‚Altanwendung‘. Aber selbst die BefĂŒrworter*innen des Big Bangs erkennen an, dass das JEE Ökosystem einfach zu groß ist, als das man innerhalb kĂŒrzester Zeit von allen Anbieter*innen von Servern, Anwendungen, Paketen ein Mitziehen erwarten könnte. Es sind also Übergangslösungen gefragt.

In des Migrationshinweisen von Tomcat 10 widmet sich ein eigener Abschnitt dem Thema und es zeigt sich, dass das Tomcat Migration Tool for Jakarta EE, welches im Kern den Eclipse Transformer enthÀlt, hier eingebaut ist und man seine Anwendungen offenbar ohne Umbauten weiterhin deployen kann. Aber nicht mehr in der gewohnten Weise:

Bei einem Test mit einer winzigen JEE Anwendung (nur ein Servlet) in deren pom.xml die Servlet API 4 referenziert wird

                <dependency>
                        <groupId>javax.servlet</groupId>
                        <artifactId>javax.servlet-api</artifactId>
                        <version>4.0.1</version>
                        <scope>provided</scope>
                </dependency>

scheint das Deployment durch Kopieren der WAR-Datei in den <CATALINA_HOME>/webapps-Order zunĂ€chst wie gewohnt zu arbeiten, die Datei wird entpackt und die statische Startseite wird im Browser angezeigt. Der Aufruf des Servlets scheitert aber mit einer 404-Meldung, jedoch ohne eine Fehlermeldung in den Tomcats-Logs đŸ€”

Das Deployment funktioniert erst, wenn man wie in der Migrationshilfe beschrieben einen <CATALINA_HOME>/webapps-javaee-Order anlegt und die WAR Datei dort platziert. Dann passiert beim Start das hier:

Tomcat 10 migriert beim Start eine EE8 Anwendung nach EE9

Tomcat bemerkt die ‚Altanwendung‘ und migriert sie in die neue Welt. Das Ergebnis befindet sich dann im ĂŒblichen <CATALINA_HOME>/webapps-Order. Bei der Minianwendung hat das problemlos funktioniert. Die spannende Frage ist dann wie es sich mit komplexeren Anwendungen verhĂ€lt.

Noch nicht klar geworden ist mir aber ob man bei der Weiterentwicklung von Altanwendungen nun erst einmal auf Tomcat Versionen <10 festgelegt ist, oder ob es auch da einen Weg gibt mit dem aktuellen Tomcat weiter zu machen.

Fazit

Das sich die Eclipse Foundation dazu entschieden hat die Verbindungen zu Oracle und den Teilen von Java, bei denen Oracle sehr viel Wert darauf legt die eigenen UrheberrechtsansprĂŒche zu betonen, ist sicher ein richtiger Schritt. Aber es wird weltweit viel Arbeit machen die betroffenen Systeme auf allen Ebene darauf umzustellen.

Bis sich dieser Aufwand dann gelohnt haben wird, wird viel Zeit ins Land gehen. Und wer weiß ob es nicht FĂ€lle gibt in denen dieser Aufwand das noch fehlende Argument liefert sich von Java im Backend abzuwenden.

Release 1.3.0 des Anti-DoS-Valves – mit Docker

Heute habe ich ein neues Release des Apache Tomcat Valves zur Begrenzung von massenhaften Zugriffen auf Tomcat Server auf Github veröffentlicht. Funktional hat sich dabei nicht viel getan, abgesehen von der Anpassung des Codes an Tomcat 10 und den dort nun anders benannten Servlet API Paketen. Aber dazu schreibe ich noch etwas in einem anderen Post. Die wesentliche Verbesserung liegt hier:

Docker Logo

Im /docker-Unterzeichnis des Projekts findet sich nun eine Docker-Konfiguration, mit der sich sehr einfach ein Tomcat 10 Server mit einkonfiguriertem Valve und einer Testmöglichkeit als Containerinstanz starten lĂ€sst. Entweder um das Ganze einmal schnell auszuprobieren, oder um bei eigenen Weiterentwicklungen ohne Basteleien und manuelles Hin- und Herschieben von JARs und Konfigurationen schnell die letzte Version des Valves direkt ausfĂŒhren zu können.

Ich bin noch nicht so routiniert mit Docker, daher gehe ich hier einmal die Inhalte des /docker-Verzeichnisses durch und falls eine Leserin oder ein Leser dazu VerbesserungsvorschlÀge hat freue ich mich:

Dockerfile

Es ist nahezu leer:

FROM tomcat:10-jdk16-corretto

Nur das Tomcat 10 Image von Dockerhub wird referenziert. Ich hĂ€tte hier schon die angepasste server.xml oder das Valve Jar in das Image bringen können, aber gerade fĂŒr Entwicklungszwecke erschien es mir zu umstĂ€ndlich jedes Mal ein neues Image zu bauen. TatsĂ€chlich hĂ€tte es das Dockerfile im Moment gar nicht gebraucht, es hilft in der jetzigen Form nur die unten beschriebenen Kommandozeilen von spĂ€teren Änderungen des verwendeten Tomcat Images zu isolieren.

Falls man aber ein Tomcat Image fĂŒr produktive Zwecke bauen möchte, in dem das Valve schon enthalten ist, wĂ€re es sicher eine gute Idee die Valve Anpassungen bereits hier zu integrieren und mindestens das Jar schon in das Image aufzunehmen.

README.md

Hier sind die Kommandos enthalten, die es braucht um den Tomcat samt Valve zu starten. Interessant ist dabei eigentlich nur dieses Kommando:

docker run \
   --mount type=bind,source="%cd%"/../target/anti-dos-valve-1.3.0.jar,target=/usr/local/tomcat/lib/anti-dos-valve.jar,readonly  \
   --mount type=bind,source="%cd%"/server.xml,target=/usr/local/tomcat/conf/server.xml,readonly  \
   --mount type=bind,source="%cd%"/advdemo/,target=/usr/local/tomcat/webapps/advdemo/,readonly \
   --name AntiDoSValveDemo \
   -p 8013:8080 \
   -it antidosvalve_demo

In den drei mount-Anweisungen werden drei Dateien/Order aus dem Host-System in den Container abgebildet und ĂŒberdecken dabei die schon vorhandenen Dateien im Container:

  • JAR: Das Jar, welches sich eins höher im /target-Verzeichnis befindet, wird in das /lib-Verzeichnis des Tomcats im Container gebracht und steht dem Server damit zur VerfĂŒgung. Das Jar muss natĂŒrlich vorher schon gebaut worden sein
  • server.xml: Hier wird eine angepasste Version der server.xml, die sich im Tomcat Image befindet, in den Container gesetzt. Dadurch werden die Valve Konfigurationen wirksam
  • /advdemo: Dieser Ordner enthĂ€lt eine JSP – siehe unten – und wird als Webapp eingebracht, die der Tomcat klaglos ausfĂŒhrt

Alle mounts werden als readonly deklariert, damit in keinem Fall der Server im Container etwas zurĂŒckschreiben kann. mounts benötigen absolute Pfad, damit die Anweisung trotzdem immer funktioniert wird der aktuelle Pfad eingesetzt. Hier fĂŒr Windows, fĂŒr Linux sind entsprechende Anpassungen notwendig.

Es wird ein Portmapping gemacht, dabei wird nicht der sonst ĂŒbliche Port 8080 verwendet, um nicht in Konflikt mit anderen auf dem Host laufenden Servern zu kommen.

Schließlich wird ein Name vergeben, unter dem sich der Container ansprechen lĂ€sst. Das verhindert, dass man einen beendeten Container einfach erneut starten kann und ihn erst entfernen muss. Ich bin mir noch nicht sicher, ob ich das wirklich praktisch finde.

server.xml

Die server.xml Datei, mit der Tomcat 10 Distribution mitgeliefert wird, um 2 Valve Konfigurationen ergÀnzt. Wenn man alternative Konfigurationen ausprobieren will kann kann man einfach die Datei bearbeiten und den Container neu starten.

/advdemo-Ordner

Hier ist nur eine JSP enthalten, die fĂŒr die Demonstration des Marking Modes des Valves benötigt wird. Sie wird als eigene Webapp in den Tomcat gebracht und ist dann dort ausfĂŒhrbar.

Schnelle Iterationen

Durch die Containerlösung, die sich in Sekunden hochfĂ€hrt, ist es einfach neue Versionen des Valves, der server.xml oder auch der JSP auszutesten, deutlich schneller als mir das bisher mit einer separaten Tomcat Instanz möglich war. Auch der rasche Wechsel zwischen unterschiedlichen server.xml Dateien ist einfach, man muss sich nur eine alternative Kommandozeile zurechtlegen. Und dafĂŒr ist keine ‚Magic‘ mit in Eclipse und Co. integrierten Tomcats notwendig, alles sind einfache Kommandozeilen, die sich schnell ausfĂŒhren und und anpassen lassen.

Mir gefĂ€llt das gut 😀🐳

Die Tasten an einem ASUS Chromebook ausbauen

Die Vorbesitzer*innen meines aktuellen ASUS C443T Chromebooks haben wohl hĂ€ufig Chips beim Streaming gegessen, jedenfalls waren einige Tasten sehr schwergĂ€ngig. Obwohl man unzĂ€hlige Videos zu Tastaturreparaturen im Netz findet ist mir keins untergekommen, welches die (De)Montage genau dieses Modells zeigt. Daher hier mein Beitrag zum großen Wissensspeicher:

Die Tasten verhalten sich etwas unterschiedlich:

  • Die normalgroßen Tasten sind am oberen Rand eingeklickt, man zieht sie also dort hoch bis sie ausrasten. Das kleine GerĂŒst darunter ist mit 4 Haken am Grund befestigt, ich konnte es beschĂ€digungslos lösen in dem ich auch am oberen Rand ansetzte
  • Bei den schmalen Tasten am oberen Rand der Tastatur ist es genau umgekehrt, aber das Prinzip identisch
  • Die Leertaste hat eine etwas andere Konstruktion mit zwei DrĂ€hten, an denen die Taste eingeklemmt ist. Hier scheint es egal zu sein, von welcher Seite man zieht, aber vielleicht gibt es hier auch spezielles Werkzeug mit dem man weniger den Eindruck hat gleich etwas zu zerbrechen
  • Auch andere große Tasten wie Shift haben zusĂ€tzliche DrĂ€hte, hier sind weitere Bauformen zu finden

Ich habe hier Hilfsmittel verwendet, die sonst fĂŒr den Tausch von Handydisplays verwendet werden, also einen kleinen Schraubendreher und ein Plektrum.

Beim Einbauen geht man umgekehrt vor, hĂ€ngt also die Tasten zuerst auf der Seite ein, in der sie nicht einklicken. Beim AndrĂŒcken der kleinen GerĂŒste muss man etwas darauf achten die Metallhaken nicht zu verbiegen.

Das eKVV erreicht sein 3. Betriebsjahrzehnt

In den BIS News habe ich diesen kurzen Post ĂŒber das 20. Betriebsjahr des eKVVs eingestellt. Man hĂ€tte mehr schreiben können, aber es gab in der Vergangenheit auch schon umfangreichere Texte zu anderen, runden Geburtstagen (10 Jahre Projekt BIS) oder inhaltlichen Meilensteinen (die 2.000.000ste PrĂŒfungsleistung im System). Irgendwann fĂ€ngt man sich zu wiederholen 😅

BaukrÀne an der UniversitÀt Bielefeld

Und wenn der 20. Geburtstag mitten eine Zeit fĂ€llt, in der sich so viel bewegt – der Start des Medizin-Studiengang rĂŒckt nĂ€her und damit vielfĂ€ltige VerĂ€nderungen im Grundsystem – ist das eher ein Anlass nach vorne zu blicken, als zurĂŒck.

Trotzdem 
 wenn ein technisches System allmĂ€hlich ein Alter erreicht, in dem man als Mensch endgĂŒltig als Erwachsene*r gilt, ist das bemerkenswert, um so mehr wenn die Perspektive nach heutigen Stand ohne Deadline fĂŒr eine Ablösung oder ein Nachfolgesystem ist.

Am Ende der langen Geschichte des BIS (bis Ende 2016) findet sich ein Abschnitt zur technologischen ZukunftsfĂ€higkeit des Gesamtsystems. Das dort gesagte gilt fĂŒr mich auch weiterhin: Die Nutzung von Java als Grundtechnologie gibt uns die Handlungsoptionen und das große, lebendige Ökosystem, welches wir fĂŒr Weiterentwicklungen brauchen. Auch große Überarbeitung wie die aufwĂ€ndige Umstellung der OberflĂ€chen auf das aktuelle Corporate Design und die damit endlich erfolgende EinfĂŒhrung einer responsiven Darstellung lassen sich bewĂ€ltigen, die hohen Kosten (in Form von Personalressourcen) entstehen eher durch die KomplexitĂ€t und den Umfang der BIS Anwendungen und weniger durch die eingesetzte Grundtechnologie.

Im Moment spricht daher nichts dagegen, dass das eKVV in 10 Jahren weiterhin das zentrale System fĂŒr die Lehrplanung an der UniversitĂ€t Bielefeld ist. Die sich dann mit einem Medizinstudiengang im Vollausbau, vielen neuen GebĂ€uden und vielleicht auch durch die Nachwirkungen der Corona-Online-Zeit sehr verĂ€ndert haben wird.

PS.

Beim Schreiben des BIS News Posts habe ich den alten Screenshot des eKVVs aus dem Jahr 2003 herausgesucht:

Screenshot des eKVVs aus dem Jahr 2003

Und irgendwie gefĂ€llt mir die Buntheit 😌 und die LĂ€uferin, die wir damals in den Verlauf gesetzt haben. Vielleicht auch einfach nur weil weil der Kontrast zu heutigen Seiten einfach so groß ist.

PPS.

Wer mehr ĂŒber zur Entstehung des eKVVs lesen möchte: In der Geschichte des Bielefelder Informationssystems bis zum Jahr 2016 findet sich eine Beschreibung.

Endlich: Emacs unter ChromeOS 😆

Screenshot ChromeOS mit Linux Anwendungen

Das ist ein Screenshot aufgefertigt auf dem ChromeBook, das gestern ankam. Das erste Modell hier im Haus, auf dem sich Crostini ausfĂŒhren lĂ€ĂŸt. Damit hat ChromeOS Linux Container erhalten und so die Option Tools wie git oder eben Emacs nativ auszufĂŒhren. Und Google Drive lĂ€sst sich einfach mounten. Sehr schick 😊

Java APIs in Android: Der Rechtsstreit ist entschieden

Die Auseinandersetzungen zwischen Oracle und Google um Google’s Nutzung von Java APIs in Android sind offenbar vorbei: Das Oberste Gericht der USA hat entschieden, dass diese Nutzung unter den Fair Use fĂ€llt. Neben IT und Tech Seiten wie Heise und The Verge haben auch SPIEGEL und FAZ direkt darĂŒber berichtet. Das Urteil ist spannend zu lesen:

Fast 11 Jahre vor Gericht

Zusammenfassungen der verschiedenen Etappen dieser Auseinandersetzung zwischen den beiden IT Giganten lassen sich an verschiedenen Stellen im Netz finden, fĂŒr mich verbindet sich die Anfangsphase noch mit intensiven Diskussionen darĂŒber beim schon lange eingestellten Google+. Dort haben sich naturgemĂ€ĂŸ die eher Google-freundlichen Diskutanten eingefunden, aber die Frage ob Google sich unrechtmĂ€ĂŸig der kreativen Leistung anderer bedient hat, oder ob Oracle mit seinem Versuch Programmierschnittstellen nachtrĂ€glich als urheberrechtlich geschĂŒtzte Werke zu interpretieren die Softwarewelt aus ihren gewohnten Angeln hebt, war heiß umstritten. Ich war da eher auf der Seite, die Oracles Klagen strikt ablehnte. Die folgende Karikatur aus dieser Zeit zu den Organisationsstrukturen verschiedener IT Unternehmen ist mir daher direkt wieder eingefallen:

Humoristische Organisationscharts verschiedenen US IT Unternehmen: Apple, Google, Microsoft, Oracle, Facebook, Amazon
Comic von Manu Cornet

Interessante AuszĂŒge aus dem Urteil

Das Urteil kann man hier als PDF vom Heise Verlag abrufen. Es ist durchaus lesenswert und auch ohne umfangreiche juristische Kenntnis durchaus verstÀndlich. Ein paar Abschnitte habe ich mir rauskopiert:

‚To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.”

Das oberste Gericht hat also die fĂŒr die IT Welt – insbesondere auch die Open Source Community – wesentliche Frage ob eine API ĂŒberhaupt ganz grundsĂ€tzlich ein Urheberrecht haben kann, nicht entschieden. Und da hatte Oracle in frĂŒheren Instanzen einen Etappensieg errungen. Auch wenn die Oracles Niederlage nun vielleicht einen abschreckenden Effekt hat, grundsĂ€tzlich ist damit zumindest in den USA wohl mit weiteren Verfahren zu rechnen, in denen API-Nutzungen Anlass zu Gerichtsverfahren geben. Und nicht jede Beklagte ist so mĂ€chtig und wohlhabend wie Google.

‚Computer programs differ to some extent from many other copyrightable works because computer programs always serve a functional purpose.‘

Das Gericht hat sich aber Gedanken dazu gemacht, in wie weit das Urheberrecht eigentlich auf Software angewendet werden kann.

‚As a result, this code is different from many other types of code, such as the code that actually instructs the computer to execute a task. As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google). Unlike many other computer programs, the value of the copied lines is in significant part derived from the investment of users (here computer programmers) who have learned the API’s system.

Hier macht das Gericht zum ersten, aber nicht zum letzten Mal, einen interessanten Punkt: Eine API – zumindest die, um die es hier konkret geht – gewinnt dadurch an Wert, dass Programmierer*innen sie erlernen und dafĂŒr Zeit investieren. Damit wird die Wertgenerierung nicht mehr allein den Erschaffer*innen zugebilligt, sondern jede Java Entwickler*in, die diese APIs gelernt hat, vergrĂ¶ĂŸert durch ihr Investment den Wert der Sprache.

‚Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language.‘

Auch hier wird wieder der Verweis auf das existierende Knowhow von Entwickler*innen gemacht und das es Googles Vorgehensweise diesen ermöglicht habe ihr Wissen nun in einem weiteren Umfeld zu nutzen. Dieses Wissen also wertvoller wurde.

‚Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as one small part of the considerably greater whole. As part of an interface, the copied lines of code are inextricably bound to other lines of code that are accessed by programmers. Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.‘

Und noch einmal der Verweis auf die Möglichkeit fĂŒr Entwickler*innen ihr Knowhow in einer neuen Umgebung zu nutzen. Verbunden mit der Entlastung von Google, die eine vergleichsbare API oder gleich eine ganze Programmiersprache auch leicht hĂ€tten selbst entwickeln können (was sie in spĂ€teren Jahre mit Dart und Go taten).

‚The fourth statutory factor focuses upon the “effect” of the copying in the “market for or value of the copyrighted work.” §107(4). Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE. The record also showed that Java SE’s copyright holder would benefit from the reimplementation of its interface into a different market

Mir persönlich gefĂ€llt, dass das Gericht den positiven Einfluss von Android auf das ganze Java Ökosystem hier honoriert. Schon bei den ersten Diskussionen gab es diesen Punkt, wenn es Oracle wirklich darum gegangen wĂ€re Java zu pushen, dann hĂ€tten sie direkt mit Google zusammenarbeiten können. Und offenbar ist im Laufe der Jahre das Argument von Oracle verloren gegangen, wonach Google mit Android das ‚florierende‘ Ökosystem von Java ME Handys vernichtet habe.

Die Entwickler*innen als eigene Partei

Abgesehen von der eigentlichen Urheberrechtsfrage, die vermutlich in anderen Gerichtsverfahren – vielleicht nicht nur in den USA – entschieden wird, finde ich den Aspekt, das wir als Entwickler*innen eine wesentliche Rolle in solchen ErwĂ€gungen spielen, sehr spannend:

Wenn wir uns auf eine Sprache / API / Technologie einlassen kostet uns dies Zeit und vielleicht auch Geld und eine Technologie kann sich kaum durchsetzen ohne eine entsprechende Menge von Menschen, die sich damit gut auskennen. Und unsere Interessen sind dabei durchaus anders als die der potentiellen Urheberrechtsinhaber*innen: FĂŒr uns ist es attraktiv die Wahl zu haben, zwischen Werkzeugen und zwischen Implementierungen einer API, und jedes neue Feld, in dem wir unsere Kompetenz einsetzen können, ist zunĂ€chst einmal gut fĂŒr uns und den Wert unseres Wissens.

Man wird sehen, ob dieser Aspekt auch in zukĂŒnftigen Gerichtsverfahren eine Rolle spielen wird.

Die Blockchain und das Osterei

Wenn die Ostereier in diesem Jahr ungefĂ€rbt waren, dann hat man vielleicht ein neues Logo darauf entdecken können, das Logo von respeggt. Damit werden Eier gekennzeichnet, die ohne das Töten von mĂ€nnlichen KĂŒken bei der Zucht der Legehennen auskommen. Dieser Abschnitt aus der respeggt-Webseite sagt dazu:

Das respeggt-Siegel steht fĂŒr das Versprechen: „Ohne KĂŒkentöten“. Dank einer lĂŒckenlosen PrĂŒfung der Lieferkette wird garantiert, dass nur Produkte das Siegel tragen, die die Forderung „Ohne KĂŒkentöten“ erfĂŒllen.

An dem respeggt-Siegel erkennt der Verbraucher sofort, dass es sich um Eier handelt, in deren gesamter Lieferkette die GrundsĂ€tze des respeggt-Versprechens eingehalten werden. Die Nutzung einer Blockchain-Technologie stellt sicher, dass jedes Ei, das das respeggt-Siegel trĂ€gt, lĂŒckenlos verfolgt und auf das Einhalten des respeggt-Versprechens verifiziert wird.

Das hört sich sowohl in ethischer wie auch in technologischer Hinsicht interessant an. Aber wie funktioniert das?

Ei im Eierbecher

Was ist die Aufgabe

Die respeggt-Group ist selbst kein Eierproduzent, sie hat das QualitĂ€tssiegel entwickelt und betreibt das System zur Sicherung dieser QualitĂ€t. Damit das Siegel glaubwĂŒrdig ist mĂŒssen dabei mindestens diese Dinge beleg- und nachvollziehbar sein und zwar lĂŒckenlos:

  1. Von welchem Legehennenbetrieb kommt das mit dem Siegel gekennzeichnete Ei
  2. Von welcher Henne wurde das Ei dort gelegt
  3. In welchem Aufzuchtbetrieb wurde die Henne großgezogen
  4. Woher kam das Ei, aus dem die Henne geschlĂŒpft ist
  5. Wie wurde in der BrĂŒterei mit den mĂ€nnlichen KĂŒken der Eier umgegangen, die zusammen mit dem Ei, aus dem die Henne geschlĂŒpft ist, bebrĂŒtet wurden. Diese Frage ist das eigentliche Fundament des QualitĂ€tssiegels

Bis das respeggt-Ei in die Handelsketten und zum Endkunden kommt sind also schon auf mehreren Ebenen Unternehmen mit unterschiedlichen Aufgaben beteiligt, und in jedem dieser Unternehmen und auch bei den Transporten von HĂŒhnern und Eiern zwischen ihnen gibt es Potentiale fĂŒr Fehler oder gar absichtliche VerstĂ¶ĂŸe gegen die Richtlinien.

Das Supply Chain Monitoring System fĂŒr so eine Produktions- und Lieferkette ist schon eine komplexe Aufgabe, um das Vertrauen der Verbraucher*innen zu gewinnen muss aber auch plausibel gemacht werden, dass die Dokumentationen dazu vollstĂ€ndig und fĂ€lschungssicher sind.

Was kann die Blockchain dazu tun

FĂŒr die Blockchain Technologie, die mit dem Aufstieg von KryptowĂ€hrungen wie Bitcoin Bekanntheit erlangte, werden schon lange weitere Einsatzfelder diskutiert. Genauer gesagt muss es dabei nicht unbedingt eine Blockchain sein, sondern generell eine Distributed-Ledger-Technologie, was man als verteiltes Kassenbuch ĂŒbersetzen kann, und Blockchain ist dabei das heute am weitesten verbreitete Verfahren.

Eine Distribute-Ledger-Technologie hat dabei mehrere interessante Eigenschaften, hier sind es wohl diese beiden, die wesentlich sind:

  • Das ‚Kassenbuch‘ ist kryptografisch so abgesichert, das nachtrĂ€gliche Änderungen nicht möglich sind, zumindest nicht ohne das sie auffallen. Die Blöcke in der Blockkette verweisen dazu aufeinander und bilden so eine Kette, die nicht unterbrochen werden kann
  • Bei einem echten verteilten Kassenbuch gibt keinen zentralen Akteur, der uneingeschrĂ€nkt ĂŒber das Kassenbuch bestimmt, es sich mehrere Akteure notwendig, um den nĂ€chsten Dokumentationsabschnitt (= Block) zu bestĂ€tigen und damit unverĂ€nderlich zu machen. Allerdings ist mir beim respeggt-System nicht klar, ob das Sinn macht bzw. so umgesetzt wurde

Diese Eigenschaften sind etwa in der Bildungslandschaft die Grundlage fĂŒr Überlegungen ĂŒber eine Blockchain fĂ€lschungssichere und allgemein zugĂ€ngliche Dokumentationen von AbschlĂŒssen bzw. Bildungszertifikaten aufzubauen, die je nach Nutzungsweise auch ohne zentrale Datenhaltung auskommen könnte. Dabei mĂŒssen ’nur‘ noch ein paar HĂŒrden ĂŒberwunden werden, etwa die, das nicht komplette Zeugnisse in die Blockchain aufgenommen werden können: Die personenbezogenen Daten darin wĂŒrden sich nie mehr daraus entfernen lassen, was sich nicht mit der DSGVO vereinbaren lĂ€sst. Hier könnte mit Dokumentenhashes gearbeitet werden, ĂŒber die sich dann Dokumente, die von Absolvent*innen prĂ€sentiert werden, validieren lassen.

Eine andere Idee – und hier kommen wir denke ich dem Einsatzszenario bei den respeggt-Eiern schon nĂ€her – ist das hier beschriebene Verfahren fĂŒr Diamanten Herkunftsnachweise zu realisieren. Und so den Nachweis zu fĂŒhren, dass es sich nicht um sogenannte Blutdiamanten handelt. Ob dieses Verfahren inzwischen tatsĂ€chlich eingefĂŒhrt und genutzt wird habe ich leider nicht herausgefunden, aber das liegt vielleicht in der Natur der Sache:

WĂ€hrend die Bitcoin Blockchain vom Prinzip her öffentlich sein muss, wĂŒrden sich die am Diamantenhandel beteiligten Parteien wohl eher nicht völlig frei in die Karten schauen lassen. Hier wird die Blockchain dann zu einem internen Werkzeug fĂŒr Unternehmen, die sich nicht völlig (oder ĂŒberhaupt nicht) vertrauen können, aber damit eine gegenseitige Kontrollmöglichkeit erhalten könnten ohne eine zentralisierte Struktur.

Leider habe ich auch zur respeggt-Blockchain keine konkreteren Angaben im Netz finden können, die inhaltlich ĂŒber den oben zitierten Satz hinausgehen. Es gibt nur von Telefonica dieses Paper (PDF), welches im Kontext des Internet of Things die Anbindung von respeggt-Infrastrukturen beschreibt. Vielleicht speisen verschiedene GerĂ€tschaften wie die Drucker, die das Siegel auf die Eier drucken, ihre Daten so gleich in die Blockchain ein? Leider ist auch nicht klar wer genau wie tief in die Blockchain schauen kann und was genau da alles drin steht. Als Endkunde kann man nur hier seinen Eiercode online prĂŒfen.

Trotzdem ist das fĂŒr mich eines der bisher noch wenigen Beispiele, in denen die Blockchain Technologie jenseits von Bitcoin ganz direkt nutzbar geworden ist.

Hafnium im Gartenshop

Die wahlweise Hafnium oder ProxyLogon genannte Gruppe von SicherheitslĂŒcken in Microsofts Exchange Servern dominierte in den letzten Wochen die IT Sicherheitsthemen. Und selbst wenn IT Profis wie die Kollegen in der Uni die LĂŒcken schnell geschlossen haben kann einen das Thema betreffen. Daran erinnert diese Mail eines Webshops, bei dem ich vor Jahren mal etwas bestellt habe, und die gestern eintraf:

Screenhot einer Mail mit der Information darĂŒber, dass der Exchange Server eines Webshops gehackt wurde

Nicht alle Admins von Exchange Servern waren schnell genug um den direkt nach Bekanntwerden der LĂŒcke einsetzenden, massenhaften Scans nach verwundbaren Servern zuvor zu kommen. Vermutlich gibt es 10.000e von Systemen, die schon mit Webshells oder anderen HintertĂŒren ausgestattet wurden (Nachtrag: manche offenbar auch gleich mehrfach). Und ein reines Patchen der Exchange LĂŒcken beseitigt diese ZugĂ€nge dann nicht mehr.

Die DSGVO zwingt nun die Betreiber zumindest im europĂ€ischen Raum dazu ihre Kund*innen ĂŒber solche VorfĂ€lle zu informieren. Und ich wĂŒrde wetten, dass das nicht die letzte entsprechende Mail war, die ich bekommen werde. NatĂŒrlich nur, wenn gehackte Betreiber sich gesetzeskonform verhalten bzw. ĂŒberhaupt entdecken, dass sie gehackt wurden.

Was kann man tun?

Bei der Gelegenheit die Erinnerung an den schönen Have i been pwned? Dienst:

https://haveibeenpwned.com/

Der benachrichtigt einen, wenn mit der eigenen Mailadresse verknĂŒpfte Kontodaten irgendwo im (Dark)Web auftauchen, oft auch verbunden mit der Information von welchem Dienst diese Daten gestohlen wurden. Ich habe in den letzten Jahren schon mehrere entsprechende Meldungen bekommen und zum GlĂŒck hatte ich bei den jeweiligen Diensten schon individuelle, nur fĂŒr den jeweiligen Dienst geltende Passworte verwendet, so dass mit den gestohlenen Zugangsdaten nicht noch weitere Konten von mir missbraucht werden konnten.

Was zum nĂ€chsten Tipp fĂŒhrt: Heute ist die Verwendung eines Passwortmanagers unumgĂ€nglich um

  • sehr sichere (also lange und komplett zufĂ€llige) und
  • fĂŒr jeden Dienst einzigartige

Logindaten zu verwenden. Wer sich dabei nicht auf die in heutigen Webbrowsern eingebauten Passwortmanager verlassen möchte, der findet hier einen aktuellen Überblick.