Meltdown und Spectre – Lehren aus dem Desaster ? – I – Die letzte Warnung

Posted on by

Als WannaCry und SambaCry 2017 die IT-Welt in Aufruhr versetzten, wurde ein paar fundamentale Dilemmata IT-gestützter Informationsgesellschaften deutlich:

  • Hardware und Software sind nie fehlerfrei – auch OpenSource Software nicht.
  • Es kann fundamentale, hochkritische Fehler geben, die von interessierten Kreisen über entsprechende Schadcodes lange Zeit genutzt werden, ohne dass die Schwachstellen öffentlich gemacht würden.
  • Auch staatliche “Sicherheits”-Organe sind gegen das Abgreifen von selbst entwickelten Angriffsverfahren durch kriminelle Organisationen und feindliche Staaten nicht zu 100% gefeit. Der Staat als (ggf. durch ein Parlament legitimierter) Hacker ist daher nicht nur als Schutzfaktor, sondern auch als ungewollte indirekte Gefahrenquelle zu begreifen.
  • Es kann Schwachstellen geben, die über hinreichend intelligent gestrickte Angriffs-Software und gesteuerte Angriffswellen über BOT-Netze innerhalb kürzester Zeit zu einer weltweiten Bedrohung werden können – und zwar auch für die sensiblen Infrastrukturen von Industriestaaten.
  • Es ist ein gigantischer Fehler, von wenigen HW-Produzenten und Betriebssystem-Herstellern abhängig zu sein – und im Ernstfall keine Alternativen zu haben. In diesem Sinne sind wir in Westeuropa fast alle abhängig von der IT-Supermacht USA. Das beklagte zuletzt ja sogar unser amtierender Außenminister auf der DLD-Konferenz.

Meltdown/Spectre verschärfen alle diese Punkte – und lassen sie im Sinne einer globalen Verwundbarkeit von uns allen in neuem Licht erscheinen. Nun haben wir also noch eine ganze Weile mit Meltdown/Spectre zu leben. Der Unterschied ist diesmal: Fast alle gängigen IT-Systeme sind angreifbar, da die Schwachstellen in den Prozessoren selbst stecken. SW-Updates werden möglicherweise nur begrenzt helfen; z.Z. gibt es noch kein Heilmittel gegen bestimmte Varianten von Angriffen nach dem Spectre-Muster. Die Nerven der Beteiligten liegen deshalb auch auf der Linux-Seite blank – siehe
https://www.heise.de/newsticker/meldung/Absoluter-Muell-Linus-Torvalds-verliert-die-Geduld-mit-Spectre-Patches-3948756.html.

Ich behaupte deshalb mal: Meltdown/Spectre sind – genau wie WannaCry eine Art letzter Warnung, die erneut verdeutlicht auf welch dünnem Eis unsere modernen Gesellschaften leben – nicht zuletzt auch durch bestehende Abhängigkeiten von einigen wenigen IT-Monopolisten.

Jeder, der sich einmal mit der Abhängigkeit moderner Industrie- und Informationsgesellschaften wie Deutschland von funktionierender IT auseinandergesetzt hat, weiß, dass wir extrem verwundbar sind: Ein dauerhafter Zusammenbruch grundlegender und infrastrukturell relevanter IT-Netzwerke und -Systeme würde uns in kürzester Zeit in wahrhaft katastrophale Zustände katapultieren.

Zeit für ein paar Gedanken zu möglichen Lehren aus dem aktuellen Desaster, die in der aktuellen Debatte weniger angesprochen werden …. Weniger technik-affine Leser, die sich erst in die Thematik einarbeiten wollen oder müssen, seien auf die Links weiter unten verwiesen.

Ich teile meine Kommentare in mehrere Beiträge auf, da mich einige Bekannte (Linux-Nutzer) vor kurzem auch gefragt haben, was sie den nun konkret tun sollten.

Schwachstellen und Angriffsverfahren

Meltdown und Spectre stellen bislang Angriffsmuster dar und noch (!?) keinen vollständigen, massenhaft einsetzbaren Schadcode. Sie beruhen nach dem, was ich dazu gelesen habe, auf zwei Aspekten moderner Prozessoren, die in ihrer Kombination zu angreifbaren Schwachstellen führen:

  • Das spekulative Ausführen von Programm-Code auf Basis von
    Heuristiken, bevor das Ergebnis solcher Code-Fragmente in der Ausführung einer Anwendung faktisch benötigt wird. Die Bevorratung der Ergebnisse derartiger “transienter Instruktionen” dient der Performance praktisch aller moderner Computer-Prozessoren. Bei der spekulativen Code-Ausführung wird z.Z. auf verschiedenen Prozessortypen nicht hinreichend geprüft, ob in einem bestimmten Ausführungskontext hinreichende Berechtigungen vorliegen.
  • Seiteneffekte beim Einlagern von (vorausberechneten) Daten in Prozessor-Caches, die erstens erkennen lassen, ob die Daten einer spekulativen Codeausführung entstammen und die in Kombination mit bestimmten, schon länger bekannten Verfahren den ungehinderten Zugriff auf solche Daten auch durch unberechtigte Prozesse/Programme ermöglichen. Durch geschickte Manipulationen der spekulativen Codeausführung kann man das Exception-Handling beeinflussen und über den Cache systematisch auf ganze Speicherbereiche mit hinreichender Geschwindigkeit zugreifen.

