programmierer-nachrichten.de
Startseite Podcast RSS Impressum

Podcast Folge 2


Wie versprochen der wöchentliche Podcast! Heute nun "schon" Folge 2. In dieser Folge sabbel ich über Cloudbleed, also über die Sicherheitspanne bei Cloudflare, über den neuen Delphi Compiler für Linux, über die erste praktische Kollision in SHA-1 (jawoll! SHA-1 wurde bezwungen!), und über neue ECMAScript Features in Firefox.

Nimm dir Zeit, denn dieses Mal habe ich leider die 2-Stunden Marke gesprengt :(. Such den Podcast über iTunes, tunein oder in deiner Podcast App. Mit "programmierer nachrichten" wirst du meinen Podcast finden. Oder aber nutze die Möglichkeit die Folge hier im Webbrowser abzuspielen. Oder aber du lädst dir die Folge als Datei runter.

Ich wünsche dir viel Spaß!


Cloudflare Proxy Fehler legt geschützte Daten offen


Cloudflare ist Anbieter eines Content Delivery Networks; wenn man also sicherstellen möchte, dass seine Inhalte weltweit schnell erreichbar sind, dann wählt man oft solche Anbieter, da sowas in der Regel günstiger ist als überall auf der Welt eigene Server aufzustellen. Cloudflare ist nur einer von vielen Anbietern, jedoch einer der größten. Cloudflare bietet auch Schutz gegenüber DDoS Attacken.

Cloudflare bietet auch an statische Inhalte über HTTPS bereitzustellen. Dafür setzt Cloudflare Software ein. Diese Software ersetzt auch Links innerhalb des HTML mit HTTPS Links.

Was ist also passiert? Am 19.02.2017 hat Tavis Ormandy eine Sicherheitslücke auf den Cloudflare Servern entdeckt. Ihm sind eigenwillige Informationen aufgefallen. Er konnte mit den Daten erst nichts anfangen. Aber dann verstand er die Daten.

Die Software, welche die Inhalte analysiert und neu zusammensetzt, also der Proxy, hatte einen Fehler, welcher zu einem Speicherüberlauf führte. Dieser Fehler führte dazu, dass Inhalte fälschlicherweise aus dem Speicher in die HTML-Seite injiziert wurde.

Und da Cloudflare für sehr viele Webseiten alle HTTP-Requests entgegen nimmt, werden die Request-Daten im flüchtigen Arbeitsspeicher von Cloudflare gespeichert. Durch diesen Fehler war es nun möglich, dass man sensible Daten als Dritter im Inhalt von Websites sehen konnte. Schlimmer noch: die Suchmaschinen haben diese Daten indexiert. So waren alle diese sensiblen Daten bei Google zu finden. Google hat diese Daten mittlerweile gelöscht. Fraglich ist aber, wer die Daten in der Zeit noch indexiert hat. Der Fehler war mehrere Monate vorhanden.

Oder um es noch einfacher zu beschreiben: wenn eine Website Cloudflare nutzt, und man sich auf der Website mit seinen Daten anmeldet, so werden die Daten zwar (hoffentlich) via HTTPS übertragen, aber in den seltensten Fällen auch clientseitig verschlüsselt, bevor sie zum Server gesendet werden. In den meisten Fällen werden Benutzername und Passwort in Klartext zum Server übertragen (wie gesagt: heute meist über HTTPS). In diesem Fall wären die Daten, also dein Benutzername und Passwort, vermutlich durch diesen Fehler veröffentlicht worden. Es besteht eine nicht geringe Wahrscheinlichkeit, dass Google deinen Benutzernamen und dein Passwort indexiert hat, weil Cloudflare die POST-Daten in die HTTP-Antwort mit injiziert hat. Unbeabsichtigt durch einen Speicherüberlauf.

Wie gefährlich ist diese Sicherheitslücke? Google hat schnell reagiert und alle Einträge in ihrem Index, die hier zutreffen, gelöscht. Das verhindert gezielte Suchen nach entsprechenden Daten. Jedoch kann niemand wissen, wer zwischenzeitlich die Daten indexiert hat. SOMIT sollten bei dir alle Alarmglocken schlagen, denn das Ausmaß ist riesig.

Welche Webseiten sind betroffen? Es gibt zwar auf Github riesige Listen, aber die sind nicht sehr hilfreich, da sie alle Webseiten auflisten, die den DNS-Dienst von Cloudflare nutzen. Cloudflare selbst spielt die Sicherheitslücke etwas runter. Dieses Verhalten hat bei vielen Programmierern und Sicherheitsexperten Verunsicherung ausgelöst, um es freundlich zu beschreiben.

Du darfst gespannt sein, welche Daten durch diese Sicherheitslücke fälschlicherweise veröffentlicht wurden.


SHA-1 Hash Algorithmus in der Praxis geknackt


SHA-1 ist ein populärer Hash Algorithmus, welcher benutzt werden kann, um für Daten jeglicher Form einen Hashwert zu generieren. Dieser Hashwert sollte für alle unterschiedlichen Daten einen einzigartigen Wert generieren.

Wenn ich also eine Textdatei produziere und dafür einen Hashwert erzeuge, so kann man diesen Wert dafür benutzen, um zu beurteilen, ob die Textdatei immer noch die ist, die ich produziert habe. Denn, wenn man nur ein Bit in dieser Textdatei ändert, so ändert sich bereits der Hashwert und man weiß, dass die Datei verändert wurde.

Ein Softwarehersteller möchte sicherstellen, dass die heruntergeladene Software auch dem entspricht, was er erzeugt hat. Der Softwarehersteller erzeugt also von seiner Software einen SHA-1 Hashwert und kommuniziert diesen mit dem Kunden. Er veröffentlicht den Wert auf seiner Website oder wie auch immer. Der Kunde lädt dann die Software runter und erzeugt lokal auf seiner Festplatte den SHA-1 Hashwert, um sicherzustellen, dass er auch die originale Datei runtergeladen hat und nicht irgendeine mit einem Virus zum Beispiel.

Und genau an dieser Stelle scheitert SHA-1. Es ist mit SHA-1 möglich, dass 2 verschiedene Dateien den gleichen Hashwert errechnet bekommen. Man spricht dann von einer Kollision.

Marc Stevens und Pierre Karpman von der CWI Amsterdam, eine Universität, als auch Elie Bursztein, Ange Albertini und Yarik Markov von Google Research haben nun auch in der Praxis eine Kollision herbeigeführt und sie auf der Website "shattered.io" veröffentlicht. Dort findet man 2 verschiedene PDF-Dateien mit identischem Hashwert. Außerdem findet man dort Dokumente, die beschreiben, wie sie die Kollision erzeugt haben.

In der Praxis bedeutet dies, dass man den SHA-1 Hash Algorithmus nicht mehr verwenden sollte. Die realistische Gefahr ist aktuell gering, da es sehr teuer wäre eine Kollision zu berechnen, aber da sie nun praktisch vorgeführt wurde, ist das eben nicht undenkbar.


Firefox 54 implementiert ECMAScript 2016 und Teile von ECMAScript 2017


Mozilla Firefox 54 unterstützt nun zu 100% ECMAScript 2016. Aber das reichte dem Entwickler Team nicht. Obwohl ECMAScript 2017 noch in der Entwicklung und nicht abgeschlossen ist, hat das Firefox Entwicklungsteam damit begonnen auch Sprachkonstrukte aus ECMAScript 2017 in Version 54 zu implementieren.

In ECMAScript 2016 neu dazugekommen sind u.a. der Hochzahl Operator **. In Arrays kann man nun auch mit include suchen. Wenn man Daten mit dem Rest-Operator destrukturieren möchte, kann man das nun auch verschachtelt tun.

Aus ECMAScript 2017 wird async und await implementiert. In ECMAScript 2015 hatte man ja bereits Promises eingeführt, womit man schon ein sehr gutes Mittel gegen die Callback-Hölle hatte. Promises konnten einfach in bestehende Implementationen eingebaut werden und waren für den "Client", also den Bediener der Funktion auch recht übersichtlich und einfach zu bewerten. async und await dienen dazu die Übersichtlichkeit und Bewertbarkeit von Promises weiter zu verbessern. Es ist ein weiterer Layer oberhalb von Promises.

Alle diese neuen Features funktionieren auch bereits im stabilen Chrome und Chromium.


Embarcadero entwickelt Delphi Compiler für Linux


Embarcadero entwickelt einen Delphi Compiler für Linux! Am 1. März findet ein Webinar statt, wo man Interessierte dieses Produkt näher bringt. In der Zukunft wird es vielleicht auch einen Linux Delphi Compiler für ARM geben, aber das steht noch nicht fest.

Ich selber habe ja eine lange Geschichte mit Delphi und finde die Sprache an sich nicht schlecht. Sie hat alle modernen Features und der Compiler ist rasend schnell. Aber irgendwie hat Delphi mit Borland einen sehr schlechten Ruf bekommen. Wie auch immer; Delphi ist sehr unbeliebt.

Ich bin gespannt, welchen Markt Embarcadero hier wiederbeleben möchte.


Mit 40 Jahren noch programmieren?


Ist man mit 40 schon zu alt, um als Programmierer zu arbeiten? Bei Jobgesuchen bekommt man ja immer den Eindruck, dass man viel Berufserfahrung sucht, aber all zu alt sollte man dann auch nicht sein. Das steht zwar nirgendwo, aber jeder weiß es. Man will 30 Jahre Berufserfahrung inklusive Studium bei einem maximalen Alter von 35 Jahren :). Und man soll sich natürlich auch in neuen Technologien auskennen. Wenn node.js 2 Jahre alt ist, muss man 3 Jahre Berufserfahrung mit node.js haben ;). Manchmal liest es sich aber tatsächlich so :).