Wie genau diese Effekte ausgenutzt werden können, ist u.a. von der Prozessorarchitektur und der Art der Caching-Seiteneffekte abhängig. Bei Meltdown greift man dabei den eigenen Speicherbereich an, in den allerdings auch globale Speicherinhalte eingeblendet sind, die normalerweise nur in bestimmten Prozessormodes und nicht direkt durch einen unberechtigten User-Prozess ausgelesen werden können – wohl aber im Rahmen der spekulativen Ausführung von Codefragmenten.
Meltdown betrifft Intel-Prozessoren.

Bei Spectre werden Speicherbereiche fremder Prozesskontexte (anderer User) angegriffen. Für Spectre-basierte Angriffe sind intime Kenntnisse von Anwendungen und auch des Betriebssystems erforderlich. Das spekulative Verhalten des Prozessors wird dabei vorab auf bestimmte Annahmen hin “trainiert”. Spectre betrifft (zumindest in einer Variante) sehr viele Prozessortypen unterschiedlicher Hersteller.

Die Zugriffsverfahren auf Prozessor-Cache-Inhalte über Seitenaspekte (und z.B. Zeitanalysen) wurden bereits seit mehreren Jahren erforscht. Dass das Zusammenspiel mit spekulativer Codeausführung erst jetzt als fundamentaler Gefahrenpunkt erkannt wurde, mutet etwas seltsam an und offenbart im besten Fall die Blickfeldeinschränkung, von der auch Sicherheitsexperten nicht verschont bleiben, wenn sie sich auf ein spezielles Problem konzentrieren. Über den schlechteren Fall mag ich gar nicht nachdenken … In jedem Fall scheint zu gelten: Professionell durchgeführte Angriffe auf Basis der Schwachstellen würden kaum Spuren in den betroffenen Systemen hinterlassen.

Nun wurden die Schwachstellen, die seit vielen Jahren existieren, im Juni letzten Jahres publiziert und kommuniziert. Seitdem sind 7 Monate vergangen. Auch das ist ein erheblicher Zeitraum. Die schlimmsten Schwachstellen und Bedrohungen sind diejenigen, die wir nicht mal erkannt haben. Im Moment wurden wir uns nur der Schwachpunkte und Gefahren bewusst; ob sie nicht bereits ausgenutzt wurden, kann niemand sagen.

Angriffe?

Aus meiner Sicht haben die Teams, die die Schwachstellen entdeckt bzw. untersucht haben, bereits relativ detailliert aufgezeigt, wie und aus welchen Angriffswinkeln heraus man Angriffstools konstruieren muss. Gegen Meltdown in Intel-Prozessoren können Kernelmodifikationen der Betriebssysteme schützen. Das ist für relevante aktuelle und LTS-Linux-Kernel bereits der Fall. Spectre-Angriffe sind dagegen komplex, weil sie zielgerichtet und betriebssystem-spezifisch ausgelegt werden müssen. Andererseits ist die Verteidigung gegen Spectre wirklich komplex – und erfordert absehbar das Zusammenwirken von Microcode-Änderungen für die Prozessoren und neuen Kernel-Features (Stichworte: KPTI + Retpoline).

Aber auch dann ist aber sehr fraglich, ob alle denkbaren Seitenkanalvarianten, die in der Original-Publikation zu Spectre angesprochen wurden, abgedeckt werden können. Die Experten, die die Schwachstellen publizierten, sind da eher skeptisch.
Seiteneffekte, die sich durch eine zeitlich hochauflösende Analyse von Speicher/Cache-Vorgängen nutzen lassen, stellen nur einen Teil des möglichen Spektrums dar. Hierfür gibt es allerdings seit längerem sehr ausgereifte Tools.

Genau das Richtige also für ambitiöse Hacker … Das lässt nichts Gutes für den weiteren Verlauf des Jahres erahnen, da potentiell extrem viele Systeme betroffen sind.

Im nächsten Beitrag gehe ich auf Konsequenzen für normale Linux-Nutzer ein.

Links

Wo finde ich verständliche Informationen?
Nachfolgend ein paar Links, deren Inhalte aus meiner Sicht auch für Nicht-IT-Spezialisten verdaubar sind. In etwa geordnet nach steigendem Schwierigkeitsgrad.
http://www.sueddeutsche.de/digital/meltdown-und-spectre-chip-sicherheitsluecke-alle-sind-betroffen-1.3814322
https://www.heise.de/newsticker/meldung/FAQ-zu-Meltdown-und-Spectre-Was-ist-passiert-bin-ich-betroffen-wie-kann-ich-mich-schuetzen-3938146.html
https://www.heise.de/ct/ausgabe/2018-3-Sicherheitsluecken-in-den-meisten-modernen-Prozessoren-3942720.html
https://www.schneier.com/blog/archives/2018/01/spectre-_and-_mel-_1.html
https://solutionsreview.com/security-information-event-management/living-spectre-fallout-meltdown-spectre/
https://www.theregister.co.uk/2018/01/12/meltdown-_spectre-_researchers-_sitrep/
http://www.crn.de/software-services/artikel-115987.html
https://www.heise.de/newsticker/meldung/Analyse-zur-Prozessorluecke-Meltdown-und-Spectre-sind-ein-Security-Supergau-3935124.html
https://www.golem.de/news/updates-wie-man-spectre-und-meltdown-loswird-1801-132125.html

Movies
https://twitter.com/misc0110
https://www.youtube.com/watch?v=I5mRwzVvFGE

Interviews / History
https://www.golem.de/news/meltdown-und-spectre-dann-sind-wir-performancemaessig-wieder-am-ende-der-90er-1801-132224.html
https://www.gdata.de/blog/2018/01/30334-meltdown-spectre-interview-mit-anders-fogh
https://solutionsreview.com/security-information-event-management/dr-eric-cole-discusses-meltdown-spectre/
https://www.bloomberg.com/news/articles/2018-01-08/-it-can-t-be-true-inside-the-semiconductor-industry-s-meltdown
https://www.wired.com/story/meltdown-spectre-bug-collision-intel-chip-flaw-
discovery/
https://cyber.wtf/2018/01/05/behind-the-scene-of-a-bug-collision/
https://www.theverge.com/2018/1/11/16878670/meltdown-spectre-disclosure-embargo-google-microsoft-linux
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
https://www.riskbasedsecurity.com/2018/01/the-slow-burn-of-meltdown-and-spectre-exploits-lawsuits-and-perspective/

Original-Publikationen (für IT-Freaks wirklich lesenswert)
https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.pdf

Linux/QEMU – Schutzverfahren ?
http://kroah.com/log/blog/2018/01/06/meltdown-status/
http://kroah.com/log/blog/2018/01/19/meltdown-status-2/
https://www.heise.de/ct/ausgabe/2018-3-Wie-die-Linux-Welt-auf-Meltdown-Spectre-reagiert-3942819.html
https://de.wikipedia.org/wiki/Kernel_page-table_isolation
https://www.cyberciti.biz/faq/check-linux-server-for-spectre-meltdown-vulnerability/
https://fedoramagazine.org/update-ongoing-meltdown-spectre-work/
https://www.pro-linux.de/news/1/25515/meltdown-und-spectre-weitere-kernelaktualisierungen.html
https://www.suse.com/de-de/support/kb/doc/?id=7022512
http://www.linux-magazin.de/news/meltdown-und-spectre-update-von-kernel-entwickler-kroah-hartman/
https://www.qemu.org/2018/01/04/spectre/
https://lwn.net/Articles/744287/

Warnung vor den Intel-Microcode Updates vom 08.01.
https://thehackernews.com/2018/01/intel-meltdown-spectre-patch.html
https://www.suse.com/de-de/support/kb/doc/?id=7022512https://www.theregister.co.uk/2018/01/18/red_hat_spectre_firmware_update_woes/

Service-Wüste IT-Hosting … im Zweifel ist erst mal der Kunde schuld … Szenen aus dem realen Leben

Posted on by

Es gibt ein paar Dinge im IT-Leben, die können einen aufregen. Im Besonderen Provider-Support. Nicht zuletzt, weil das Zeit kostet. Gerade musste ich das wieder erleben. Mit der Folge ungesund erhöhten Blutdrucks. Daher der nachfolgende Text:

Sei ca. 13:00 Uhr ist eine unserer bei Strato gehosteten Domänen nicht mehr oder nur erratisch erreichbar. Mal 0,8 Sek Antwortzeit, mal 120 Sekunden, mal interner Verbindungsfehler. Typische Antwortzeiten der letzten Monate lagen dagegen bei 0,8 bis 2,5 Sekunden – je nach Tageszeit. Was tut man in einer solchen Situation? Man ruft seinen Provider an. Man schildert das Problem. Erste Antwort:

“So etwas können wir leider nicht supporten.”

Man langt sich an den Kopf, man stöhnt innerlich und äußerlich und bemüht sich dann, dem Ansprechpartner klar zu machen, dass die Webseiten inkl. PHP seit Monaten bis heute 13:00 anstandslos liefen. Und: Kein Support gibts nicht … ob er denn Support-Mitarbeiter sei oder nicht?

Beim Stichwort PHP wurde besagter “Support”-Mitarbeiter dann plötzlich hellhörig und empfahl mir einen Umstieg auf PHP 7.2. Dann würde das wieder und schneller funktionieren. Auf die Rückfrage, ob ältere PHP-Versionen denn von Strato noch unterstützt würden, kam ein klares: Ja. Ob er denn auch Daten zu Performanceunterschieden vorliegen hätte und wie er mir erklären könne, warum der Einbruch abrupt geschehen sei. Ich wurde nach einigen Wortwechseln dann zu einem “Techniker” verbunden. Selbiger hatte dann den schlauen Gedanken, mal in die Error-Logs zu sehen. Und den weniger schlauen Gedanken, dass da wohl meine Skripte nicht laufen würden …. Da könne man nichts tun – ich müsse das selber debuggen.

Gleichzeitig flimmerten verschiedene Meldungen über den Schirm – Tenor: “Interner Proxy-Server …. – keine Antwort vom Upstream-Server.” Was ich dem Techniker pflichtbewusst mitgeteilt habe. 3 Minuten später lief meine Domäne dann wieder plötzlich sehr schnell, dann erneut Fehler und/oder bis zu 120 Sek. Responsezeit.

Ich habe mir zwischenzeitlich selbst die Error-Logs angesehen (aktuell bei Strato im Web-Kundenbereich übrigens in einer katastrophalen 1-zeiligen Darstellungsweise). Die Meldungen implizierten, dass die FastCGI-Server (wieso eigentlich trotz bekannter Schwachstellen FastCGI??) bei Strato keine Antwort von anderen Servern (File-Server) erhielten und die Skripts deshalb auf einen Timeout liefen. Keine der Meldungen deutete auf einen Skriptfehler hin. Es gab immer nur Timeout-Fehler. Ein ergänzender Blick in die Zugriffslogs zeigte zudem, dass es bis heute 13:00 keinerlei Probleme – außer typischen Angriffsversuchen auf vermutete (!) WordPress-Installationen – gab.

So gewappnet rief ich wieder an. Nun bekam ich nach einigem Hin und Her die Empfehlung, Security-Einstellungen (permanente SSL-Umlenkung und Filter) abzuschalten (!); solche Domän-Einstellungen würden manchmal “eine korrekte Ausführung von PHP-Skripten verhindern”.

Stirnrunzeln, innerliches Stöhnen, Nerven beruhigen, Hinweise auf den unglaublichen Kern der Botschaft und die Widersprüchlichkeit zu anderen Befunden absondern, Ausprobieren um des lieben Friedens willen und trotz Sinnlosigkeit: Brachte erwartungsgemäß gar nichts. Ich wurde dann auf erneuten Wunsch zu einem Techniker verbunden; die Verbindung brach dabei ab.

Zwischenzeitlich Check der Skripte. Originalzustand. Check Lauffähigkeit bei eingeschaltetem Fehlertracking in der php.ini einer Testdomäne. Kein Fehler. Erneuter Check der Strato-Error-Logs, wenn denn mal verzögert ein Seitenaufbau erfolgte – Zero Fehler.

Erneuter 4-ter Anruf. Der Kollege lies mich den Sachverhalt in Ruhe darstellen. Schließlich:

Er habe gerade das gleiche Problem mit einem anderen Kunden gehabt. Seit 20 Minuten wisse man nun auch, dass es ein größeres Problem intern bei Strato gebe. Man habe bisher vermutet, dass manche Kunden ihre Skripts modifiziert hätten. Nun wisse
man aber, dass das Problem bei Strato läge. “Tut uns leid – aber Sie können beruhigt sein, es liegt nicht an Ihren Skripten”.

Ach ….

Interessanterweise hatte auch die Telekom seit 13.00 Uhr ein flächendeckendes Problem. Da ich nicht weiß, ob man Ausschnitte von der Seite allestörungen.de kopieren darf: Dort ist Deutschland weitgehend und bis auf Thüringen zur Zeit (14:30 Uhr) rot eingefärbt. Sieht schlimm aus. Der Meldungspegel zu Störungen bewegt sich aktuell in Richtung 350 pro Viertelstunde.

Nun war Strato ja mal eine Telekom-Tochter und hatte (hat?) wohl auch einen Teil der internen Netzwerk-und Backbone-Infrastruktur bei der ehemaligen Mutter am Laufen. Ein Schelm, wer da nun einen Zusammenhang im Störungsaufkommen vermuten möchte … Am Strato-Support ging das jedenfalls spurlos vorbei.