In vielen Firmen wird falsch und knapp geplant. Stressige Überstunden sind das Resultat. Das gefällt nicht jedem älteren Menschen. Deswegen bevorzugt man jüngere Menschen, da sie soetwas eher mitmachen als alte Menschen. Zwar gefällt das auch den jungen Menschen irgendwann nicht mehr, aber das ist den Firmen ja egal. Hauptsache man hatte für den Moment die notwendige Ausbeute. Das klingt hart, aber ist so unrealistisch nicht. Alte Menschen haben meist andere Prioritäten. Junge Menschen haben ihr Leben noch nicht geformt und lassen sich leicht von Firmen beeinflussen. Alte Menschen sind wie alte Hunde; gefährlich und nicht mehr zu verrücken. Alles nicht ganz falsch :).

Ja, mmh...sollte man also mit 40 noch programmieren? Ja unbedingt! Wenn man sich selbst diese Frage stellt, so sollte die Antwort "ja" lauten. Nun könnte man meinen, dass ich selbst schon 40 Jahre alt bin und es deswegen gut finde. Nein, so alt bin ich noch nicht, aber allzu weit weg bin ich auch nicht mehr :).

Die meisten Programmierer versuchen irgendwann mehr aus ihrem Job herauszuholen. Ist das so sinnvoll wie es klingt? Im Grunde ist das Bestreben nach mehr Erfolg ja nicht so verkehrt; zumindest klingt es nicht falsch; aber ein normaler Programmierer hat es in der Regel doch schwer mehr zu sein als er ist. Oh, und diesen Satz bitte mal verdauen. Man sollte nämlich nie vergessen welchen Beruf man gelernt hat.