Was haben wir gelernt? Fehler macht jeder – das ist OK. Probleme gibt es in der IT auch immer wieder. Auch das ist OK. Was aber nicht geht, sind folgende Dinge:

Erstmal den Support verweigern, die Schuld beim Kunden zu suchen, Abwimmeln und Techniker, die (vielleicht aus Zeitdruck) nicht genauer hinschauen und nicht genau hinhören.

Die Servicewüste Deutschland wächst – bei Strato offenbar in größerem Ausmaß, seit das Unternehmen eine Tochter der 1&1-Muttergesellschaft wurde. Die “ISO 27001”-Zertifizierung von Strato in Ehren – aber an der Support-Front ist Ebbe. Und das nach einer erst kürzlich erfolgten Preiserhöhung für die Hosting-Pakete.

Die Störungsmeldungen bei der Telekom haben gegen 15:00 Uhr den Höchstwert von 418 pro 15 Minuten passiert.

16:30 Uhr: Die Antwortzeiten meiner Domäne schwankten gerade zwischen 0,162 Sekunden und 120 Sekunden. Eben wieder ein Ausfall.

Nun, um 16:40 Uhr: 0,16 bis 0,26 Sekunden nach erstmaligem Laden der PHP-Skripte (< 1 Sek).

Jetzt 16:45 Uhr: Stabilität seit mehr als 5 Minuten … bei der Telekom fällt das Störungsaufkommen.

Sinkender Blutdruck …

Zu späte Erkenntnisse eines Ministers …

Posted on by

Vor kurzem konnte man lesen, dass sich unser geschäftsführender Außenminister (und früherer Wirtschaftsminister) auf der DLD-Konferenz geradezu ängstlich zum Thema IT und Europas Rolle zwischen den USA und China äußerte:

https://www.golem.de/news/dld-konferenz-gabriel-warnt-vor-digitalem-schlachtfeld-europa-1801-132276.html

Da wird spekuliert, ob Europa nicht zwischen den digitalen Supermächten (gemeint sind vor allem China und die USA) zerrieben werden könne – und der Telekom-Chef gibt auf derselben Tagung Europa auf dem Feld von sozialen Medien bereits verloren. Man fasst es ja nicht ….

Seit Jahren (wenn nicht Jahrzehnten) wurde und wird das Thema Digitalisierung sowie die totale Abhängigkeit Europas von amerikanischen globalen IT- und SW-Monopolisten von den diversen Regierungsparteien – vor allem aber den Volksparteien – völlig vernachlässigt. Man hat da wie üblich auf die Marktkräfte vertraut …

Und jetzt plötzlich ist alles zu spät? Bedurfte es erst Meltdown und Spectre – und die dadurch erneut in Szene gesetzte totale Abhängigkeit von außereuropäischen Chip-Herstellern – um Minister plötzlich wach zu rütteln? Lieber Ex-Wirtschaftsminister:

An Warnungen – auch von Seiten der Industrie – hat es nun wahrlich nicht gemangelt. Und dass die Marktkräfte eben nicht alles richtig regeln, sollte ein SPD-Mann wohl am besten wissen. Man hätte gerade auf diesem Feld schon längst auf eine staatlich organisierte Zusammenarbeit mit Frankreich setzen können …

Und lieber Herr Ex-Wirtschaftsminister – am Rande sei auch darauf verwiesen, dass deutsche Regierungen Know How einfach abfließen lassen:

Ich habe hier in Augsburg mal mit einem hochqualifizierten Ex-Mitarbeiter von Kuka gesprochen. Dem standen die Tränen in den Augen als der Verkauf von Kuka an chinesische Konzerne genehmigt wurde. Es wurde ja angeblich kein europäischer Investor gefunden …

http://www.finanznachrichten.de/nachrichten-2016-07/37971269-kuka-chef-rueckabwicklung-der-uebernahme-durch-midea-nicht-moeglich-016.htm

Wo blieb da der Staat als Investor? Da hatten wir mal ein weltweit führendes Technologieunternehmen mit Bezug zu Themen wie u.a. künstliche Intelligenz. Dass das Know-How ausschließlich und langfristig in Europa hätte verbleiben müssen, liegt angesichts der jetzt offenbarten ministerialen Ängste auf der Hand. Dafür hätte man damals kämpfen müssen. Wo waren Sie damals – lieber Ex-Wirtschaftsminister – als der Verkauf erfolgte und vor allem davor?

Immerhin ist im jetzigen Sondierungspapier von CDU/CSU und SPD die Rede von Giga-Netz-Ausbau, steuerlichen Erleichterungen für IT-Investitionen und einem gemeinsamen französisch-deutschen Zentrum für künstliche Intelligenz. Den erneuten Anlauf in Sachen “Deutsches E-Government” sehen wir regelmäßig seit dem Jahr 2000 in Regierungsprogrammen. Den Stand kennt jeder selber.

Alles Jahre zu spät – aber immerhin. Aber eines sollte ein Ex-Wirtschaftsminister auch verstehen:

Wenn man Google, Facebook, etc. etwas entgegensetzen will, nutzt es nichts, allein 10 – 12 Milliarden in den seit langem notwendigen Infrastrukturausbau zu investieren.

Mindestens die gleiche Summe muss in staatlich geförderte Brainware – sprich Menschen und deren IT-Kreativität investiert werden. Hierzu ist einerseits die gezielte Förderung von IT-Projekten erforderlich. Andererseits solltet ihr vielleicht auch mal darüber nachdenken, warum IT-Unternehmen zwar Ansparabschreibungen auf HW (zur Not auch Bagger) vornehmen können, nicht aber auf manchmal deutlich teurere SW und (in Grenzen) auch auf das Halten bzw. Beschaffen qualifizierten Personals?

Und dann ist da noch ein Punkt:
An unseren Schulen wird – wenn überhaupt – IT auf Basis von proprietären Microsoft-Systemen unterrichtet. Meist steht die Verwendung von MS-Office-Progammen im Fokus
der schon damit oft überforderten Lehrer.

Ehrlich gesagt:
Ich habe schon MSCE-zertifizierte Administratoren erlebt, die unfähig waren, sich in IPtables einzuarbeiten – weil zu abstrakt, komplex und ohne grafische Oberfläche. Das kommt leider nicht von ungefähr – es hat damit zu tun, dass die Betriebssysteme von MS geschlossen sind und weder Anwender noch Admin aus prinzipiellen Gründen viel davon mitbekommen sollen.

Es ist deshalb kein Wunder, wenn eine junge Generation von Indern und Chinesen, die schon allein aus Kostengründen auf Linux und offene Systeme setzt, unseren Kindern und Enkelkindern den Rang abläuft.

An den Schulen muss anhand von Systemen unterwiesen werden, die man auf jeder Detailebene studieren und ggf. auch anpassen kann; die Schüler müssen ab einem gewissen Alter in der Schule den strukturellen Aufbau von IT-Systemen lernen – und nicht den speziellen Umgang mit Google, MS Office oder Facebook. Letzteres lernen sie täglich völlig ausreichend im Umfeld ihrer Freunde.

Die Schule muss dagegen gezielt zeigen, wie IT-System prinzipiell funktionieren. Sie muss zeigen, was IT-Sicherheit bedeutet, wie und warum Angriffe erfolgen und wie man sich verteidigt (Harry Potter lässt grüßen …). Es ist vor allem SW-Entwicklung zu lehren – für Anwendungen und Betriebssysteme gleichermaßen. Das geht am besten und tiefsten mit Open Source und Linux.

“IT und SW-Entwicklung” hätte ab einer hinreichenden Altersstufe ein Pflichtfach an den Schulen werden müssen. Am Gymnasium in anspruchsvoller Form und auf der gleichen Stufe wie Mathematik.

Aber dafür müsste die Politik erstmal für eine hinreichende Ausbildung der Lehrkräfte sorgen …. dazu lese ich aber nichts im aktuellen Sondierungspapier.

Für all das ist es keineswegs zu spät und Europa ist keineswegs verloren – es fehlte und fehlt wie immer der politische Wille. Es gibt in Deutschland und Frankreich genügend junge Leute, die gerne eine europäische Suchmaschine auf Basis künstlicher Intelligenz aufbauen möchten und dies in Form eines staatlich finanzierten Open Source Projektes auch in relativ kurzer Zeit schaffen könnten. Aber wird der Ehrgeiz geeigneter Leute überhaupt angestachelt, wird er auch finanziell gefördert? Statt dessen mussten wir vor ein paar Jahren erleben, wie genau ein Europäischer Entwickler für einen Hungerlohn und mit viel Freizeit die Verantwortung für bestimmte lebenswichtige Verschlüsselungsverfahren übernahm.

Bzgl. der Ängste unseres Außenministers und früheren Wirtschaftsministers, Europa werde zum “tatenlosen Zuschauer” im globalen IT-Wettbewerb, ist deshalb in aller erster Linie an seine – aber nicht nur seine – Verantwortlichkeit für die eingetretene Fehlentwicklung zu verweisen. Einen Kommentar zum Telekom-Chef erspare ich mir.

Eclipse, Git, SSH2, Einträge in der ~/.ssh/config, Bug bei Ciphers mit Domain-Angabe