Ich bin Programmierer. Ich versuche darin gut zu sein. Ich versuche mich zu verbessern. Aber einige Programmierer wollen die Karriereleiter aufsteigen, ohne ein besserer Programmierer zu werden. Sie nutzen oft die Möglichkeit innerhalb einer Firma einen ganz anderen Job auszuüben. Erfahrene Programmierer beobachten nicht selten, dass mittelmäßige Programmierer auf einmal Führungspositionen einnehmen. Die erfahrenen Programmierer stört das in der Regel nicht, da das keinen wirklichen Verlust darstellt.

Offen gesagt sind viele Programmierer völlig fehlgeleitet. Sie denken, dass die nächste Stufe ihrer Karriereleiter in Führung von Personal ist. Das kann natürlich eine Option sein, aber jemand, der Anwendungsentwicklung als Beruf gelernt hat, hat oft einfach nicht die Kompetenzen außerhalb der Programmierung zu arbeiten. Natürlich kann man sich diese Kompetenz aneignen, aber wieso nicht den eigenen Job verbessern? Wenn ich Programmierer bin, dann versuche ich ja nicht ein guter Autoverkäufer zu sein. Immerhin hatte es irgendwie seine Gründe wieso ich stundenlang vor einem Monitor sitze und kryptische Zeilen in die Tastatur hacke. Wenn ich ein Kommunikationstalent wäre, würde ich nicht als Programmierer arbeiten.

Und genau diese Sichtweise fehlt den meisten Programmierern. Ich gebe zu, es ist heute nicht ganz leicht sich auf etwas zu konzentrieren, da wir andauernd mit neuen Technologien bombardiert werden, aber es ist nicht ausgeschlossen.

Dennis Ritchie, Ken Thompson und Brian W. Kernighan sind gute Beispiele für Programmierer, die ihre Profession einfach immer weiter verbessert haben. Es spricht also rein gar nichts dagegen auch mit etwas höherem Alter noch zu programmieren.


Archiv nach Kalenderwochen


2017/KW24, 2017/KW23, 2017/KW22, 2017/KW21, 2017/KW20, 2017/KW19, 2017/KW18, 2017/KW17, 2017/KW16, 2017/KW15, 2017/KW14, 2017/KW13, 2017/KW12, 2017/KW11, 2017/KW10, 2017/KW9, 2017/KW8, 2017/KW7


Startseite Podcast RSS Impressum