Posted on by

Wenn man mit Eclipse (Oxygen2, Neon3) Git-Repositories auf Remote-Servern versorgen will, macht man das natürlich über SSH. Ich hatte in einem früheren Blogbeitrag schon mal auf einen Artikel

https://stribika.github.io/2015/01/04/secure-secure-shell.html

hingewiesen, in dem verschiedene Härtungsmaßnahmen aufgezeigt werden. Natürlich verwendet man dabei auch eine Public Key Authentication, wobei der öffentliche RSA-Schlüssel in hinreichender Länge (> 2048 Bit) auf dem Server implementiert wird. Er ist dort wie üblich beim entsprechenden externen User in die Datei “~/.ssh/authorized_keys” einzukopieren.

Unter Eclipse ist dann in jedem Fall noch Folgendes erforderlich: Unter dem Menüpunkt

Window >> Preferences >> General >> Network Connections >> SSH2

trägt man im Fensterchen zum “General”-Tab das Verzeichnis ein, in dem man seine privaten Keys aufbewahrt – und listet zudem die von Eclipse zu verwendenden Keys für die verschiedenen Git- bzw. SSH-Server auf. Das sieht dann etwa so aus:

Ohne diese Einträge funktioniert eine key-basierte SSH-Authentifizierung unter Eclipse nicht. Das gilt nicht nur für Git sondern auch für andere Arten von SSH-Verbindungen etwa unter den “Remote Systems”-Modulen, für SFTP- und für SSH-Shell-Zugriffe. Die korrespondierende Git-Push-Konfiguration für SSH kann dann etwa wie folgt aussehen:

“55511” sei dabei der gewählte SSH-Port, unter dem der Server erreichbar sein soll. Der Leser muss an dieser Stelle natürlich die für ihn geletenden Einträge vorzunehmen.

Auf einem typischen OpenSSH-Server unter Linux lassen sich die Vorgaben des oben genannten Artikels zu Einträgen in der SSH-Konfigurationsdatei “/etc/ssh/sshd_config” problemlos umsetzen. Etwas anders sieht es aber auf dem OpenSSH-Client-System aus. Dort würde man gerne zumindest folgende empfohlenen Härtungseinträge in der Datei “~/.ssh/config” unterbringen:

Korrekte Einträge in der OpenSSH “~/.ssh/config”-Datei, die aber unter Eclipse nicht funktionieren:

  
Host myserv.myhosteddomain.net
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr,aes256-cbc

Nutzt man die Zeile für “Ciphers” in der angegebenen Form, so funktioniert dies zwar für eine native SSH-Verbindung von der Kommandozeile eines Terminalfensters aus; Eclipse reagiert jedoch traurigerweise mit einer Exception “….. java.lang.NullPointerException“.

Ursache dafür ist eine falsche Behandlung von Domain-Angaben in den Cipher-Verfahren durch die zuständigen Eclipse-Module. Interessanterweise funktionieren aber die Domain-Angaben hinter den KEX-Verfahren!

Folgende Variante funktioniert mit den SSH-Modulen von Eclipse:

Funktionierende SSH-config-Datei für Eclipse: 

  
Host myserv.myhosteddomain.net
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
# The following does not 
work in Eclipse 
# Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes192-cbc
# This works, however: 
Ciphers aes256-cbc,aes256-ctr

Es ist irgendwie traurig, dass Eclipse sich in puncto SSH und Cipher-Angaben fehlerhaft verhält; denn man steht nun vor einer (geringfügigen) Einschränkung der Sicherheit. 256Bit basierte AES-Verfahren sollten im Moment allerdings noch ausreichen.

Ich hoffe, das hilft dem einen oder anderen, der auf die oben genannte Exception stößt. Zu hoffen bleibt auch, dass die Eclipse-Entwickler solche Bugs baldmöglichst beseitigen.

Update zu Opensuse 42.3 – kleine Probleme mit nvidia und libvirt/kvm

Posted on by

Das aktuelle Drama um Meltdown und Spectre verlangt auch von Linux-Usern starke Nerven. Bei Opensuse steht zudem das Auslaufen des Support-Zeitraums für Opensuse Leap 42.2 an. Es lohnt sich also, hier auch noch ein Upgrade betroffener Systeme auf Opensuse Leap 42.3 vorzunehmen. In der Reihenfolge

  1. Anwendung aktueller Kernel-Patches (man suche z.B. unter YaST > Software Management” mit dem Begriff “kernel” nach entsprechenden RPM-Paketen und deren Updates) sowie von Intel- bzw. AMD-Microcode-Patches (Pakete “ucode-intel”, “ucode-intel-blob” bzw. “ucode-amd”) unter Opensuse Leap 42.2.
  2. Bei Einsatz von qemu, kvm, libvirt: Update entsprechender Pakete unter Leap 42.2.
  3. Upgrade auf Opensuse Leap 42.3 (z.B. gem. der Anleitung unter https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/)
  4. Soweit dann noch nötig: Anwendung aktueller Kernel-Patches, von Intel- bzw. AMD-Microcode-Patches und Updates von qemu/kvm/libvirt-Paketen unter Leap 42.3
  5. [Für Mutige (und Sicherheitsbewusste): Upgrade auf ein aktuelles Kernel-Paket zur Version 4.14 aus dem “kernel”-Repository “http://download.opensuse.org/repositories/Kernel:/stable/standard/”.]

Das klappt eigentlich ganz gut. Bei zwei Systemen bin ich dabei im Zuge des Standard-Upgrades aber auf zwei kleinere Problemchen mit “kvm/qemu” und dem proprietären “Nvidia”-Treiber gestoßen.

Nvidia-Problem => Deinstallation des Pakets “drm-kmp-default”

Im Zuge der Installation des proprietären Nvidia-Treibers (z.B. über das Installations-File “NVIDIA-Linux-x86_64-384.98.run”), den man sich von der Nvidia-Web-Site laden kann, klappt zwar die Kompilation des Treibers, nicht aber das Laden des Moduls “nvidia-drm.ko”. Es kommt eine entsprechende Meldung zum Fehlschlag der Nvidia-Installation. Ursache ist ein Paket “drm-kmp-default”, das aus mir nicht nachvollziehbaren Gründen installiert wird, aber in seiner Version nicht zum aktualisierten Default-Kernel (z.Z. 4.4.104-39.1) des Leap 42.3-Systems passt. Hier hilft es, das Paket “drm-kmp-default” zu deinstallieren. Das “drm”-Modul wird dennoch geladen und vom Modul “drm-nvidia” auch korrekt verwendet.

qemu/kvm-Problem: Korrekten Eintrag zu “namespaces” in der Datei qemu.conf vornehmen

Nach dem Upgrade auf Leap 42.3 und Aktualisierung aller Virtualisierungspakete ließen sich leider keine KVM-Gastsysteme mehr starten. Ich erhielt ganz unabhängig von der Art des Gastes und dessen Betriebssystem eine Meldung der Art:

Error starting domain: internal error: child reported: Kernel does not provide mount namespace: Permission denied

Ursache ist ein fehlender Eintrag

#namespaces = [ “mount” ]
namespaces = []

(bzw. ein unwirksamer Default-Eintrag (namespaces = [ “mount” ])) in der Datei “/etc/libvirt/qemu.conf”.
Ich tippe darauf, dass dieses Problem durch Rückportierungen bestimmter neuer Kernel-Features auf die relativ veraltete 4.4-Version von Leap 42.3 verursacht wurde. Im Standard-4.4-Kernel brauchte man den Eintrag in der vorliegenden Form nämlich nicht. Auf die Lösung dieses Problems bin ich nicht selbst gekommen; s. zu diesem Thema die unten angegebenen Links.

Viel Spaß weiterhin mit Opensuse – trotz des aktuellen Security Super-GAUs. Das beste Gegenmittel gegen Spectre ist – neben laufenden System-Updates – maximale Vorsicht beim Öffnen jeglicher externer Quellen, das Verifizieren von Update-Quellen für System- und Anwendungsdateien und das Verifizieren von Web-Sites im Internet über https-Verbindungen, das Kontrollieren der Hash-Summen für alle Updates sowie der Einsatz von “Noscript
“-Plugins in euren Browsern. Soweit ich das verstehe, erfordert ein Ausnutzen der Spectre-Schwachstelle in den aktuellen Prozessoren das Ausführen malignen Codes. Ein Einfangen von Schadcode muss man vermeiden – diese Binsenwahrheit gilt und erfordert nunmehr weiter erhöhte Wachsamkeit – im besonderen beim Browsen im Internet.

Vielleicht denken einige Unternehmen und Webseiten-Programmierer nun auch wieder ein wenig mehr darüber nach, ob und wann Javascript für den Betrieb einer öffentlichen Web-Seite überhaupt erforderlich ist. Auf vielen Seiten erfolgt der Einsatz oftmals weniger aus funktionalen Gründen als vielmehr deshalb, damit das Nutzerverhalten aus kommerziellen Gründen getrackt werden kann …..

Links

https://forums.opensuse.org/showthread.php/527697-Can-t-load-nvidia-drm-ko-after-update
https://forums.opensuse.org/showthread.php/527394-KVM-guest-will-not-start-with-latest-version-of-kernel
https://www.redhat.com/archives/libvirt-users/2017-March/msg00033.html
https://www.redhat.com/archives/libvirt-users/2017-March/msg00035.html