Ja hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast in der 26. Episode heute.
Heute ist das Thema Security, ein Thema was ich persönlich sehr sehr spannend finde.
Da haben wir natürlich auch wieder Gäste eingeladen, neben dem Jochen und mir, dem Dominik,
sind heute wieder dabei der Christian, der Toini und der Philipp. Hallo Philipp!
Hallo!
Wie geht es euch? Stellt euch doch mal kurz vor, wer ihr denn seid und dann erzählen wir ein bisschen was über die Folge.
Tja, wer fängt an? Also ich bin der Jochen.
im Podcast.
Das habt ihr mich wahrscheinlich schon
einmal dabei gehabt.
Also ich glaube, das brauche ich gar nicht weiter ausführen.
Aber ich glaube, am interessantesten ist wahrscheinlich
Philipp, der ist jetzt gerade zum ersten Mal dabei.
Genau.
Ich bin Philipp, ich habe bis vor kurzem
noch an der Uni Düsseldorf
studiert und nachher auch
gelehrt zum Thema unter anderem auch Security.
Also ich habe da die Vorlesung zur
Internet Security, glaube ich.
Oder wie haben sie sie genannt? Also Internet Security,
einfach Security.
die Security-Vorlesung gehalten.
Netzwerk haben wir sie genannt.
Also Netzwerksicherheit sieht sie offiziell.
Und bin jetzt seit
zweieinhalb Jahren arbeite ich für die Firma
Boxine in Düsseldorf.
Die ist wahrscheinlich bekannt durch ihr Produkt
die Tonybox. Also wenn man keine Kinder hat,
dann kennt man die Tonybox.
Und genau die läuft auch mit Python.
Vielleicht kommen wir da nochmal ein bisschen dazu.
Oh cool, da haben wir letztens am Wochenende noch jemanden getroffen,
der für die Firma arbeitet. Interessant.
Ja, ja, ich habe mich letztes Wochenende genau mit Jens,
deswegen kannst du dann wahrscheinlich auch lange unterhalten.
Genau, der Jens ist auch in meinem Team. Jens ist auch
einer von den Python-Entwicklern
bei Boxine.
Ja, die
Tonybox ist super beliebt.
Ja, dass es ein Python-Projekt geworden ist.
Ihr kennt ja bestimmt, das sind diese kleinen Spielzeug-
Figuren, die man auf eine Box stellt und dann
spielen sie ein Hörspiel. Also für alle, die keine Kinder
haben.
Genau. Ja, schön. Also heute
das Thema Security. Wir wollen das so ein bisschen aus
mehreren Perspektiven beleuchten, die wir noch gar nicht
so genau festgelegt haben. Sie immer, ich habe
keine Ahnung, stell du mir Fragen. Und
und die Jungs antworten ein bisschen.
Ja, fangen wir doch direkt an.
Was ist denn Sicherheit? Security?
Was meint das denn? Also, dass
niemand irgendwie einbricht und dann hat jemand irgendwie
einen kaputten Pullover an und dann riecht dann so ein Rechner
mit grüner Schrift und dunklem Monitor
oder wie sieht das aus?
Das trifft es wahrscheinlich schon ziemlich
gut.
Du möchtest Leute
schützen davor,
oder du möchtest
Systeme schützen vor irgendwelchen
Angreifern. Das ist das grundsätzliche Prinzip
für Sicherheit. Du hast dann verschiedene Ziele.
Ganz traditionell hat man die Integrität,
dass ich sagen möchte, niemand möchte etwas ändern.
Ich habe die Vertraulichkeit, dass ich sagen möchte,
niemand soll rausfinden können,
welche Daten meine Benutzer haben. Zum Beispiel bei uns
beruflich bei der Tonybox. Auf die kann man
ja beliebige Audio-Teilen draufspielen und es soll
auf keinen Fall möglich sein, dass irgendjemand anders die Audio-Teilen
von einem Kunden
abrufen kann. Das wäre
Vertraulichkeit. Und dann haben wir noch
Ziele, die werden
manchmal so Zuverlässigkeit genannt oder
Availability, wo es halt
darum geht, dass das System verfügbar
ist die ganze Zeit.
Okay, also schon irgendwas, was einen auch privat
betreffen kann natürlich und vor dem man vielleicht
geschützt werden möchte.
Ja, und
wie macht man das denn in Python?
Ja, ich würde jetzt so spontan
sagen, eigentlich hat man ja in Python schon mal ganz gute
Karten, weil ein großer Teil der wirklich
bösen Fehler, die einem da so
begegnen können, hat man jetzt in Python
eigentlich gar nicht. Also so mit Buffer-Overflows
hat man eigentlich eher nicht so wirklich viel zu tun.
Obwohl, jetzt eigentlich schon wieder, dem müsste ich erklären, was das ist.
Oh nein, das wollte ich schon.
Wir sind direkt eingeschrieben, du hast gesagt, man kann Fehler machen und das bedeutet,
dass Fehler zu Sicherheitslücken
führen können, die dann Angreifer ausnutzen können.
Ist vielleicht einer der Punkte, über die wir vielleicht reden,
welche Sicherheitslücken es denn gibt, aber was du sagst,
heißt, es gibt Fehler, die jemand gemacht hat, also
ein Entwickler, eine Entwicklerin gemacht hat, die
dazu führen, dass es
schwierig wird?
Genau, das Programm macht dann irgendwas, was
der Entwickler nicht gedacht hat. Also der Entwickler dachte sich,
okay, da kommen doch immer gute Daten
und dann hat
und jemand mit einem grünen Bildschirm und einem Kapuzenpulli nachher herausgefunden,
okay, wenn ich ganz bestimmte Daten sende, dann macht das Programm etwas, was der Entwickler nicht wollte
und erlaubt mir dann Zugriff auf irgendwelche geheimen Daten oder im schlimmsten Fall erlaubt mir sogar Code auszuführen bei irgendjemand.
Genau das wollen wir halt verhindern und da gibt es halt eine ganze Menge Schwachstellen,
je nachdem auf welcher Plattform man ist.
Also zum Beispiel auch mit Python gibt es Unterschiede natürlich, wenn ich einen Treiber schreibe,
dann kann auch der erwähnte Buffer-Overflow vielleicht schon mal passieren.
Wenn ich mit Python eher
eine Web-Anwendung schreibe, dann muss ich mir da halt
typische Sicherheitsblicken anschauen
Aber das ist eigentlich immer, dass ich irgendwelche Eingaben
des Benutzers nicht richtig
interpretiere und dann plötzlich komische Sachen mache
Benutzereingabe, Speicher, also Buffer, Overflow
vielleicht nochmal ganz kurz, der Speicher
läuft voll und dann kommt man in Bereiche rein
die das Programm gar nicht vorgesehen hat
und dann passieren komische magische Dinge
Das ist dann diese Blackbox
Mensch mit dem Kapuzzer-Kolore
Naja, also ganz ganz kurz
irgendwie, ja, ist auch eine relativ spezielle Art von Sicherheitsproblem, aber das gab
irgendwann, ich glaube, das war dann Mitte der 90er, ich weiß nicht mehr so ganz genau, gab es einen Artikel
im Frag Magazine von Aleph One
irgendwie, Smashing the Stack for Fun and Profit und
es betrifft vor allen Dingen die Programmiersprache C, die ist halt, das sind Strings
Nullpointer terminiert und, naja,
wenn man... Ach so! Genau, also da steht nicht
anzuzwingen vorher dran, der ist jetzt so und so lang
und dann liest man halt nur bis da,
sondern man liest halt so lange, bis halt ein Nullbyte
kommt und dann hört man halt auf damit.
Oder halt eben auch nicht, wenn man irgendwie das
falsch macht. Ah, das heißt, wenn man am Ende sagt, da sind gar
keine Nullbytes, sondern sein eigener Code, dann liest er
gar nicht, liest er es immer noch weiter. Genau, wenn man
zum Beispiel einen festen Buffer definiert hat
aber nicht überprüft,
ob die Eingabe von dem Benutzer halt
vielleicht länger ist, dann kann man halt über den Buffer
hinwegschreiben unter Umständen.
Und dann halt auch, also was man dann
macht, man schreibt dann irgendwie eine Menge
NOPS, was ist das?
Irgendwas A oder so
rein, hofft dann, dass
beim Rücksprung aus der Funktion irgendwie
man in diesem Bereich landet und dann rutscht
es halt durch bis zu einem Shell-Code, den man mit reingeschrieben
hat und dann kann man also im besten Fall
irgendwie direkt das Programm
komplett übernehmen.
Das war
lange Zeit,
viel Server-Software hatte
diese Fehler und man konnte das halt ausnutzen.
Obwohl, ich meine, heute spielt
ist vielleicht auch immer noch eine Rolle, vielleicht eher so bei Clients, ich glaube Server,
obwohl es gibt es vielleicht immer noch, ich weiß es nicht mehr so genau,
ich habe auch lange nicht mehr drauf geguckt,
aber das ist eigentlich genau so das, was sich Leute vielleicht vorstellen,
wenn man davon redet, dass jetzt irgendwie irgendwelche Server gehackt werden oder so.
Man gibt irgendwas ein oder führt ein Programm aus
und dann hat man eine Shell auf einem anderen System,
wo man einfach Code ausführen kann oder beliebige Kommandos.
Da kann man auch tatsächlich sozusagen diese Perspektiven von
man muss halt, da kann man nochmal einen ganzen Schritt zurückgehen, weil im Prinzip
das Thema Sicherheit kann man noch weiter aufmachen
wenn ich halt, Philipp hat gesagt Anwenderinput
das ist so ein, das muss oder kann man noch weiter abstrahieren, weil
im Prinzip sind Viren halt auch nichts anderes als Anwenderinput
Das ganze Thema von Security
und die Programme, die man nicht will,
lässt sich halt stark darauf zurückführen,
dass wir halt eine sogenannte
von-Neumann-Architektur haben.
Das geht halt zurück auf die,
was weiß ich jetzt, gar nicht mehr.
Mir wurde mal vorher erworfen,
Opa redet vom Krieg,
aber da war ich nicht dabei.
60er, 70er, irgendwo da, noch älter,
40er, von-Neumann-Architektur, noch älter.
Das war vor dem Zweiten Weltkrieg wahrscheinlich sogar.
und irgendwo da, also als es so richtig losging gerade erst mit den ganzen allgemeinen Rechenmaschinen
und die Von-Neumann-Architektur hat halt ein wichtiges Konzept und das ist halt, dass der Programmspeicher mit der Datenspeicher einzeln.
Es gab früher Rechnerarchitekturen, da waren Daten von der Eingabe und die Daten, die den Prozessor gesteuert haben,
also das Programm, komplett getrennt
macht halt das
große Problem, dass du nicht einfach
irgendwie Programme als Daten runterladen
und ausführen kannst, also der Effekt, den wir dadurch
haben von der Neumann Architektur ist ja, ich kann ins Internet
gehen, kann mir Daten runterladen
und die dann als Programm ausführen, das Problem ist
aber
der Vorteil ist gleichzeitig der Nachteil, das heißt
auch Daten, die vielleicht gar nicht als Programm
gedacht waren, werden als
Programm ausgeführt und das ist sozusagen die ganze
Krux da dran, dass die CPU
schon nicht unterscheiden kann von
sind die Bytes bei mir gerade
gedacht für, ich soll mit ihnen rechnen
oder ich soll damit meinen
Instruction Pointer befüttern.
Das kannst du halt, da gibt es ein
dieses Grundproblem wird never ever
jemals weggehen. Das geht nie weg.
Na gut, also
moderne CPUs haben ja durchaus
einige Verteidigungen dagegen.
Moderne CPUs haben einen Marker, wo
drin steht, okay, diese Speicherseite
ist ausfüllbar oder nicht.
Das geht ja dann schon in Richtung
der konkurrierenden Harvard-Architektur ein bisschen, dass man sagt,
okay, das sind die Daten, das sind die Instruktionen.
Aber
natürlich gibt es immer noch Tricks. Also selbst bei den
Buffer-Overflows gibt es halt
sehr, sehr viele Möglichkeiten,
wie man genau
dann doch irgendwie noch ein Programm
konstruieren kann, das halt eigentlich nur aus Daten besteht.
Also wo du sagst, okay, das sind eigentlich nur Daten,
aber die auf
komischen Stellen liegen und dann trotzdem den
Programmfluss irgendwie beeinflussen.
Ich wollte eigentlich zu dieser Frage
mit den, was machen denn die CPUs dann da falsch?
Kannst du zum Schluss kommen? Ihr habt ja jetzt damit
den Einstieg gefunden.
Das ist die unterste Ebene, auf der wir jetzt
anfangen. Ich finde das aber sehr spannend, weil was du
sagtest, dass diese unterschiedlichen Architekturen,
also ich glaube, von Neumann nennt man auch irgendwie
Princeton-Architektur und ich glaube, es war irgendwie,
ich habe gerade nachgeguckt, 1945, als
sie rausgekommen ist und diese
Harvard-Architektur, die daneben liegt, die macht
halt diese Getrennung von Daten und
Programmspeicher und du sagst jetzt, es gibt
auf dem CPU, also der CPU
benutzt für alle Menschen, die
vielleicht nicht so drin ist,
Opcodes, also Operation Codes,
das heißt, die sagen, was für eine Rechenoperation
der machen soll, der Kern,
und dann macht der genau mit den Daten,
die ihm dazugeschickt werden,
in den einzelnen, was sind das,
Stacks? Nein, Registern.
Macht der dann diese Operation
und
da kann was schief gehen.
Philipp, vielleicht kannst du das noch ein bisschen
erklären, weil das klingt ja sehr spannend.
Ja, weil
wenn ich einen ganz klassischen Buffer-Overflow habe,
und der Angeber gibt eine längere Datenfolge an.
Und wie wir eben schon erwähnt haben, da könnten dann zum Beispiel verschiedene Instruktionen wie
Nobcodes drin vorkommen. Und das sieht aus wie
normaler Text, aber das ist halt genauso
designt, dass man das auch als Obcodes für die CPU interpretieren kann.
Und genau das ist das Problem danach, dass der Entwickler dachte, okay, da kommt einfach nur Text
rein, aber in Wirklichkeit hat der Angreifer den Text so geschickt konstruiert, dass er ein
gültiges Programm ist.
Und es ist sozusagen, wir können für die CPU, weil das konkret zu machen ist häufig sehr schwer
so im Luftlernraum, aber weswegen ich schnell zur
Neumann-Architektur gegangen bin, ist, das Problem ist ein ganz grundsätzliches
Architekturproblem und die Features, die wir jetzt da oben
drüberlegen, wie zum Beispiel non-executable pages und so ein Kram,
oder was dann halt auf anderen Ebenen kommt
Address Randomization und so ein Zeug.
Das sind alles bloß
kleine Trostpflaster
und man macht es den Angreifern schwerer und teilweise auch
um Größenordnungen schwerer dagegen anzukommen,
aber das Restrisiko kann in der Architektur
halt nie weggehen. Sie wird nie weggehen und die Effekte,
die wir aber sehen, lassen sich auf anderen Ebenen genauso
wieder erklären und ein Buffer-Overflow lässt sich gut vergleichen und das ist für viele Leute wieder einfacher vorstellbar
wie mit einer SQL-Injection. Das ist genau das gleiche. Eine SQL-Injection ist, gib hier bitte deinen Namen ein
und dann kommt das berühmte, mein Name ist Bobby, bla bla bla, Semikolon, Drop Tables.
Und auch da ist es so, das Programm hat gedacht, ich habe eine Eingabe und die Datenbank haut dann aber einmal
und sagt, das ist doch jetzt die nächste Query hier.
Weil wir drücken ja alles als Text aus.
Der Name ist Text und das Programmierstatement für die SQL-Datenbank ist auch nur Text
und wird dann aber eben als Programm interpretiert.
Und wenn ich das eben nicht richtig escape an der Stelle,
dann finden solche Modusübergänge statt, wo etwas, was eigentlich als Eingabe zu verarbeiten gewesen wäre.
Und der Trick ist ja eben der von Neumann Architektur,
das SQL-Statement, was ich an den Server drücke, ist ja aus Serverperspektive erst mal Daten,
die als Programm zu interpretieren sind.
Und wenn darin halt Mist stattfindet, dann geht da alles quer durcheinander.
Und das ist in Buffer-Overflow im Prinzip nichts anderes.
Also das Glas Milch, das zu voll ist und dann tropft das auf die Erde und dann hat man alles nass und denkt sich, oh nein.
Ja, genau.
Buffer-Overflow ist sozusagen die Variante von, das Glas ist zu voll.
und auch Python schützt einen
vor sowas im Prinzip erstmal nur
im Sinne von, ja Python selber gibt sich extrem
viel Mühe selber keinen Mist zu machen,
wenn du aber, und ich hab mit sowas halt selber
auch, also ich sag immer,
ich fass C nur dann an, wenn die anderen es verrissen haben.
Ich schreib nie C-Code
neu. Ich hab den C-Code nur in der Hand,
wenn die anderen es völlig kaputt gemacht haben
und ich gerade so noch weiß, wie ich es mir ganz mache.
Der Pleiko-PG
ist zum Beispiel halt im Datenbankumfeld,
da merkt man so,
und das ist ein bisschen
und die Programmiersprache Python.
haben ein Minuszeichen drin. ISO 8501 und so Kram. Und im Psycho-PG ist es so, dass der Encoding-Buffer tatsächlich davon ausgeht, dass da ein Minus drin ist und sie meinten, es wäre eine gute Idee, sie müssen alles normieren und die Minusse rausnehmen.
und das ist im Postgres auch okay.
Der hat die ganzen Encoding-Namen auch immer noch mit ohne Minus rumliegen
und ein Kunde von uns kam aber dann damals auf die Idee,
es gibt in Postgres einen Alias für UTF-8, der heißt Unicode.
So, und dann hat der Psycho halt gesagt, na jetzt kommt hier ein Encoding-Name,
also streiche ich das Minus raus, also ziehe einen neuen Buffer, der genau ein Byte kürzer ist
und schreibt dann Unicode ohne Minus in einen statt, was haben es, U-N-I-C-O-D-E,
in einen 6-Byte langen Buffer statt in einen 7-Byte langen Buffer.
Und weil sie aber nicht einfach nur malloc benutzt haben,
weil ganz kleine Objekte zu alloziieren im Speicher halt ineffizient sein kann,
hat Python einen sogenannten Small Object Allocator.
Damit kann ich eine Page, die ist typischerweise ein K oder sowas,
je nachdem, das System kann ja auch ein Megabyte oder größer sein,
aber gehen wir mal von einem K aus oder 4K,
und dann packt Python halt solche 6-Byte-Objekte alle zusammen in eine Page
und dann brauche ich halt statt 200 Pages, also statt 200k nur 1k,
die werden eng an eng hintereinander gepackt
und was dann passiert ist, ist, dass der Server, der das hatte, so alle Woche mal gecrashed ist.
und ich habe das halt versucht rauszufinden und irgendwann habe ich da mit, ich glaube, ich habe mit Guido mal reingeguckt, ich habe mit Martin von Löwis reingeguckt, mit ein paar Leuten und irgendwann haben wir festgestellt, der schreibt dann halt manchmal genau auf den letzten Eintrag in dieser Page dieses eine Byte zu viel und das eine Byte zu viel in einer sogenannten Arena im Small Object Allocator ist der Pointer auf die nächste Arena.
und der landet dann halt im Nirvana
und dann gibt es halt einen Zagfault
und dann sagt das Linux halt, so geht es hier nicht.
Und das ist ein typisches Beispiel für,
da hat jemand dann einen zu kleinen Buffer alloziiert,
das ist dann ein Buffer-Overflow,
er schreibt mehr Daten rein, als da reingehören,
weil er sich einfach bloß verrechnet hat
und der Effekt muss noch nicht sein,
dass jemand Code ausführen kann,
aber der Effekt ist halt typischerweise,
dass das Programm anfängt Müll zu machen
und dann haben wir, Philipp hat da ja auch genickt,
schon mal die Availability, die Verfügbarkeit
von der Anwendung reduziert und das ist ein Sicherheitsproblem tatsächlich auch.
Genau, es könnte auch dann sein, dass das nachher auf dem Server irgendwo läuft, wo dein Postgres läuft und das kann
vielleicht auch jemand, den Server möchtest du für viele Kunden bereitstellen und dann
ist es auch richtig kritisch, wobei hoffentlich niemand dein Encoding im Server
steuern kann, das wäre wahrscheinlich eine andere Sicherheitslücke.
Ja, aber also Denial of Service ist halt, das ist böser, als die meisten Leute so
zunächst vermuten würden. Ich meine, wir hatten ja jetzt auch letztens irgendwann in Düsseldorf an der Uniklinik
ja auch so einen eher gemeinen Fall.
Irgendwie so diese
Ransomware-Geschichten, die es da gibt. Ich weiß nicht, das war
irgendeine Remote-Verwaltungssoftware.
Ich weiß nicht, den Namen wieder vergessen.
Citrix. Citrix, genau.
Irgendeine uralte Version davon und dann ist
irgendjemand hingegangen und hat denen ihre Daten verschlüsselt
oder so und hat sie erpresst. Und da ist
glaube ich dann tatsächlich auch jemand bei gestorben oder so.
Das war irgendwie sehr unschön.
Ja.
Das ist dann auch der Teil, den
grenzt man in der Security manchmal ab.
Im Englischen ist es halt...
Ja, das ist im Deutschen, haben wir das sozusagen
nicht getrennt. Ich finde das eigentlich so
ein schönes Beispiel, dass
Konzepte
mit extra Begriffen in anderen
Sprachen einem nochmal einen neuen Blick liefern,
dass Sicherheit im Englischen halt mit
Security und mit Safety übersetzt
werden kann. Und Safety ist halt die
auf Menschenleben und körperliche Unversehrtheit
bezogene Perspektive
von Sicherheit. Und Security ist
halt die Frage, ob das Fahrrad noch da ist.
Aber kannst du das denn in der modernen Gesellschaft
wirklich auseinanderhalten?
Ja, das ist halt sozusagen genau das Thema,
dass man,
damit machen wir jetzt einen schönen nächsten Bogen,
dass Security extrem kontextspezifisch ist.
Sie stellen mir gerade die Gesichtsbemalung vor,
die dazu führt, dass die Kamera den Algorithmus
verändert und ein anderes Gesicht immer in die
Daten erkennen lässt und dann
kann ich mich tarnen mit einer
gewissen Schminke und als jemand anderes ausgeben.
Weil der Algorithmus dadurch
denkt, ich bin jemand anderes, weil ich einen anderen Gesichtshash bekomme
oder so.
Das ist der Fun in dem ganzen Machine Learning Umfeld,
dass du diese Adversarial Models hast,
dass du sozusagen auf der einen Seite
ein Model haben kannst, was Dinge
erkennt und jemand anderes weiß aber, wie er
auf Basis eines Models
Outputs generiert,
die dieses Model dann
wieder aus dem Takt bringen.
Ja, nur für seinen Social Score oder sowas kann man den dann
hochhalten, obwohl man andere Sachen...
Die Ecke von Philipp fand ich
jetzt nochmal wichtig und spannend, dass
halt dieses Thema, ah, hier passiert ja
nichts Schlimmes.
Das Interessante ist eben, durch dieses
Architekturproblem trifft es halt
alle und jeden. Also jedes Stückchen Code, was du
schreibst und mit dem großen Problem
Dual Use, du weißt halt nie,
wofür wird Code halt mal eingesetzt werden.
Den schreibt man jetzt und der ist
da und ganz ehrlich, Leute, die Code
finden, werden ihn benutzen.
Er wird irgendwo benutzt werden
und er wird für Dinge benutzt werden,
die man sich nicht vorgestellt hat.
Wobei ich da auch immer eine Lanze dafür breche,
zu sagen, naja, der, der den Code in den
Context einführt, hat
die Verantwortung sicherzustellen, dass er
da was Sinnvolles tut.
Dann macht er ein
Projekt mit NPM-Paketen.
Genau, aber das ist
deren Verantwortung.
Es ist nicht die Verantwortung von jemandem,
es gibt im Open-Source-Umfeld, kann man ja auch
viel da nochmal drüber reden,
über die Motivation von Leuten, die halt so
Open-Source-Packages maintainen, die dann
ein riesen Schwergewicht kriegen. Ich finde,
die Leute haben keine moralische Verpflichtung
anderen gegenüber, aus ihrem
Freizeitprojekt, wo sie sagen, da steckt einfach nur meine Lust und meine
persönliche Motivation drin, anderen Garantien auszusprechen, dass sie damit
jetzt einen Space Shuttle betreiben können.
Das darf man so nicht umdrehen.
Und nichtsdestotrotz ist es natürlich
ein etwas zusammengeschimmertes
kleines Raumschiff, was immer droht auseinanderzufallen, was auf der einen Seite mit Kohle und auf der anderen
Seite mit einem Handpedal betrieben wird
und kann also genau weiß, wo denn jetzt das nächste
Leck entsteht.
Ja, ich hätte auch große
Bedenken, irgendwie so medizinische,
Software für medizinische Geräte zu schreiben oder
irgendwelche Software, die Flugzeuge steuert oder so,
da hätte ich irgendwie groß, würde ich wahrscheinlich
eher lieber nicht. Wahrscheinlich schon bei
Bank-Transaktionsgeschichten schon Bedenken, aber
Allein das zeichnet
dich aber eigentlich schon aus als jemand, der
qualifiziert sein könnte, das zu tun.
Ich weiß nicht, weil
zu viele Leute
gehen nämlich ohne diese
Vorsicht heran.
Also, man hat mal früher gesagt,
die Deutschen bauen die besten Atomkraftwerke,
weil die so scheiß viel Angst davor haben.
Und halt entsprechend in die
Sicherheit investieren.
Deswegen ist Siemens mit den
Atomkraftwerken so ein Exportschlager.
Andere haben halt weniger Angst
davor und machen dann halt
auch weniger Sicherheit.
Das ist so ein bisschen ein,
wer sich halt auf dem Fahrrad sicher fühlt
und keinen Helm aufsetzt,
und wer sich unsicher fühlt und einen Helm aufsetzt, ist am Ende bei einer echten Kollision feiner raus.
Ja, aber ich meine, das ist einfach so.
Ich glaube, das, was mich da so unsicher fühlen lässt, ist halt einfach, es ist schwer zu hinzu...
Also es ist schwer, überhaupt sicherzustellen, dass da nichts passieren kann.
Es ist einfach, es kann so viel schief gehen.
Es geht auch nicht.
Das ist dann der schöne Übergang zu dem Thema Security als Prozess halt.
Man kann halt immer, ich glaube etwas, was lange in der Informatik gelehrt wurde, ist halt das Problem sozusagen Security als abstrakte mathematische Eigenschaft eines Systems.
Das wird an vielen Stellen auch noch verfolgt und da kommen interessante Sachen raus, gerade wenn wir gucken in Richtung strenger Typsysteme und all so ein Zeug.
also ADA zum Beispiel, dieses ganze Umfeld.
Und da finde ich es auch spannend, dass die tatsächlich dort Engineering haben.
Ich hatte ADA nur mal im Studium und muss sagen,
also es ist halt, was die Garantien angeht, wirklich straff.
Es ist auch ziemlich schnell.
Ich habe aber nie irgendwas Sinnvolles damit programmieren können.
Kannst du vielleicht nochmal ganz kurz erklären, was ADA ist?
ADA ist eine Sprache, die ist extrem formal definiert.
und die wird hauptsächlich im militärischen Bereich eingesetzt, also bei uns an der Uni ist die gelehrt worden und dann gab es halt gerne mal von der Eurocopter und von anderen Leuten Besuche, wo es dann darum ging, irgendwie Steuersysteme für Kampfhufschrauber und so ein Kram zu programmieren.
und die ist halt, die zeichnet sich dadurch aus, dass sie ein sehr umfassendes
Typsystem hat. Das heißt, da wo man in anderen Sprachen halt sagt,
ich hätte hier gern einen Integer, kannst du dem Ding halt sagen,
ja, ich will hier einen Integer haben, der darf aber nur von 7 bis 9, 11,
13 und 12 sein. Und der Compiler
kann dir vorher über alle Operationen deines Programms schon sagen,
ob die Verkettung der Operationen in Summe
noch zu zulässigen Ergebnissen führt.
Oder ob du irgendwo deine
Wertebereiche sprengen würdest.
Und gleichzeitig, und das ist halt wirklich cool,
die können halt Echtzeit
und sie sind auch auf anderen Systemen
sehr, sehr schnell in der Laufzeit nachher.
Und das ist halt, das ist was wert.
Gleichzeitig ist es aber so,
immer wenn es um I.O. geht, nämlich da,
wo halt dieses Thema, da kommen Daten
von draußen rein oder müssen wieder raus,
da gucken sie so ein bisschen in die Luft und sagen,
naja, das macht jemand anders.
Das ist dann halt immer
also da herzugehen und zu sagen,
ihr kennt jetzt hier gerne mal schnell eine
HTTP-Library und ich würde dir
SSL nochmal da drüben, Repository
von GitHub, sowas ist bei aller
halt eher nicht so an der Tagesordnung.
Du brauchst halt auch eine entsprechende
Engineering-Menge und Genauigkeit,
all die Kombinationen, mit denen du
sozusagen konfrontiert wirst, dir so genau
anzugucken, das lohnt sich
halt auch eigentlich nur,
wenn da wirklich Menschenleben dranhängen.
Ja, das, wenn du sagst, es ist okay,
wenn dieses kleine Programm jetzt
zwei Millionen Euro kostet.
Wo jemand anders sagt, komm, da hack ich dir jetzt das Shell-Skript runter
und dann ist es gut.
Und da muss man immer aufpassen,
dass es halt kontextbezogen ist.
Also, die kommen halt aus dieser Ecke von einer
mathematisch perfekten, idealisierten
Variante von so, wir schreiben jetzt
das Programm und das ist dann sicher.
Und wenn du in ausreichend komplexe
Systeme kommst, musst du aber eigentlich
eher einen prozessorientierten Ansatz machen.
Genau, genau, da würde ich
nämlich jetzt auch gerade noch kurz einhaken
und sagen, naja, das Blöde ist, dass
einem halt auch diese Geschichten nicht unbedingt schützen
vor wirklich fatalen
Fehlern, wie zum Beispiel
ich weiß nicht, ob das der Jungfernflug
der von irgendeiner neuen Ariane-Version
war, Ariane 5, äh Ariadne
Ariadne oder Ariane, Ariane glaube ich
5
Ich glaube auch die Steuerungssoftware dafür ist
auch in Ada geschrieben oder so und die ist sogar
bewiesen
dass die tatsächlich das tut, was in der
Spezifikation steht, nur
das Problem ist halt, sie haben irgendwie die falsche Spezifikation
verwendet
das war Wind
die Spezifikation war halt für die alten Motoren
irgendwie und dann hat
irgendwie waren die Sensordaten
für den Computer halt
irgendwie so, nee das kann nicht sein
aber es ist ja bewiesen, das ist
richtig, daher muss ich defekt sein
dann hat sich der erste Steuerungskomputer ausgeschaltet
und dann hat sich der zweite auch noch ausgeschaltet
und dann war halt Schluss
und dann ist die Rakete halt abgestürzt
und ja
Das ist ja auch sowas. Ich meine, klar, man kann halt beweisen manchmal, dass Programme das tun, was sie tun sollen, aber dann muss man ja immer noch sicher sein können, dass die Spezifikation richtig ist. Aber irgendwie, man kommt da in so einen infiniten Regress und selbst das hilft einem nicht.
Das war jetzt ein Fall, wo ein Hardware-Update dazu geführt hat, dass das Ding nicht mehr lief. Also keine Updates fahren, never touch a running system.
machen.
und der Code sieht komisch aus.
Und dann kann ich ja sowohl Tests durchführen
gegen den Source-Code, also dass ich
mir den gesamten Source-Code nehme
und ein automatisiertes Programm drüber laufen lasse,
das mir halt sagt, okay, die Stelle sieht komisch aus.
Hier machst du wahrscheinlich eine SQL-Injection
oder ein C, ein Buffer-Overflow,
das sieht irgendwie gefährlich aus.
Und dann kann ich natürlich auch sogenannte Blackbox-Tests
fahren, wo ich sage, okay, ich starte meine Anwendung
einfach mal und dann nehme ich mal so ein
Hacker-Tool und das probiert einfach mal aus.
Kann ich hier komische Sachen eingeben und
und crashen das Programm oder macht das Programm irgendwas komisches.
Also auch in Python ist das nicht verloren.
Da kann man auch sehr sichere Anwendungen schreiben,
was meistens das gleiche ist wie eine gute Anwendung zu schreiben,
weil die stürzt halt nicht ab und die kann auch mit allen Benutzerangaben umgehen,
noch nicht mal nur von Angreifern, sondern auch von Benutzern.
Also ich hatte das beruflich auch so.
Wir dachten erst, wir hätten einen Angreifer, weil unsere Anwendung abgestürzt ist,
aber hat sich herausgestellt, wir hatten ein ähnliches Problem wie beim Buffer-Overflow.
Wir hatten ein Datenbankfeld mit einer bestimmten Länge
und die Länge war aber in Bytes
und dann kamen halt User an und haben
ihre kleine Tony-Figur
mit ganz viel Smileys genannt
und dann passte das nachher nicht
und
führte zu einem Crash und auch sowas kann man natürlich
auch vorher darauf achten und
entsprechend auch testen,
das ist ja noch ein anderer Bestandteil
eines sicheren Prozesses,
der sagen kann, ich schreibe vorher Tests
und ich überlege mir entweder manuell
oder sogar automatisiert, wie sehen komische
Eingaben aus. Bei Nummern sind das meistens
Null oder sehr kleine
Zahlen oder sehr große Zahlen.
Typischerweise auch
Zahlen, die vielleicht über
die 32 Bytes hinausgehen, was in Python jetzt
nicht so ein Problem ist oder über die 64
Bits hinausgehen.
Also wenn ich da eine sehr
große Zahl, wenn ich 2 hoch 64 plus 1 schreibe,
dann in Python gar kein Problem. Aber
in vielen anderen Programmiersprachen führt das halt
zu einem
Abschluss oder zu komischem Verhalten Und damit kann ich auch in Python glaube ich sehr gut Sicherheit sichern Also du wirst tats in solchen kritischen F wo du dir
ich weiß nicht so genau, was da rauskommt, Assertment-Statements
in den Code schreiben einfach und dann
sagen Asserts should never happen oder sowas.
Und dann fliegt dann...
Genau, vielleicht auch testen.
Also bei dem Beispiel, was ich eben gebracht habe, wo die
zwei Emojis eingeben haben oder andere
komische Unicode-Zeichen, haben wir halt einen Test
gemacht. Und dieser Test, also wir haben
sowohl einen Unit-Test, der also ganz normal in der Anwendung läuft,
wo wir halt mal ausprobieren, was passiert, wenn ich nur Emotions eingebe oder andere komische Strings.
Und wir haben aber auch einen End-to-End-Test, der das gesamte System testet.
Zum Beispiel hatten wir auch mal einen Bug, der durch den Reverse-Proxy vor unserer Anwendung verursacht wurde,
dass der halt Sachen falsch macht.
Und sowas kann man dann halt nicht so richtig testen.
Natürlich könnte man auch in Nginx sagen, ich schreibe eine Art Unit-Test für unsere Nginx-Konfiguration,
zu schreiben,
der halt wirklich eine echte Anfrage
gegen das echte System schickt, oder gegen Prod, also
kann man sogar gegen sein Production-System testen,
aber natürlich testet man das im Normalfall zuerst
gegen Development und sendet
mal komische Anfragen und schaut, okay,
geht das, kommen hier ordentlich Ergebnisse raus
und meldet das
System vielleicht auch hinten drum schon,
dass irgendwas umgefallen ist und
das kann man halt damit schon ganz gut testen.
Ich finde
das halt auch spannend aus der Perspektive von
User lassen sich halt mehr Dinge einfallen, als man selber halt vorher konstruieren kann.
Tests sind an der Stelle immer natürlich auch super, weil man, wenn man im Hinterkopf behält, dass Tests halt eben nicht dafür da sind, Beweise zu ersetzen.
Also ja, sie sind sogar eine Annäherung eines Beweises, aber sie können halt nie alle Fälle abdecken.
Das geht halt schon in dem Moment schief, wenn du halt ein kontinuierliches Wertesystem hast an der Stelle.
und was da halt interessanterweise zum Tragen kommt, aus einer ganz anderen Ecke von Security,
ich weiß gerade nicht mehr, welcher amerikanischen Militär das war,
das kommt so aus dem Counterterrorism-Zeug,
das ist Only Variety Can Match Variety.
Also das Problem von Terrorismus ist halt, dass Terroristen extrem variierte Inputs,
also Angriffe fahren.
Da geht es ja nicht um eine reguläre Kriegsführung nach Genfer Konvention,
sondern die machen Dinge, gerade
weil sie verboten sind und
weil keiner damit rechnet an Stellen, wo keiner damit
rechnet und die Amerikaner
haben halt irgendwann rausgefunden, wir können dem
halt nicht mit herkömmlichen Maßnahmen, indem
wir alle möglichen Fälle durchdeklinieren
entgegentreten, sondern du brauchst
halt kognitive Diversität, um
auf diese absurden Ideen zu kommen
du brauchst tatsächlich Leute, die unterschiedlich
ticken und ganz ehrlich, keiner von uns
wenn ich hier in die Runde
gucke, wir haben halt vier mittelalte weiße Männer
und die
Diversität ist auf der Ebene
halt auch kognitiv dadurch mit dem Bias
belegt. Keiner von uns kommt auf
die Idee in seinen Tests halt
Katzen-Emojis in den Inputs
zu zeigen. Das macht halt von uns keiner.
Und an der Stelle
ist Security als Prozess halt
tatsächlich auch von einer hohen Diversität,
also braucht eine hohe
Diversität, immer mit dem kleinen
Zusatz von kognitiver
Diversität, die aber auch tatsächlich
überlappt mit kultureller und
persönlicher Erfahrung
etc., um halt
das erzeugt zu kriegen, dass man halt
auf genügend Ideen kommt,
die dann mal so eine Baseline herstellt von
okay, das ist jetzt hier nicht mehr scheiße.
Naja, das ist immer,
ich finde das aus einem prozesshaften Ansatz gesehen
und das ist halt das, wo wenn Jochen
der halt sagt, hilf ich, ich will keinen Space-Structure-Code
schreiben, aber Leute, die halt besser
differenzieren können zwischen
ja, wie gut oder schlecht ist es denn,
versus ist es jetzt perfekt sicher oder ist es nicht
und die
und Jochen unterhalten sich über die Programmiersprache Python
Petent und ihr aktualisiert das so, wie es halt nötig ist und jada, jada, jada.
Aber das war dann halt auch plötzlich ein Kampf, wo die da vorstanden und
sagten, fuck, ich muss jetzt hier das Siegel drauf machen, obwohl ich eigentlich
in der Liste geschrieben habe, verstößt gegen unsere Sicherheitspolicy.
Ja, stimmt, das ist ein großes Problem. Das ist auch so ein Problem mit so
Zertifizierungen, die man ja sonst vielleicht macht, wenn man jetzt irgendwie
ein Auto fährt oder keine Ahnung, wo das eigentlich herkommt, Kirmesgeräte hat,
auf denen Leute rumfahren. Dann kommt der TÜV und sagt halt, okay, ist noch nicht
durchgerostet, alles klar, hier das Siegel.
Das geht halt bei Software nicht so gut,
weil die muss man ja ändern und eigentlich braucht man
dann eine neue Zertifizierung.
Ja, genau, das wäre,
könnte man jetzt denken, dass das die Lösung wäre.
Ich habe das schon gemacht.
Ja, ich habe
2003 oder 2004
haben wir damals mit
Soap eine Common Criteria Zertifizierung
gemacht und das war
so ein Challenge, da gab es einen Sponsor,
der uns das bezahlt hat und
parallel dazu hatte damals
Red Hat den
J-Boss, glaube ich, durch eine
Common Criteria gejagt und
wir hatten im Prinzip das gleiche Schutzniveau
anzubieten.
Eine ERP 3 Plus oder ERP 4 oder so ein
Kram.
Ich kann
auch nur die humoristische
Variante irgendwie so, die unterste ist
irgendwie das Programm existiert,
die nächste ist dann irgendwie ja, das Programm existiert
und es gibt Dokumentation dazu,
dann die nächste ist irgendwie, jemand hat mal
geguckt, ob die Dokumentation zum Programm passt und dann
und es existiert
ein formaler Beweis, dass das Programm korrekt ist.
Wo dann irgendwie so ein Zwischenschritt fehlt,
das ist, glaube ich, Stufe 6
oder weiß ich nicht genau.
Ja, ERP 6 ist die formale Verifikation, genau.
Und, nee, nee,
wir hatten da schon ein relativ hohes Schutzniveau
und die Common Criteria als
Framework, um über Security nachzudenken,
inhaltlich, ist toll.
Weil du kriegst halt einen Katalog
von, also du hast zum einen einen Prozess,
der dir sagt, okay, mach dir mal Gedanken
über, wer sind denn deine Assets?
Wer sind deine Angreifer?
Was haben die für Motivationen?
Was haben die für Ressourcen?
Und jetzt gucken wir mal, wie mappen wir das
alles aufeinander von
wie sind deine Assets
mit was geschützt gegenüber welchen
Angriffsszenarien?
Und die haben auch noch einen tollen
Implementationskatalog, wo sie sagen, okay, also
wenn du folgendes countern möchtest, könnte man zum Beispiel
Logging machen. Wenn du Logging machst, dann musst
du dir über die Integrität vom Log Gedanken
machen, da musst du dir über Zeitstempel-Gedanken
machen, da musst du, das ist sozusagen, das ist so ein bisschen,
da kannst du wie bei so einem Spinnennetz irgendwie
reingreifen, erstmal, was interessiert mich,
und dann kommen alle Sachen hinterher, von die du noch berücksichtigen
musst. Das ist viel, aber es ist
eigentlich erstmal auf der Ebene
fachlich gar nicht schlecht gewesen.
Das große Problem ist, die Common Criteria
kommt aus der Produktsicherheit.
Und die
gehen halt davon aus, dass ein Produkt eben
siehe, ein Karussell auf dem Jahrmarkt,
das Ding wird einmal gebaut und existiert jetzt,
und jetzt ist das ab und jetzt läuft das 30 Jahre.
Wenn du aber sowas wie einen Open Source
Application Server hast,
wo du exakt ein Release
einmal
verifizieren darfst
und dann kommt
aber in 23 Stunden das nächste raus
und du fängst
die ganze Zertifizierung wieder von vorne an,
das geht dann halt schief.
Ja, außer man muss ja die Zertifizierung
erstmal, also es kann manchmal
sehr gut sein, dass man sich über alle Sachen
Gedanken macht, aber man kann ja auch ganz viele Sachen
vermissen. Also ich glaube, der
viel besser, oder also
für viele Anwendungen besser ist es,
wenn man sagt, ich mache einen Pentest, also ich
einen Auftrag geben. Bei einem Pentest
geht halt jemand anders hin und sagt, ich
checke deine Software. Also entweder
checke ich die von außen oder ich schaue mir
den Source-Good an, ich schaue mir das mal an,
was du so in Python oder auch in anderen
Programmiersprachen alles programmiert hast.
Und das sind dann halt erfahrene Entwickler
in der genau der Programmiersprache
und die können halt schon, vielleicht auch mit automatischen
Tools, sehr schnell kritische Stellen
finden. Also damit habe ich auch
gute Erfahrungen gemacht.
Das ist natürlich eine ganz andere Herangehensweise, dass man sagt, okay,
ich versuche nicht alles irgendwie, den ganzen
Prozess, ich schreibe kein Papier,
sondern ich lasse den wesentlichen Leuten anfangen, uns zu coden.
Und das muss man natürlich auch
regelmäßig wiederholen. Das bringt natürlich nichts, wenn man vor 10 Jahren
das mal gemacht hat. Aber das ist auch
sicherlich eine Methode, mit der man
seine Anwendung gut absichern kann.
Du musst also den Angreiferhut aufsetzen und da draufhauen,
solange bis auseinander fällt. Da brauchen wir halt gute Angreifer
auch, die so ein bisschen ein paar Tricks kennen.
Ich glaube, wenn man jetzt nur so Tools drauf loslässt, dann weiß ich nicht.
Genau, also wenn man nur
ein Tool selber drauf loslässt, hilft es wahrscheinlich nicht.
Aber wenn man halt jemanden beauftragt, der
da wirklich Experte ist,
ich glaube, das ist eine ganz
gute Möglichkeit, um so einen Blick
zu bekommen, wie schlimm ist denn mit unserer Anwendung?
Haben wir nur eine ganz kleine Schwachstelle?
Oder ist unsere Admin-Oberfläche
ohne Benutzernamen
und Passwort irgendwie verfügbar und man kann beliebig
einen Code hochladen? Und ich glaube,
Das ist noch ein bisschen eine andere Herangehensweise, aber ich glaube, das ist oftmals effektiver, vor allem für so kleinere Projekte.
Wenn man natürlich eine Zertifizierung braucht, dann braucht man sie, aber ich weiß nicht, ob das immer auch wirklich zu Sicherheit führt, wenn ich nur ganz viel Papier schreibe.
Also ich würde an der Stelle halt eine Lanze brechen für das, was wir jetzt zu Corona-Zeiten kennengelernt haben als irgendwie Schweizer Käse-Modell.
Du kannst halt, also für alle, die das noch nicht gehört hatten, ist sozusagen die ganzen Maßnahmen, alle Anti-Corona-Maßnahmen sind für sich genommen natürlich durchlöchert.
wie so ein Schweizer Käse, aber wenn ich halt fünf Scheiben Schweizer Käse hintereinander lege,
ist die Filtrationsrate dann doch relativ gut.
Dass also wirklich über fünf Schichten an der gleichen Stelle überall die Löcher sind,
das passiert halt normalerweise nicht.
Und deswegen würde ich halt es immer, also aus meiner dann längerfristigen Erfahrung,
würde ich halt sagen, es kommt immer auf den Kontext drauf an.
Man muss immer erstmal gucken, was sind hier eigentlich die Assets gerade.
Und wenn ich gerade hier in meinem Heimkeller irgendwie die Temperaturdaten von meinem Haus aufschreibe,
und Jochen unterhalten sich über die Programmiersprache Python
wo ich dann weiß, jetzt habe ich wenigstens nichts
unnütz vergessen
während dann halt das Thema ist
halt auch jemand zum Beispiel vom Pentest
da würde ich auch sagen, einige Leute mit denen
ich mich dann austausche, sagen, ne dann
machst du halt lieber auch noch gleichzeitig sozusagen
eine externe Code Review
die sozusagen über das was du brauchst halt dann nochmal
im Whitebox drüber guckst und dann kannst du nochmal von draußen
draufhauen und diese ganzen
Schichten ergeben dann halt und gleichzeitig
kannst du dann an vielen Stellen ja auch wenn man
standardisierte Protokolle
wie halt HTTP immer so dazwischen hat.
Dann gibt es da ja auch noch die Möglichkeit,
immer nochmal so Schichten einzuziehen wie eine Web-Application-Firewall,
die einem so bestimmte
Sachen schon mal
wegfängt. Also ich habe zum Beispiel ein paar Kunden,
denen gucke ich über die Schulter
und da weiß ich dann so, okay, bei dir
knall ich da jetzt eine Waffe davor,
weil ansonsten traue ich mich nicht,
das ins Netz rauszulassen. Du sagst mir, es muss raus
ins Netz.
Das ist das gleiche Prinzip wie ein Virenscanner.
Da habe ich irgendwie
ein Muster, das ich suche.
bei einer Bar und sagt, okay, wenn ich das Muster
finde, dann mache ich irgendwas, dann
unterbinde ich die Anfrage oder schmeiße das
Muster raus und mache irgendwas.
Das ist
schon ein bisschen gefährlich, weil
eine Möglichkeit ist halt schon, wie bei einem Visenscanner,
dass der,
also die Wald- und Wiesenattacken
findet der sicherlich. So was im Internet das Grundrauschen
ist, das findest du auf jeden Fall. Aber wenn dann
wirklich jemand deine Firma angreifen will, dann
merkst du dich da vielleicht auch in falscher Sicherheit,
weil man halt dann doch immer...
Also du hast recht mit dem Schweißer Gessel,
Modell, das macht es vielleicht ein bisschen besser, aber gleichzeitig kann ja so ein Waf auch wieder
ein anderes Modell sein, weil der muss ja auch wieder alles interpretieren und ein Problem kann halt sein, dass
mein Server davor und mein Server danach sowieso schon unterschiedliche Details
anders interpretieren, also bei HTTP zum Beispiel Junk Encoding oder irgendwelche
komischen HTTPS-Optionen anders interpretieren und dass dann die Waf sogar
noch ein neues Problem aufmacht, dass sie plötzlich Sachen anders interpretiert und
dann vielleicht sogar eine Schwachstelle an sich hat, also auch die Waf ist ja nur Code.
Ne genau, deswegen ist das auch für uns zum Beispiel
keine Maßnahme, die wir halt so Blanko überall drüber
gießen, sondern das ist halt, wir haben halt
dann Kunden, wo feststellen, also
die Waffe ist für uns mehr oder weniger dann
der erste Move, also manchmal
wie du sagst, will irgendwer einfach in seiner
Ausschreibung sehen, da muss eine Waffe davor
dann packe ich da eine Waffe davor
und wenn, das
muss er ja anbieten können erstmal in dem Moment, wenn er
das fragt und wenn der dann irgendwie nach zwei Monaten
fragt mit, warum ist das hier alles so doof, dann sage ich
du wolltest eine Waffe haben, dann sagt er mir, jetzt machst du wieder aus
dann mache ich es halt wieder aus
und wo wir es häufiger als Werkzeug tatsächlich sehen ist, dass tatsächlich diese Wald- und Wiesenscans und Angriffe gerne mal massiv für Last sorgen.
Und das ist halt, wir sehen immer wieder Anwendungen, wo Leute mit SQL-Injection versuchen, quer über so eine Anwendung drüber gießen
und die Anwendung dadurch in Performance-Probleme gerät.
Und das ist halt tatsächlich was, das filtern wir dann damit zum Beispiel vorne weg.
Also jetzt hier haben wir den natürlichen SQL-Kram, das hat da nichts zu suchen, zack, weg, raus.
Ah, okay.
Ja, aber ich habe auch schon mal von jemandem gehört, der so Pentests macht,
dass er meinte, da war eine Bank, die hatte irgendwie ein System vor den Datenbanken
und das sollte eigentlich aus dem SQL irgendwie alles rausfiltern,
und das hat dazu geführt, dass SQL-Injection wieder möglich wurde,
weil es halt Dinge zu viel rausgenommen hat.
Du hast ja
aus Komplexitätsperspektive
hast du immer das Problem der Kombinatorik
das heißt, wenn du
n Dinge hast, die miteinander reden
dann hast du halt n Quadrat Verbindungen
mindestens und
wenn du jetzt sagst, okay, das ist mir zu unsicher
ich packe noch eins davor
dann hast du noch mehr
n plus 1 Quadrat
Das Problem ist glaube ich an der Stelle auch
wer halt irgendwie diese Architektur
entscheidet und so und wem man da vertrauen kann.
Gerade wenn Leute jetzt keine Ahnung haben von
Sicherheit oder von Computern allgemein,
aber irgendwie Software als Manager irgendwie bestellen
wollen. Die haben ja eine unheimliche
Asymmetrie gegenüber den auch
Entwicklern und so und die müssen halt vertrauen
auf das, was denen da erzählt wird
und die stellen sich dann meistens so ein Sammelsurium
an Angebot und Nachfrage
oder Best Practice oder irgendwas,
was die halt in Informationen saugen können zusammen
und das ist ja auch schon so eine Art
Baukasten und das ist ja nie ganzheitlich
irgendwie gedacht, was wird ja auch immer dann teuer und so,
muss dann auch wieder sparen und
wenn man das dann rauslässt, dann ist ja klar,
Fehler sind ja völlig vorprogrammiert
und sich da richtig vor zu schützen
ist fast eine unmögliche Aufgabe
und die Frage wäre vielleicht, wie man solchen
Menschen auch eine Möglichkeit geben kann,
Systeme in sicherer zu denken,
also ihr habt jetzt gesagt, so Prozesse von Anfang an
so ein bisschen, das würde ja wirklich bedeuten,
dass man sich, bevor man damit anfängt,
mit einem Systemarchitekten oder sowas
intensiv auseinandersetzen muss,
und Jochen unterhalten sich über die Programmiersprache Python
eigentlichen Zertifizierung oder die Prozesse, sondern vielleicht mehr, wie lasse ich die entwickeln?
Wie sorge ich dafür, dass, wie ich eben erwähnt hatte, Code Review, also wie sorge ich dafür,
dass das halt schon bei der Entwicklung direkt die Software sicher ist?
Weil nachher das draufzubauen ist immer schwieriger.
Also nachher mit dem Scanner zu suchen ist, glaube ich, schwieriger als zu sagen, okay,
ich habe Entwickler, die sich direkt darüber Gedanken machen.
Das ist ja zum Beispiel total kaputt.
Also ich hatte jetzt irgendwie mal so die Situation, dass so ein Konzern da war.
und die wollten dann Software bereitstellen
und dann haben sie gesagt, nee, aber neue Software
ist irgendwie komisch, wir wollen die alle auditieren vorher
so persönlich, also als Security-Team
und haben dann so ein Service dann rausgebracht
dann jetzt im November und da war
dann Django 1.10.4, weil das dann die
sichere Version war. Also LTS war 1.11
für alle, die es noch wissen. Das ist halt schon ein altes
System und da gibt es halt dann irgendwie schon jede Menge
Exploits, wenn man irgendwie genug nach sucht,
die irgendwo drinstehen und das wird dann
von den Leuten irgendwie geaudited und man fragt sich halt
okay, was machen die denn da eigentlich?
Warum tun die das?
Das ist halt wieder der Griff in Richtung
Product Security statt Process Security
Also ein prozesshafter
Ansatz und wir haben jetzt ja auch seit
einhalb Jahren, doch seit
ein bisschen mehr als eineinhalb Jahren machen wir bei uns ISO 27000
und
der Trick ist halt bei
vielen, die prozesshaften
Security Sachen werden häufig missverstanden
weil die Standards, die es dazu
gibt, wie eine Keule aussehen
obwohl sie eigentlich gar nicht so schlimm sind
man muss da bloß, wenn man die Standards interpretiert
immer unterscheiden zwischen
was fordert der Standard formal
und was ist im nächsten Satz schon nur noch die
Implementationsguideline
wo man dann eigentlich
selber Hoheit hat, also ich habe halt auch jemanden
der meinte
der ISO 27000, seitdem müssen
wir sämtliche Stromkabel
einmal im Jahr
irgendwie auf die Erdung prüfen
also, ne, muss man nicht
ich habe auch eine 27, aber dann müsste man das doch auch mal so
nehmen müssen wir nicht.
Ja, aber, aber, ja, nehmen müssen wir nicht.
Dann dreht man so eine Schleife mit,
naja, die ISO sagt, du musst dich halt
um die für dich relevanten Normen und
Vorschriften kümmern, das sagt die
ISO 27000, also macht man
das, und die sagt aber auch,
du musst sie bewerten
und musst dann Schlussfolgerungen für dich
daraus ziehen.
Und es ist völlig legitim im Rahmen der ISO
zu sagen, ja, wir haben zur Kenntnis
genommen, dass ortsveränderliche
elektrische Verbraucher irgendwie alle zwei Jahre auf
X geprüft werden müssen.
Machen wir nicht.
Ihr könnt doch mal erklären, was für eine Lücke
das offen lassen könnte, warum
man das testen wollen möchte.
So, naja, ISO als
Prozess, die ISO als
Informationssicherheitsprozess ist extrem umfassend
und zwingt dich dazu,
den kompletten Wertschöpfungsprozess
von einem IT-System
zu betrachten. Da gehört halt dann unter anderem
auch dazu, dass
du eben rechtliche
Rahmenbedingungen bewertest,
etc., weil du musst am Ende
immer für alle deine Assets
und für den hat das halt schon die vier
Grundsicherheitsaspekte, also
bei uns sind sie aufgeschlüsselt, manchmal wären es drei,
manchmal wären es vier, halt nach
Vertraulichkeit, Confidentiality,
nach Integrität,
Integrity, nach Authentizität
und nach Availability
zu schütten. Und was hat das jetzt damit zu tun,
dass da so ein Stromkabel ist,
in das sich... Ja, Strom ist zum Beispiel für die Availability
relativ wichtig. Okay, also
Availability, okay. Und du misst halt dann da quasi nur die Stromleitung, um zu testen, ob das Ding irgendwann mal ausfällt.
Es ist halt eine deutsche Norm, die kommt aus dem
ich weiß nicht welches ist, die schreibt halt vor, dass halt alle
ortsveränderlichen Verbraucher auf
sind alle zwei Jahre halt so. Und wenn die ISO halt sagt, du musst halt
alle für dich gültigen Rechtsnormen berücksichtigen und
überwachen etc., dann schlägt sowas halt auch zu. Was die Leute aber eben häufig missverstehen
ist, dass in der ISO drinsteht, du sollst es bewerten.
Und du sollst für dich
daraus ableiten, ob das jetzt
was Relevantes ist oder nicht. Du kannst als
Geschäftsführer oder als CISO an der Stelle immer
sagen, okay, ich habe da fünf Risiken
gesehen, ich akzeptiere die.
Jetzt hast du aber meine Story
kaputt gemacht. Ich wollte eigentlich die
Story hören, wie man durch das Stromkabel
in den Rechner des NUS einbringt.
Stromkabel,
das kann zum Beispiel passieren,
wenn du deinen Prozess so aufschätzt und sagst,
und Jochen unterhalten sich über die Programmiersprache Python
und
sehr, sehr lange, teilweise 10, 15 Jahre und länger.
Das heißt, wenn ich, und auch teilweise mit politischem Impact,
also wir haben ein paar Systeme, die sind unter anderem zu uns gewandert,
extra aus Amerika raus, von Non-Profits, die unter anderem im Nahen Osten halt aktiv sind.
Und die haben ein massives Sicherheitsbedürfnis um das Leben derer,
deren Daten in dem Ding drin stehen, weil da halt Decknamen und so ein Zeug auftauchen.
und die,
wenn du dann halt sagst, naja,
wenn da jemand ein richtiges Longgame spielt
und sagt, ich hab hier drei Jahre Zeit,
das ist nicht das Problem.
Ich will aber, dass diese NGO mal so richtig gegen die Wand
fährt, dann fahre ich jetzt die Lücke
und sage, aha, ich hab rausgefunden, der ein Hoster
kauft immer irgendwie beim,
aus der Grabbelkiste die Stromkabel,
das dauert jetzt, naja, der tauscht nur so und so oft
die Stromkabel aus, aber wenn ich
es schaffe, irgendwie ein Drittel
seiner Stromkabel durch meine mit dieser Schmelzsicherung
zu ersetzen, dann bin ich in drei Jahren
soweit, dass dann irgendwie bei dem das RZ
implodiert.
Das ist sozusagen
die... Und da muss man immer
aufpassen.
Da kommt dieser, welcher XKCD ist
das mit der hohen Verschlüsselung und
der 5-Dollar-Entschlüsselungsmaschine?
XKCD, bitte
nochmal einmal.
XKCD, Comic.
Da gibt es
eine schöne...
Wo die Idee ist, dass du
eine ganz, ganz teure Verschlüsselung kaufen kannst
mit super zertifiziert
und dann kommt aber jemand zu deinem
Admin mit einem
5 Dollar Baseballschläger und
bedroht ihn dann und sagt, okay, gib mir das Passwort
und wenn das für mich gibt, dann hau ich
dich mit dem Schläger und dann bringt dir die
beste Zertifizierung und die beste Sicherheit nichts.
Ja, tatsächlich, ja.
Und man sagt halt auch an der Stelle, weil häufig, also
wenn jetzt halt gerade dieses Thema
Advanced Persistent Threat, also
die typischerweise staatlich
finanzierte Organisationen
oder Teams, die irgendwo reingehen sollen,
man sagt halt auch so schön
gegen den Mossad
schützt du dich nicht
weil den Mossad
interessiert nicht
was du für Security irgendwo in deinem RZ hast
der kommt zu dir nach Hause und nimmt dich mit
und dann reden wir nochmal
so deswegen
ist eben
wenn man das mal schluckt und sagt
ich bin hier nicht der der sich gegen den Mossad schützen muss
weil ich habe eh keine Chance
dann brauche ich aber auch nicht so tun
als wenn ich sozusagen alles auf dem Niveau
machen müsste. Oder du brauchst einen eigenen Geheimdienst.
Bitte?
Oder du brauchst einen eigenen Geheimdienst. Ja, genau.
Das Fiese am Internet ist ja, dass
du immer mit den besten Angreifern
kommunizierst. Das heißt,
vielleicht nicht mit dem Mossad, aber vielleicht hast du
irgendwelche russische Hacker, die durchaus was drauf haben
und die installieren dann halt wie
hier in der Uniklinik Düsseldorf
deine Ransomware und die wollen halt,
die sind auch fast auf dem Level
von so einem Advanced Persistent Threat.
und die haben vielleicht jetzt nicht so, also die machen schon ein bisschen Streufeuer, aber die haben durchaus das technische Know-how und auch die Zeit und die machen sich auch die Mühe, das an deine Architektur anzupassen.
Also vielleicht nochmal kurz, und nicht in Düsseldorf, da gab es einen Vorfall, da ist die Server rausgefallen und da das Netzwerk intern nicht geordnet war, konnte man durch den einen befallenen Rechner irgendwie mehrere OP-Säle ausknipsen, wenn ich das richtig verstanden habe.
Ja, ich weiß nicht genau, was da passiert ist, aber war
Hab ich nicht verfolgt, muss ich zugeben
War aber auch, glaube ich, nicht der erste Fall in Deutschland
und ich glaube, Python hat es auch ein paar Mal so richtig erwischt
Die, ne, natürlich, also das ist halt ja
jetzt erstmal, die Mossad-Beispiele
kommen immer zu dem Thema, wenn man anfängt, die
Physical Security halt extrem stark
zu übertreiben und das ist aber dummerweise
auch das, wo Leute gerne übertreiben, weil das können
sie sich bildlich vorstellen
Dann kommt halt immer noch ein, ja, warum ist hier vor dem RZ keine
und Jochen unterhalten sich über die Programmiersprache Python
abzugrenzen von, wenn du
das Niveau hast, musst du dir nochmal um ganz andere
Sachen Gedanken machen und wenn man das aber mal
so übertrieben hat, dann wird den Leuten schnell klar, dass
Security halt eine Abwägung ist und eine
kontextspezifische Abwägung und immer nur auf 100%
zu schalten, geht halt nicht.
Und damit macht man auch mehr kaputt.
Ich würde halt nochmal anknüpfen an den Punkt von
dieser Prozessempfehlung, ich würde
halt immer versuchen, an allen Enden
weniger ist mehr zu machen.
Weniger Code, den du schreibst,
ist typischerweise weniger Architektur,
über die du nachdenken musst, ist weniger
und damit auch ein Team, was gerade erst anfängt, würde ich eben nicht sagen, ihr fangt jetzt mal an, euch über Security-Gedanken zu machen.
Auch bei uns in der ISO ist es halt, in unserer Umsetzung der ISO 27000 ist es halt auch so, dass wir sagen,
du willst irgendwie ein neues Feature für die Plattform etc. entwickeln? Ja, mach halt.
Ja, mach halt.
Ja, und du kannst gern auch irgendwie deine drei, vier Testmaschinen auf der Plattform halt schon mal auf diese Branch umstellen.
Habe ich kein Problem mit.
Aber bevor das dann halt in großen Einsatz kommt, muss das halt mal durch eine Vier-Augen-Review durch.
und dann musst du mal irgendjemand anders erklärt haben, was du dir gedacht hast.
Und dann gibt es dort eine Checkliste und die fragt, jetzt erklär mir mal, was du dir zu Security für Gedanken gemacht hast.
Und das ist im Prinzip, das ist bei uns der komplette formale Prozess für die Entwicklungssicherheit.
Also übertrieben jetzt ein bisschen, aber im Prinzip ist sozusagen bei uns nur ein, ja komm, entwickle halt.
Da drüben sind die zehn Guidelines, was man in welchen Situationen so alles mal berücksichtigen könnte.
und aber das Einzige, wozu wir dich zwingen, ist, du musst in den Pull-Request,
wo dein Feature in die General Availability geht,
musst du mir oder deinem PR-Reviewer glaubhaft vermitteln,
dass du dir jetzt wirklich adäquat zu dem Ding Gedanken gemacht hast.
Schreibt man das dann als Text in den Pull-Request?
Als Text in den Pull-Request rein.
Da gibt es zwei Fragen. Das eine ist, was sind hier die Sicherheitsanforderungen
und B, wie habt ihr die erfüllt?
Wo ist hier der Nachweis, dass die erfüllt wurden?
Wie seid ihr zu der Frage gekommen von was sind hier die relevanten Sicherheitsanforderungen
und wie weist ihr nach, dass ihr das jetzt halt ordentlich umgesetzt habt?
Das hört sich so ein bisschen an, als sollte man die Angst weglassen
und tatsächlich nur die Worst-Case-Szenarien, also was ist das Schlimmste, was passieren kann
also bei dir wären zum Beispiel jetzt Daten weg gewesen, das wäre nicht so gut gewesen
weil die so sehr privat sein müssen
und an anderer Stelle ist es vielleicht so, ja okay, wenn man die Backups noch hat, dann ist es halt nicht so schlimm
und das ist halt dann vielleicht der Worst-Case und da muss man sich halt Gedanken darüber machen, dass der nicht eintreten kann
und der Rest ist dann egal
Ja.
der Review-Prozess aber zum Beispiel auch umgedreht.
Der Review-Prozess
in dem PR bei uns ist halt
immer nur ein, ja,
man darf nicht alleine Zeug nach draußen
prügeln. Sternchen-Fußnote.
Doch, es gibt Situationen, in denen man das darf,
aber dann muss man noch mehr Dinge beachten.
Weil es gibt halt bei uns auch so
Gefahr und Verzugssituationen dann muss ich handlungsf sein Aber der Pull ist halt wenn er gemerged wird ist das halt nicht die Aussage von dem Reviewer dass er seinen Erstgeborenen irgendwie mit Blut unterschrieben dem Teufel dass er sagt hier ist alles sicher
sondern der Vier-Augen-Prozess ist dafür da, dass ein zweiter Mensch dem ersten nochmal in die Augen guckt und sagt, also wenn du jetzt nicht noch sagst, ich soll nach irgendwas schauen, dann merge ich den Kram jetzt.
Das ist aber dein Code, den ich jetzt gleich merge. Und das ist ganz spannend, weil das ist ein kognitiver Prozess, der halt einer Person, einem anderen Menschen, und da gehört Empathie eben mit dazu, gegenüberstellt und sagt, ich lasse das hier raus.
und Jochen unterhalten sich über die Programmiersprache Python
so aufwendig, dann muss er sich aber auch lohnen,
sondern wir drehen es halt um und
sagen, nee, der Review-Prozess ist erstmal freundlich
und der Default ist, wir gucken
da zusammen drüber und alle machen ihre Arbeit
und reden drüber und klären das
und dann lassen wir es auch raus und dann ist der in 5 Minuten
erledigt. Also wenn ich halt
zum Beispiel nur, weiß ich, ein Pull-Request
bei uns kann sein, Paket-Update vom
Nginx, weil war ein CVE drin,
kommt die nächste meiner Version.
Ein CVE ist ein Vulnerable, ne?
Ja genau, also war eine Vulnerability,
und die
Anforderungen, Anforderungen war, wir müssen Updates machen, weil wir die Sicherheit aufrechterhalten sollen. Nachweis, naja, das ist jetzt die alte Version war die, die neue ist die, zack, fertig, raus damit, Ende. That's it. Das ist halt den Leuten in den Prozessen das so an die Hand zu geben, dass sie nicht jedes Mal vor so einer Checkliste stehen von, du musst jetzt aber umhalten, damit dir nachher keiner den Kopf abbeißt, weil das ist ja alles immer nur noch Asscovering, dass niemandem die Schuld zugeschoben werden kann.
und das ist ja nicht der Prozess, um den es geht, sondern der Prozess ist, dass Leute produktiv arbeiten können
und während dieser Arbeit der Vektor der Änderung immer heißt,
mit jeder Änderung machen wir es erstmal potenziell sicherer und nicht unsicherer.
Und wenn man dann sagt, okay, wenn ich das für alle Änderungen sicherstellen kann,
dass alle Änderungen die richtigen Vektor haben,
ja, dann mache ich doch einfach mehr Änderungen und werde halt immer sicherer.
Ja, das ist interessant, was mir da gerade noch als Idee kommt.
Es gibt da ein Problem bei dieser Sache mit den quasi Pull-Requests.
wenn das jetzt nicht in so einer Firma ist, wo alle Leute da Ahnung haben
von dem, was sie tun, sondern wieder
den nicht ganz optimalen Fall angenommen,
dann kann sich jemand hinstellen,
kann sagen, er ist jetzt hier der Türsteher und der guckt sich das
alles an.
Und dann
hat er eine Existenzberechtigung, obwohl er eigentlich sonst gar nichts
tun muss und das kann dann
sehr, ja, so ein bisschen
diese Informationsasymmetrie dann ausnutzen.
Für mich
regelt das der Wettbewerb. Eine Firma, die so drauf ist,
wird halt Schwierigkeiten haben,
wirklich immer weiter nach vorne zu laufen.
Was ich halt noch spannend finde ist, dass Python natürlich
um mal die Schleife jetzt noch zu ziehen
auch als Sprache
natürlich ein gutes Standing hat
Ich hatte vorhin nochmal irgendwie durchgeguckt
und wenn man halt guckt
wenn ich
wir könnten jetzt sozusagen, also der völlige
Tiefschlag ist natürlich, wenn ich es gegen PHP vergleiche
da habe ich halt
das Problem, dass allein die Laufzeitumgebung
von PHP und die Sprache selber
ich hatte vorhin geguckt
über die letzten 20 Jahre
über 600 CVEs eingesammelt haben.
Und die machen im Prinzip in einigen Jahren das Fünffache von dem,
was Python über die letzten 20 Jahre insgesamt hat.
Also bei Python kamen irgendwie 20 CVEs oder sowas raus über die letzten 20 Jahre.
Viel mehr kommt da einfach nicht.
Und das ist halt auch schon mal was, wo man sagen kann,
okay, das ist was.
Auf der einen Seite die Sprache selber hat viele Probleme nicht,
so was wie ein Buffer-Overflow zum Beispiel, kannst du mit Python erstmal so nicht erzeugen
und es ist auch in der Community ja so verankert, dass extrem viele Bibliotheken,
viele Frameworks das ja auch als Thema für sich erklärt haben und eben sagen,
wir basteln nicht nur um Security-Probleme rum, sondern versuchen sie dann ordentlich zu fixen
und es gab auch in Python selber, also die Sachen, die es gab, wenn ich halt schaue,
das war mal irgendwann ein LibXML-Thema,
weil du halt zum Beispiel LibXML über das externes Auflösen
von Entities dann irgendwie Code ausführen
konntest und so ein Kram.
Aber die wurden halt in der
Community immer sehr
differenziert und schnell
diskutiert und auch adäquat behoben.
Da habe ich einfach eine völlig
andere Basis, von der ich ausgehe,
als wenn ich praktisch bei jeder Codezeile,
die ich schreibe, da denke ich dann eher so an C,
tatsächlich meinen Doktorkittel angezogen
haben muss, um ja nicht daneben
zu tappen.
Ja, dann hat das glaube ich sowas wie Rust
auch deswegen gekommen, oder? Weil das genau das dann
wieder anders macht und
den Griff kriegt, ja.
Ja, ja, also Rust ist
auf jeden Fall, also ich meine, es kommt halt
immer darauf an, was man jetzt,
ich glaube eben vor Buffer-Overflows
muss man gar nicht so viel Angst haben, aber
wenn man jetzt Server betreibt,
die halt super viele Requests bearbeiten
oder so,
was hat letztens
in einem Podcast irgendwie der
Entwickler von Flastia,
Armin Ronacher, gesagt, er meinte so,
Rust ist halt für ihn schon allein deswegen so viel netter, weil Python hätte er ja auch irgendwie sehr gerne gemacht, aber das liegt halt wie Sau. Das ist halt, da kann man, man kann nicht viel dran machen und das ist natürlich schon irgendwie, irgendwie so, ja, das ist, ja.
Das würde ich gerne verstehen, weil da geht mir, Philipp dreht den Kopf und ich habe auch so ein kleines Messer, was mir in der Tasche aufgeht.
Ja, ja, klar.
Aber ich kann
schon in gewisser Weise verstehen, was er
meint. Also ich meine, bei Rust kannst du dir halt
sicher sein, dass da nichts liegt,
wenn du es halt richtig machst.
Was meinst du denn damit da liegt was rum?
Naja, zum Beispiel,
dass halt
der Hauptspeicher immer weiter anwächst, ohne
dass du das eigentlich wolltest,
sozusagen, ohne dass du wirklich den Hauptspeicher brauchst,
sondern dass halt Sachen nicht wieder weggeräumt
werden, die halt irgendwann mal angefallen sind.
Klar, also Python
nimmt dir das Memory Management halt komplett weg
und das
ist tatsächlich Fluch und
Segen zugleich, logischerweise.
Also jede technische Entscheidung, die er hinsicht hat,
immer Trade-Offs und ein Aspekt bei Python
ist nun mal, dass Python
Speicher, den es mal gebraucht hat,
auch wenn es den Akut gerade nicht braucht,
nicht einfach mal so wieder hergibt.
Also wenn dein Prozess mal
irgendwie, keine Ahnung, ein Gig oder zwei Gig groß ist,
dann kann es
gut sein, dass der das jetzt für die nächste Zeit
mal behält, auch wenn du alle Objekte gelöscht hast
und wenn die Garbage Collection durch war,
weil es ist halt auch ein Trade-Off
zu sagen, naja, ständig
Mellox groß und klein und
groß und klein zu machen, hat auch
Nachteile. Es hat Nachteile in der Hauptspeicherfragmentierung,
das ist an sich ein Performance-Thema,
jada, jada, jada, jada
und Python als Universalsprache
in der Hinsicht, wo eben Memory Management als
ich kümmere mich drum drauf steht,
verstehe ich, dass es in diese
Richtung neigt, eben eher
diesen universalen Ansatz zu verfolgen und Rust tritt nun mal an mit, du hast deinen Speicher im Griff, dann müssen sie das auch abliefern.
Das ist klar.
Also nochmal ganz kurz, was ein Melloc ist, also du alloziierst irgendeinen Speicher?
Genau, also wenn du vom Betriebssystem halt Speicher haben möchtest, dann ist es heutzutage eh schon nur noch virtueller Speicher.
und die Programmiersprache Python
und dann teilt er ihnen tatsächlich irgendwie diese Sachen zu.
Und deswegen gibt es einige Programme, MongoDB ist halt auch so ein Ding,
die alloziieren zum Beispiel immer bloß in Vielfachen von 2 oder in 2er Potenzen oder so ein Kram.
Also wenn der halt hergeht und sagt, ich brauche hier mal RAM,
dann sagt er als erstes, ich brauche 64 MB,
und dann irgendwie, ja jetzt hätte ich aber lieber 118 MB,
okay, also jetzt hätte ich gerne 1 GB.
Und das kann manchmal schon so ein bisschen unangenehm sein,
aber
der Vorteil ist halt
wenn der Speicher dann auch am Stück
ausgeliefert wird, dann hat das bestimmte
andere charmante Aspekte
weil dann bestimmte Overhead-Strukturen im Kernel
dann halt reduziert werden können, der kann sogenannte
Huge-Pages machen, das heißt
du musst dann halt nicht, wenn du einen Gigabyte
alloziierst, muss der Kernel halt nicht
eine Million mal
eine 1 Kilobyte-Page irgendwo
in seiner Tabelle abmarkern, weil auch das
kann plötzlich schon mal 2, 3, 4,
500 Millisekunden dauern, sondern der sagt dann einfach nur noch, hier hast du das Gigabyte.
Und das sind so Sachen, wo Python dann eben auch häufig optimiert und Python ist extrem
erfolgreich, was diese Optimierung angeht. Ein Beispiel dafür sind zum Beispiel Listen.
Listen haben eine, es gibt eine Operation bei Listen, die ist unoffensichtlich O von 1,
nämlich ein Append an Listen bei Python
ist
sind Listen nicht immer ein O von 1 Append?
Ja, sollte.
Es gab irgendeinen spezifischen Fall.
Also die Story drumherum grob ist die, dass die Speicherallokation
für Listen in Python auch immer nur verdoppelt.
Der allozidierten Buffer für die
für das Array, um die Indizes zu verwalten
und
alloziiert aber, wenn er dann
es größer machen muss, nicht einfach
sozusagen, dann muss er ja sozusagen
das ganze, achso genau, das Problem ist, wenn du es dann größer
machen willst, musst du
den Bestandsspeicher plus 1 nochmal
neu alloziieren, alles umkopieren und
dann halt das neue reinschreiben. Was Python aber macht
ist, Python alloziiert immer
dann das Doppelte von dem, was es vorher hatte,
kopiert das einmal um,
dann sind die nächsten
n gratis,
Dann muss er wieder einmal verdoppeln, einmal kopieren und dann hast du wieder 2n gratis und das sind so typische Sachen, die man in solchen Situationen halt hat, was so Laufzeitumgebungen für einen automatisieren und machen und weswegen sich dann hinten so ein bisschen komische Speichereffekte ergeben.
da habe ich lange Zeit meines Lebens auch immer mit dem Kopf
an meinem Kopf kratzend davor gestanden und konnte Leuten nicht erklären, warum es das jetzt gerade tut
und da muss man sich halt irgendwann sagen, kann man nicht erklären, warum es genau das jetzt gerade tut
kann ich dir nicht erklären, ich bin mir relativ sicher, dass es kein Leak ist
wenn du halt dann irgendwie mal sowas beobachtest über eine Woche oder einen Monat
wenn du einen langlaufenden Prozess hast und die Saisonalitäten findest und du was merkst wie
ah ok, frühmorgens haben die Leute ihren Kaffee getrunken, jetzt lesen sie alle irgendwie das was auf seiner Webseite ist
und Jochen unterhalten sich über die Programmiersprache Python
ist es schwierig, kontrollierbar schlanke
Prozesse zu machen.
Das geht nicht so ohne weiteres. Also das geht schnell,
dass dein, wenn du
zum Beispiel eine Datenverarbeitungspipeline
hast mit 9 oder 10 Schritten
und jeder Schritt davon braucht
irgendwie einen Gigabyte RAM,
dann kann das schon sein, dass dein Python nachher
10 Gig frisst.
Weil er halt eben den Speicher von vorher
noch nicht freigegeben hatte, der jetzt aber auch gerade nicht
gepasst hat, um das nächste Ding zu bearbeiten
und dann so.
Das kriegst du unter Python halt nicht gut kontrolliert
Ja, vor allem weil alles so dynamisch ist
weil ich also im Zweifel auch wirklich den Stack hochwandern kann
und schauen kann, was da rumliegt
oder ein Integer-Objekt als beliebiges Objekt sehen kann
was halt in Rast ohne weiteres nicht möglich ist
und auch in anderen Programmiersprachen nicht geht
Aber auch
ohne Speicherverwaltung kann ich ja in Python
durchaus noch andere Sicherheitslücken machen
die also gar nichts mit dem Speicher zu tun haben
mit dem, was wir jetzt die meiste Zeit besprochen haben
sondern halt zum Beispiel, dass ich sage
ich verwende einen Subprozess
und öffne den Subprozess und
übergebe
einen String und habe diesen
String halt konstruiert aus Benutzerdaten
und jetzt habe ich plötzlich eine Command Injection,
dass man beliebige Shell-Commandos ausführen
kann.
Das kann man in jeder Programmiersprache
und in jeder
Programmiersprache, die Shell-Commandos ausführen kann.
Natürlich kannst du dich auf den Standpunkt stellen,
man hat das gefälligst nicht zu machen oder
man hat gefälligst immer Shell gleich false zu setzen
oder der Standard, dass man eine Liste
übergibt.
aber
es gibt noch zahlreiche andere
Schwachstellen, glaube ich, die
auf höherem Level noch passieren können,
die gar nichts mit dem Speicher direkt zu tun haben.
Ja,
absolut, genau.
Habt ihr schon mal böse Sachen gesehen, die in Python
schiefgegangen sind?
Ich weiß nicht, ich überlege gerade, ob ich
irgendwas mal wirklich
Schlimmes gesehen habe.
Der Shellout, den Philipp
da nennt, das ist schon schlimm.
Das ist klassisch.
auch sehr beliebt ist, wenn Leute
meinen, ich muss hier Flexibilität reinbringen
und jagen halt irgendwie User-Input einfach durch
ein Eval durch. Das ist sozusagen
die interne Variante des Shell-Out.
Was ist denn ein Eval?
Eval ist Evil.
Aber das ist im Prinzip die...
Oh ja, doch, Pickle.
Eieiei.
Ja, Pickle, nur trusted.
Ja.
Da kann man sich schon mit dem Fuß schießen.
Mit Eval haben wir sogar einen ganz, ganz schlimmen Bug,
und zwar hat eine Anwendung auf die Idee gekommen,
dass man doch das cachen könnte.
Und man könnte doch
den Code nehmen und dann kann man sich so ein
kurzes, also man nimmt irgendwelche Benutzerdaten,
die oftmals abgerufen werden, dann schreibt
man dynamisch Python-Code,
der das ausführt und dann kann man das cachen.
Und dann war aber das Problem, dass
sogar die noch eine Datenbank-Schlafstelle hatten, dass man
sehen konnte, was in der Datenbank lag
und da lagen deren Cache-Objekte.
Und dann lagen da plötzlich Benutzer-Passwörter oder sonst
irgendwelche Sachen,
die halt, also da kann man halt
Wenn man Schwachstellen verkettet, kann man das auf sehr krumme, sehr fiese Sachen, die man mit der einzelnen Schwachstelle gar nicht machen könnte.
Also das war jetzt nicht der Fehler von denen, also es war ein Fehler, dass man den Cache plötzlich sehen kann und es war ein anderer Fehler, dass sie überhaupt Ival verwendet haben, aber erst durch die Kombination ist es halt eigentlich eine Schwachstelle gewesen.
Auch so ein klassisches Ding ist ja auch
Directory Traversal, dass halt
irgendwie von außen sagen kannst, ich will
xyz haben und dann
wird halt nicht ordentlich geguckt, ob du durch
. . . Kombinationen plötzlich dir
dann irgendwie etc. pass, wenn du dir unseren Kram halt
auslesen lassen kannst und das sind immer
auch, das ist tatsächlich glaube ich am wichtigsten
und deswegen ist dieses, das ist
wieder Variety matches Variety
deswegen sagen wir, wir wollen so schnell
so viele Verbesserungen
in der Security wie möglich durch unsere Entwicklungspipeline
jagen können, weil
die eigentlichen Vektoren ist nachher,
dass du hast immer eine Vielzahl
von potenziellen
Schwachstellen, die für sich genommen alle gar nicht so
schlimm sind. Und wenn du aber
immer nur auf der Suche nach dem einen großen Ding
bist, um alles zu reparieren,
dann vergisst man schnell, dass es halt eher um
diese Verkettung geht, wie Philipp sagt.
Da gibt es viele Kleinigkeiten, die das halt machen.
Also eben Directory Traversal, irgendwie Daten
abzusaugen, die dir dann einfach nur noch den Pointer geben
für, ah guck mal, da könntest du da drüben nochmal gucken.
in Klassiker, den ich mag, sind Exceptions.
Exceptions sind für mich die sensibelsten Daten, die dein System zur Laufzeit eigentlich von sich gibt,
weil das Problem ist ja folgendes, dein System ist in einem nicht bekannten Zustand,
mit Daten, die du nicht kennst und weißt nicht mehr, was es tun soll.
So, und die Daten können halt alles sein.
Das können die Kreditkartendaten sein, das können die was auch immer.
Und dann steht da irgendwie Value Error, hast du nicht gesehen?
und du kannst den User nicht davon abhalten,
Daten ins falsche Feld zu schreiben.
Dann schreibt er seine Kreditkartendaten
halt das erste Mal irgendwie bei seinem Nachnamen aus Versehen
rein. Und deswegen diese
Bewertung von was ist eigentlich sicher und was
ist unsicher, ist total schwer.
Das Paradigma sollte auch
eher sein, lieber ein bisschen
zu sensibel zu sein und sozusagen
dein Schutzniveau einmal
grob festzulegen und zu sagen, okay,
wir gehen ja mit Kreditkartendaten um.
Du musst davon ausgehen, dass irgendein
doofer User, nein, die User sind nicht doof,
Es ist ein Usability-Problem. Das Usability-Problem ist, dass wir halt ein Gehirn haben, was bekloppt ist. Da kommt dieses ganze Thema Cognitive Processing rein von unser Gehirn will Energie sparen und deswegen reagiert es auf irgendeine Form von Challenge immer mit der billigstmöglichen Antwort, also Pattern Matching.
und das Pattern-Matching von unserem Gehirn ist auch nicht Best-Match, sondern First-Match.
Das heißt, du hast eine Seite vor dir, hast aus deinem Passwort-Manager deine Kreditkartennummer kopiert,
dein Kind will was von dir, ja bitte, ich muss nur noch, klick, klick, klick,
und dann hast du halt deine Kreditkartennummer in das falsche Feld eingetragen.
Und das ist halt, wie wir das bei Microsoft damals, alle zwei Millionen Mal,
ja, das ist bei uns halt nächsten Dienstag.
und
sowas, deswegen sagen wir auch, wenn wir
Anwendungen dann mit Schutzniveaus
belegen und sagen, was macht man hier,
dann gucken wir eigentlich nur noch nach dem Worst Case
und sagen so, jetzt müssen wir davon ausgehen, dass
das ganze Ding mit dem Niveau geschützt werden muss.
Weiter differenzieren macht überhaupt keinen Sinn mehr,
weil du kommst dann von Hölzchen zu Stöttchen
und irgendwer greift
eh daneben und deswegen bin ich mal
sensibel drum, wenn es darum geht, so Exceptions
an externe Systeme weiterzuleiten,
weil im Prinzip
übergibst du jemandem Externes alle deine Daten, weil du ja gar nicht weißt, was in der Exception drin ist. Wenn du es gewusst hättest,
hättest du halt schon irgendwas geschrieben, damit die nicht auftritt.
Aber wie bekommst du dann mit, wenn Exception passiert? Also an irgendein System muss das ja weitergeleitet werden, oder?
Ja, internes System. Ich habe mich hier heute jetzt noch nicht wieder vorgestellt, ich bin ja so ein bisschen Stammgast schon.
Philipp und und
Was ist Greylock, Christian?
Das ist ein Log-Aggregationssystem, also den kannst du mit Log-Daten befüttern
und ihn dann nachher Parser drüber jagen lassen und dir automatisch Alerts schicken.
Das ist auch so ein Ding, da spielen wir gerade zum Beispiel mit rum für so Threat-Themen.
Der kann aus Log-Daten IP-Adressen rauspopeln und, der technische Begriff für Parsen,
und hat halt dann wieder eine Anbindung an, daran abzugleichen, ob diese IPs assoziiert werden mit irgendeiner Form von, da kommen ständig Angriffe her.
Und dann kann ich die Auswertung dann wieder zurückfüttern auf meine Firewall vorne und kann sagen,
so, und immer wenn irgendwie eine IP, die den Threat-Indicator hat, irgendwie öfter als so und so oft pro Stunde vorkommt,
dann wird die jetzt erstmal für drei Tage lahmgelegt.
Das ist aber gefährlich, es kann ja sein, dass jetzt irgendjemand auf die Idee kommt und sagt, okay, du hast einen ganz, ganz wichtigen Kunden, mit dem du immer kommunizierst und derjenige schafft es irgendwie in das Netz reinzukommen von dieser IP und dann listet er diese Anfrage aus. Ich glaube, da gab es auch schon mal Virus-Genere, die sobald ein Paket kam, dann die gesamte IP geblockt haben und dann konnte man die lustig anschreiben von 8888, einem typischen DNS-Server und die haben gesagt, oh, das Paket sieht nach Virus aus, alles sofort blocken, alles von diesem Rechner und dann geht nichts mehr.
Ja genau, da muss man immer mit vorsichtig sein
und nichtsdestotrotz
so ein bisschen mit so Sachen experimentieren wir halt gerne mal rum
zu gucken, wie sie aussehen
und dann willst du halt immer noch die Möglichkeit haben, nochmal
durchgreifen zu können in dem Moment
Klar, aber ich meine
macht das auch solche Sachen wie
weil ich kenne das eigentlich eher so als
es gibt immer, entweder verwenden Leute
diesen Kibana-Stack oft
Kibana hatte ich nachher Kibakisch-Banane an
Ja
auch immer nur, dass man da externe Services
verwendet. Kein Problem, Sentry kann man
ohne Problem, ist ja auch ein Source-Projekt, kann man
ganz normal selber hosten.
Kommt ja auch selber aus der Python-Ecke, ist glaube ich
auch Django unten drunter oder so,
ich bin mir gar nicht mehr sicher, aber
stimmt, ist auch genau.
Sentry ist ja relativ groß geworden
tatsächlich, Armin und so.
Und die kannst du selber
hosten tatsächlich an der Stelle.
Das würde ich dann auch immer empfehlen.
Wichtig ist sozusagen der Unterschied
von der Log Aggregation
versus
Exception Logging.
Exception Logging hat die große Aufgabe,
wenn du viel vom
Gleichen entgegenkriegst, weil
der eine bugt gerade 50.000 Mal
im letzten Tag auf, dann willst du, dass der dir die
schon normalisiert und sagt, hier,
das Problem gab es jetzt in 50.000
Instanzen, hier sind die Parameter, die ich gesehen
habe. Logging macht natürlich
immer nur, hier ist der Hydrant,
hier kommt alles raus.
Ja, einfach so.
vor allem müssen die ganz viel mit Speicher machen
und ganz viel Level erarbeiten
genau, das was ich nicht haben will
also wo ich es noch sehe, wo ich noch mitspiele
ist, wo wir es gerne haben
wo es angefragt wird und wir dem nicht
harsch widersprechen
ist, wenn du
tatsächlich sowas hast wie
deine Anwendung nimmt Daten per Mail oder
Upload entgegen und du weißt, die werden dann
nachher auf eher schlecht gepflegten Rechnern
wieder weiterverarbeitet
also wir haben so ein Kram, wo dann keine Ahnung
Wordfiles reinkommen und die sollen dann von irgendeiner dritten Partei auf ihrem
Windows-Rechner verarbeitet werden, dann habe ich halt mal
einen Klamm-AV damit drauf sitzen, der halt diese
eine Datei scannt, aber das ist dann kein Ding, was das
System scannt, sondern es ist bloß ein Programm. Hier
scannt die eine Datei, du sagst, ja, okay, dann geben wir die weiter und
wenn nicht, dann sperren wir sie halt zur Seite. Das ist eine Form
von Virenscanner, da spiele ich punktuell halt noch mit.
Das kann man schon mal machen. Was ich halt nicht leiden kann,
sind diese Security-Suites, die dann irgendwie einen Rechner irgendwie übernehmen und
irgendwie mehr Schaden machen als, also gut, ich meine, da braucht man bloß Fefe lesen,
da kriegst du es halt alle zwei Wochen wieder serviert, Schlangenhöhle und so.
Ein gutes Konzept.
Was ich eben noch kurz erwähnt hatte, was ich mir noch irgendwann drüber gestolpert
bin, was bei Django eine DOS-Attacke möglich war, und zwar bei RackEx,
die benutzt worden ist, um bestimmte Formularfelder auszulesen,
Das heißt, man konnte einfach, indem man
in Formulare, ich glaube E-Mail oder so,
einen cleveren Regex reingeschrieben hat,
irgendwie eine
exponentiell wachsende oder endlose
Schleife produzieren und dann die
Seite... Man kann Regex
bauen, die sehr, sehr langsam werden
dann. Genau.
Dann hat man einfach ganz viele Requester
dran geschickt und dann hat man halt die Seite in die Knie zwinkern.
Das haben die irgendwann gefixt. Ich glaube auch
relativ spät, erst bei einer Zweier-Version, wenn ich das richtig
bekommen habe. Sehr interessant,
solche Sachen. Also das denkt man immer
jemand, der keine Ahnung hat, nicht dran, dass
in so einfachen Bibliotheken wie
RegEx da was Tolles hinterstehen kann.
Was ist das? Perl RegEx oder wie nennt man das?
Diese Perl Compatible RegEx
als PCIe, aber ich
weiß nicht, ob das...
Die Python RegEx Engine ist eine eigene.
Ja, okay.
Also moderne RegEx Engines können schon nicht alle
Fälle, aber viele Fälle da
besser erkennen und haben dann auch bessere
Garantien, also nicht erkennen, aber haben
Garantien, dass das halt nicht in diesen
exponentiellen Fall läuft. Natürlich nicht immer.
und natürlich kann ich immer einen Regex produzieren,
der einfach so lange dauert, weil ich einfach sage,
okay, hier kommt irgendwas Beliebiges und das
darf beliebig auch vorkommen und wenn ich dann
einen langen String habe, dann ist es halt total,
dann gibt es
natürlich exponentiell viele Möglichkeiten,
wie ich das Matching nehmen kann
und wenn ich den String so konstruiere, dass das Matching nie passiert,
dann dauert es halt ewig.
Also unerländlich nicht, aber schon mal
länger ist das Universum.
So, ich mache hier mal kurz,
wir müssen eine Chapter-Mark hier ziehen.
Ich muss jetzt raus, ihr könnt mich rausschneiden.
Alles klar, du kannst
das falsche sagen.
Wir haben eine Sekunde Pause gehabt, das könnt ihr rausschneiden.
Alles klar.
Insofern, bis zur
Fortsetzung demnächst mal wieder.
Euch noch viel Spaß. Bis dann. Ciao.
Ja.
Haben wir denn zu dem
Security-Thema noch irgendwie,
ich weiß nicht genau, irgendwelche Dinge,
die wir unbedingt erzählen
wollten?
oder, ja,
also, mir fallen noch einige
Sachen ein, aber frage ich erstmal euch weiter.
Was willst du denn noch erzählen?
Es gibt, also, was
wichtig ist, dass
man eine Funktion nimmt
oder eine Standardmöglichkeit nimmt,
um sich gegen eine Sicherheitsschwachstelle
zu verteidigen. Also, wir haben eben schon
Path Traverses angesprochen, da könnte man denken, okay,
also, bei Path Traverses ist das Problem, dass ich
irgendwas in den Pfad einschleuse, typischerweise
halt . . . .
slash um halt aus dem Pfad der Anwendung rauszukommen und dann statt eine lokale Datei der Anwendung zu lesen, bekomme ich halt eine Datei irgendwo aus dem System.
Weiß ich, die Passwortdatei oder die Datenbankdatei oder irgendwas anderes.
Und eine Möglichkeit, um sich dagegen zu beteiligen, ist natürlich zu sagen, ich nehme immer alle Punkte raus oder so.
Oder alle Slashes raus.
Und dann kommt man halt auf andere Systeme, zum Beispiel unter Windows, da ist ja ein Doppelpunkt wichtig.
Und dann muss man auch an den denken und dann ist der Backslash wichtig.
Und es ist halt sehr schwierig, sowas richtig zu schreiben.
und da gibt es immer wieder Leute, die es versuchen, die sagen, ja, ich weiß es trotzdem und bei einigen
Systemen geht das auch, also man kann zum Beispiel bei SQL
Induction kann man relativ einfach vermeiden, weil das halt eigentlich
nur ein einfaches Anführungszeichen ist, aber es ist halt immer gut dann für eine fertige Funktion
oder eine fertige Struktur zu nehmen, die genau dafür programmiert ist und
die dann auch, zwar die sicher ist, aber die ist halt sicher
oder hoffentlich sicher, weil es halt nur eine ist, in Python zum Beispiel, in Prath
zu verhindern, kann man halt
os.path.basename oder aus der PathLib
was nehmen, statt halt
selber zu versuchen, diesen String zu bearbeiten.
Also nicht selber machen, Security
war das der... Ja, genau.
Es sei denn, man weiß, was man
tut. An einigen Stellen kann das richtig
sein. Und ich glaube, ein anderes häufiges Problem
ist auch, dass man sagt,
ich versuche, die Eingabenbedarfen zu früh
abzufangen.
Also ich sage, okay, ich habe eine ganz komplizierte
Anwendung und immer wenn mir jemand
was mit einem Anführungszeichen schickt, dann sage ich, geht
sehr schwierig, weil man halt ein komplexes
System hat, vielleicht sogar mit mehreren
Microservices, die die Daten aus verschiedenen
Quellen
anliefern. Aber wenn man darauf vertraut, dass
die Datenbank irgendwie gute Daten enthält, das ist
immer sehr, sehr gefährlich.
Ja, ist interessant, welche Assertions man da
daraus gibt oder welche Dinge man daraus macht, wenn das
nicht dem erwarteten Standard entspricht oder so.
Ein paar Stolperfallen, dass man einfach
interpretiert, was da kommt, ist wahrscheinlich
eine Mitte, wie die... Genau, man muss immer misstrauisch sein gegenüber
bei allen Daten, also auch der eigene Datenbank,
auch die kann Schrott enthalten.
Okay, guter Tipp.
Ja, ansonsten genau, ein Thema,
wo ich immer denke, das kann doch nicht so schwer sein, aber
ich tue mich irgendwie schwer damit,
ist halt, wie authentifiziert man sich
eigentlich richtig irgendwie
zum Beispiel per
einer API, per HTTP
oder so, oder die Web-Authentifizierung
ist irgendwie nicht so einfach.
Und dann, ja,
Es gibt ein paar interessante Artikel dazu die wir letztens gelesen hatten warum JBT kaputt ist und dass die Leute nutzen und sagen das ist der Standard den es da gibt Ich habe aber auch jetzt auch noch nicht so viel gefunden was man da anderes machen kann Es gibt irgendwie Passeto oder PyPasseto aber da gibt es noch nichts wirklich Nutzbares Das muss man irgendwie auch alles wieder selber machen vielleicht und das ist auch vielleicht wieder nicht so
eine gute Idee und da ist es gar nicht so
einfach, sich vernünftig per Token zu authentifizieren.
Ja, tatsächlich. Also das, was ich jetzt auch
ist halt, ja, HTTP-only-Cookies.
Ja.
Vielleicht.
Ja, Session-Cookies ist halt
manchmal ein bisschen
schwierig, aber
Aber ja, das ist immer wieder, wo ich mir denke, das müsste doch eigentlich jetzt einfach sein, aber irgendwie ist es das nicht.
Oh, oder hast du mal so von Indie aus gehört?
Ich meine, das ist halt so eine etwas abgespeckte O-Aus-Variante.
Nee, gar nicht.
Okay, ja.
Was ist das?
Das ist sozusagen, dass man halt
selber
also
das ist auch von dem
von den gleichen, also das hat
jetzt komme ich vom Hölzchen aufs Stöckchen
das hat was mit dem Indie-Web zu tun, das ist so eine Bewegung
um, dass man halt
die Dinge selber machen kann, wo man
normalerweise immer irgendwelche Unternehmen für braucht
die das halt machen
und es geht zum Beispiel darum, dass man sich mit seiner eigenen
Webseite einloggen können will
sozusagen. Also nicht
Username, Passwort, sondern man
gibt halt ein URL an und dann hat man
gibt es halt sozusagen einen Hook, wo dann
irgendwie man sagen kann,
wie man jetzt
wie man sagt, dass man jetzt
authentifiziert ist und dann zum Beispiel kann man sich dann halt irgendwie
eine
Push-Notification schicken lassen aufs Handy
und dann sagt man halt, ja okay, das war
jetzt richtig oder man kriegt einfach eine E-Mail geschickt
oder so und drückt dann auf einen Link und dann
Ja, mal dein YubiKey bitte oder sowas. Genau, genau, genau.
und solche Sachen. Und man ist ja sehr frei in der Art, wie man das halt dann,
wie man diese Authentifizierung gestalten kann. Und das klingt eigentlich schon sehr nett.
Das ist ja sicherlich immer die einfachste Lösung, wenn du sagst, ich möchte selber keinen Benutzernamen,
keinen Passwort speichern, weil einerseits sind mir die Daten zu sensitiv und ich muss genau gucken,
wie ich das richtig speichere. Ist zu sagen, okay, ich mache einfach, ich speichere überhaupt keine Benutzernamen
und Passwörter und ich verwende irgendein Single Sign-On-System. Du hast ja schon ORAS angesprochen
oder OpenID Connect, das ist ja der
alternative Standard,
dass man sagt, okay, jemand anders muss sich drum kümmern.
Und dann habe ich zwar diesen
anderen Dienst, der irgendwo vielleicht auch in meinem Netzwerk
ist oder vielleicht sagt, okay, ich erlaube
Login mit Facebook, mit Google, mit Twitter und so weiter
und mit GitHub.
Dann müssen die sich halt drum kümmern und dann kann ich halt
da auch meinen, bin ich da raus aus der Sache. Ich muss kein
Passwort speichern und für den Benutzer ist das ja eigentlich auch nicht
schlecht, weil der Benutzer muss kein Passwort wählen.
Wenn der Benutzer ein Passwort wählt,
das ist ja auch...
nicht so gut. Aber das hat auch
ein paar Falschstücke wieder. Also zum Beispiel, wir hatten
jetzt das System, dass wir auch so
ein OpenID Connect irgendwie Schriftstelle bauen
mussten, aber wir haben das dann über
Django All aus versucht zu implementieren,
der ja viele davon schon bereitstellt, irgendwie als
Pakete und dann mussten wir aber so einen eigenen
Provider dafür bauen, weil der, den wir
da hatten, der hat nicht genau das gemacht, was wir wollen.
Ich bin mir nicht sicher, ob das, was wir da gebaut haben,
alles so gut, so richtig funktioniert.
Das wird sich dann irgendwie im Laufe der Zeit zeigen.
Das müssen wir richtig testen. Mal gucken.
Beim ersten
Pentest, hoffentlich.
Oder beim ersten Pentest, der ungefragt ist
und ungefragt ausgesucht wird.
Ja, aber
was ich
vor allen Dingen blöd finde bei diesen ganzen
OpenID-OAuth-Geschichten auch,
ist halt, dass man dann halt alles an so
bestimmte User-Accounts
hängt. Weiß ich nicht, ob das jetzt GitHub,
Twitter oder schlimmer noch vielleicht Facebook
ist oder so. Dann passiert irgendwas Blödes
und dann verliert man halt den Account und dann verliert man gleichzeitig
den Zugang zu ganz vielen anderen Sachen.
Das ist ja auch irgendwie nicht so schön.
Ja gut, aber dadurch
braucht der Blitz halt nur noch
ein Kennwort und Facebook kann halt sehr, sehr
viel bessere Sachen, bessere Authentifizierung
durchführen, als du es machen könntest.
Die schauen halt auf deine IP-Adresse, auf deinen Browser,
die haben noch einen Session-Token, die haben
vielleicht auch eine Mehrfach-Authentifizierung,
dass du noch
irgendwie auf dem Handy was bestätigen musst
und das gibt es ja
an einer Partei, das musst du nicht alles selber
implementieren.
Wenn du es selber implementierst,
Es gibt wirklich dann einige Firmen, die das dann wohl doch dann ernster nehmen, als man manchmal so denkt.
Ich war zum Beispiel mich einmal irgendwo ans Ausland geflogen, als man das noch durfte irgendwie
und habe eine relativ hohe Überweisung angefordert, irgendwie da so durchgeführt.
Und auf einmal bekam ich dann so einen Anrufer von meinem Telefon von der Bank, die meinte so,
ja, hallo, wollen Sie das wirklich tun? Oder waren Sie das?
Ja, das war ich. Ja, das ist ja alles gut.
Ja, aber das war schon mal nett, dass Sie nochmal nachgefragt haben,
anstatt dass Sie einfach eine hohe Summe irgendwo hin überweisen oder von irgendwo.
Das ist schon gar nicht so
unrichtig, dass dann vielleicht
dann ein Mensch da nochmal nachguckt, also dass dann solche
Alerts irgendwie in das System rausgehen, die dann nochmal
gucken, wenn irgendwas ist
Genau, das kann deine Anwendung ja nicht leisten, das
möchtest du ja normalerweise nicht machen, du möchtest ja nicht anfangen
SMS zu verschicken oder was auch immer
oder solche Überprüfungen
zu machen und ich glaube, das ist einfacher, wenn man sowas
zentralisiert und wenn du
ein Passwort, also
viele Leute verwenden halt ein Passwortmanager, aber auch
die, glaube ich, die große Masse an Leuten
verwendet immer noch in 2020 keinen Passwortmanager,
sondern haben ein Standardpasswort,
was sie dabei verwenden. Und wenn dann halt irgendein
Katzenforum gehackt wird, dann bist du plötzlich dran
und dann rufen deine Kunden an, warum wurde hier
meine Bankseite oder was auch immer, welche Seite
du anbietest, warum wurde die gehackt?
Und dann sagst du, ja, du hast das gleiche Passwort in deinem
Katzenforum verwendet. Und die haben halt,
wir haben die besten Sicherheitsstände, aber das Katzenforum,
das ist halt nur irgendeine Kiste,
die irgendwo läuft.
Da reichen sich die
Hacker, die wird in der Türklinke
drücken sich die Hand, weil da halt
so viele Hacker drauf sind, dass die sich
gegenseitig schon stören mit ihren ganzen Exploits
auf dem Katzenforum. Und das ist halt ein Problem, was
du mit dem Sing-It-Sign-On direkt
an andere Leute verschiebst. Dann muss sich Facebook
oder Google oder wer auch immer
oder dein eigener Sing-It-Sign-On-Service
muss sich dann darum kümmern.
Ja.
Ja, ja. Ja, wir haben ja noch so ein paar Sachen
glaube ich vergessen. Also was wäre mit Security?
Müsste man ja eigentlich noch über Social Engineering
reden und ganz andere
Geschichten. Also ein paar USB-Sticks auf den Parkplatz
fallen lassen oder sowas.
und wie man Corporate sicher bekommt und wie man die Leute auditen kann.
Und da gibt es ja so Experimente zu.
Zum Beispiel, einige Konzerne verschicken ja dann so Test-E-Mails oder Trainings-E-Mails regelmäßig,
um zu gucken, klicken die Leute auf alles, was da so in Mail verflattert.
Und die Antwort ist schon, ja, das tun sie.
Und dann kann man die halt ein bisschen erziehen oder sowas,
sodass man die Quote davon reduziert und das ist eine ganz spannende.
Ja, aber
da würde ich jetzt auch ganz spontan
würde ich sagen, naja gut, aber ich meine, dafür sind doch
die Sachen dafür da, dass man da drauf klickt
also ich meine, das ist ja
das kann es ja eigentlich nicht sein, dass man
irgendwie die Leute dazu entzieht
irgendwie sich an komische Regeln zu halten
damit die Software bleiben darf
das ist ja irgendwie
Ja gut, da gibt es ja ein ganz wichtiges Sicherheitskonzept, was wir noch gar nicht so richtig
wir haben es Schweizer Käse genannt
oder Defense in Depth, dass ich sage, okay
ich sorge dafür, dass auch wenn
also dem Chef der Firma
und Jochen unterhalten sich über die Programmiersprache Python
und die HubiKey angesprochen, den man genauso einsetzen kann, wenn er ein Mensch ist.
Aber auch zwischen Systemen ist das, glaube ich, so der goldene Stand,
dass man sagt, okay, ich habe einen Client-Site TLS-Zertifikat,
ich habe einen Server-Site TLS-Zertifikat.
Vielleicht nochmal ganz kurz da, einmal kurz das Low-Layer.
Also TLS ist irgendwie Transport Layer Security.
Genau, auch bekannt als SSL.
SSL ist der Vorgang.
Und das macht doch was sicher, wie eine Verbindung zu einem anderen Rechner,
dass die irgendwie verschlüsselt übertragen,
dass man sich nicht in die Mitte setzen kann, um das abzuhören.
Ja, nicht eine Verbindung zu einem anderen Rechner,
sondern auch von einer Anwendung.
in einer anderen Anwendung.
Ja, genau.
Ja, okay.
Ja, das sind halt irgendwie so genestete
Sicherheitslevel, die irgendwie so ineinander stecken und das ist dann
wo es dann irgendwann alles relativ komplex sein
mit den ganzen... Ja, ja, du brauchst halt
allein für sowas wie eben
so eine stinknormale, ich weiß nicht,
Anwendung, wie du besuchst, bist auf deiner Bankseite
und machst da irgendeine Transaktion
und müssen halt viele Dinge gewährleistet
sein, also der TLS-Teil
macht halt die Vertraulichkeit
beziehungsweise Integrität, ich weiß jetzt gar nicht genau,
aber was du halt auch noch
beides genau,
was du halt auch noch brauchst, ist halt
Authentifizierung, also du musst dich halt
irgendwie gegenüber der Bank ausweisen, damit
die Bank weiß,
wer du bist und überprüfen
kann und das ist dann der dritte Teil, ob du auch
autorisiert bist, das zu tun, was du da tun willst,
das ist halt nochmal getrennt davon, weil es kann ja sein,
du hast dich zwar eingeloggt, aber du darfst
irgendetwas nicht machen und
Autorisierung ist ja auch nochmal so ein Riesenthema,
das ist, wie kriegt man das eigentlich ordentlich hin und Der coole Trick beim PLS ist halt, dass du sagen kannst, ich, also du kannst erstmal sowieso asymmetrisch arbeiten, das heißt, der private Schlüssel verlässt nie die Box. Du hast also einen Client, also einen Service, der einen anderen Dienst was sendet und der hat einen privaten Schlüssel und der andere Dienst kennt nur den öffentlichen Schlüssel und das kannst du noch weiter treiben, indem du halt sagst, ich verwende nicht, der andere Dienst muss so nicht mal den öffentlichen Schlüssel kennen, sodass
und Jochen unterhalten sich über die Programmiersprache Python
auskommt und da gab es ja irgendwie
Algorithmen, mit denen man bestimmte Dinge
verschlüsselt oder hasht
oder wie auch immer und die man dann
mehr oder weniger schnell entschlüsseln
konnte oder sowas. Oder man konnte sogar so
Angriffsverfahren wie Rainbow Table
nennt sich das oder sowas, dass man halt Passwort hasht
und einfach in eine Tabelle schmeißt und guckt, wie ist denn das
Ergebnis von dem Hash, also was ist denn da der umgekehrte Wert
von oder so. Und ja, wenn man
solche Sachen halt irgendwie
vermeiden möchte, dann müsste man glaube ich
schon gucken, welchen Algorithmus man zum Schlüsseln,
zum Entschlüsseln seiner Schlüssel nimmt.
auch irgendwie...
Ach, und das ist zwar für Schlüsselsachen.
Mein Passwort möchte ich eigentlich nicht verschlüsseln,
weil dann muss ich ja den Schlüssel irgendwo auf dem Server
speichern.
Also das Passwort eines Nutzers möchte ich nicht.
Ich meinte ja so SSH-Keys oder sowas,
das meinte ich mit Schlüssel,
die dann bestimmten Algorithmus benutzen irgendwie.
Okay, ja.
Das müsste ich ja vielleicht nochmal erklären,
also wie man halt da von einem
nicht so guten Algorithmus
den Schlüssel berechnen kann aus einem Public Key oder sowas.
bei asymmetrischer Verschlüsselung.
Den Schlüssel selber musst du eigentlich nicht berechnen.
Du kannst ein Zertifikat berechnen,
das ist der Schlüssel nochmal in kurz, aber du könntest
eigentlich auch immer den Schlüssel an sich verwenden,
den öffentlichen Schlüssel zumindest.
Nur weil der öffentliche Schlüssel ist halt bei dieser
Kryptografie sehr lang, das muss halt eine sehr lange Zahl sein
und die kannst du halt eindampfen auf eine
kürzere Zahl, die man aus verschiedenen Gründen dann
verwendet, die auch immer gleich ist, egal wie lang
der Schlüssel ist und das ist das Hash-Verfahren.
Das verwenden wir auch bei Passwörtern und auch an vielen
und die anderen Stellen kann ich auch verwenden, um zum Beispiel zu überprüfen, wenn ich Software runterlade,
dass die in Ordnung ist. Haben wir eben schon mal angesprochen, dass wenn ich
das mit Python mache, dann habe ich zum Beispiel bei pip
habe ich ein pip-File und ein pip-File.log
und in dem pip-File.log stehen halt die ganzen Hashes drin. Und was ein Hash macht, ist halt genau
eine lange Eingabe zu nehmen, egal welche Länge, und sie auf eine Zahl
zu reduzieren, die eine relativ kurze Länge hat
und die auch immer die gleiche Länge hat. Das sind dann halt nachher so 32 Buchstaben oder sowas.
Und das ist halt kryptografische Magie.
Und es gibt halt Mathematiker,
die haben sich darum gekümmert, dass es nicht möglich ist,
das rückwärts zu rechnen. Das heißt, wenn ich ein Hash habe, kann ich nicht das Original
berechnen und ich kann gegeben einen Hash, kann ich
überhaupt nicht ein Original finden. Das heißt, wenn du mir dein Hash gibst, dann kann ich eigentlich
hier sein, dass
die Originaldatei genau unverändert ist.
Und genau dafür kann ich die halt
einsetzen.
Mhm.
Ja.
Okay, das Rückrechnen ist dann
bei unsicheren Hash-Verfahren dann vielleicht
dann doch möglich oder sowas? Oder dauert das lange?
Ja, und man kann halt
Kollisionen finden dann. Und dann kann man
eben beispielsweise Dokumente dadurch fälschen, dass
man, wenn man hinten
Leerzeichen anfügt oder wegnimmt, kann man ja
viele Kombinationen erzeugen, weil man weiß, wie man
die Kollision erzeugen kann, dann kann man halt
quasi beliebige Texte mit einem bestimmten Hash erzeugen
und das ist natürlich ganz schlecht.
Genau, dann habe ich halt deinen Schlüssel
und dann kann halt jemand anders einen anderen Schlüssel
generieren und die haben plötzlich den gleichen
Hash. Dann kann er sich mit
seinem eigenen Schlüssel, der so tut, als wäre dein Schlüssel
damit authentifizieren.
Also es geht um Sicherheit von Kryptografie
oder sowas in der Hinsicht noch?
Ja, aber ich glaube, ich weiß gar nicht, ob man
sich als Endanwender oder so
wahnsinnig viel mit beschäftigen muss, weil
ich glaube, wenn man da anfängt, sich für zu interessieren
und dann irgendwelche Entscheidungen zu treffen,
dann liegt man wahrscheinlich eher
hoch, dass man falsch liegt.
Also genau, dann kann man quasi diese Wahl
auch gar nicht mehr treffen, welche
kryptografischen Algorithmen man zum Verschlüsseln, Entschlüsseln
benutzt.
Also wenn du
zum Beispiel hasht, dann musst du in der Python-Hashlet
sagen, okay, ich möchte diesen Hash haben.
Dann sagst du zum Beispiel, ich möchte SHA-1 haben.
Oder ich möchte MD5 haben.
Und wenn du da die falsche Wahl triffst, dann hast du durchaus
ein Problem. Also SHA-1 oder FD5 sollte man nicht
nehmen, sondern SHA-256, oder?
Genau, SHA-2256 oder eine
SHA-3-Variante oder was anderes. Aber
eigentlich willst du gar nicht, dass der Entwickler sich
darum Gedanken machen soll. Der Entwickler soll gar nicht
sagen, okay, ich nehme SHA-1, sondern der Entwickler
soll eigentlich sagen, okay, ich nehme eine fertige
Bibliothek. Und dafür gibt es dann in Python
zum Beispiel die neue
Passwortbibliothek, oder es
gibt Bcrypt.
Und da
muss ich mich gar nicht drum kümmern. Ich weiß gar nicht, die
Passwortbibliothek heißt, glaube ich, Secret?
und da muss ich halt nicht mehr drum kümmern.
Also da wird halt die Wahl für dich getroffen
und das macht es für den
Entwickler natürlich
besser, weil der Entwickler keine Entscheidung
treffen muss. Wenn du ein System groß
zertifizieren musst, dann musst du wahrscheinlich trotzdem irgendwo eine Entscheidung
treffen, weil da andere Leute drüber schauen wollen,
aber für so die Wald- und Wiesenanwendung,
die einfach mal von
vielleicht einem kleinen Team entwickelt wird, ist das
sicherlich eine bessere Option, wenn die
keine kryptographischen Entscheidungen treffen. Also
und nicht mal die Entscheidung treffen, welche Algorithmen sie verwenden, sondern vielleicht nur noch sagen,
ich möchte ein bestimmtes Sicherheitslevel haben. Das ist ja auch immer ein
Trade-off, dass ich sage, okay, ich kann das zum Beispiel mehrfach hintereinander hashen und dann
kann man das halt bei dem Passwort, dauert es auch länger, das
rauszufinden, weil ich halt, wenn ich ein Testpasswort
habe, muss ich das ganz oft hashen, um das Zielpasswort zu finden, aber das ist
halt auch ein Problem, was, auf deiner Seite, weil wenn du das halt
sehr oft hasht, dann dauert es natürlich ein bisschen länger.
Und du möchtest ja nicht,
dass dein Service plötzlich eine Minute braucht,
wenn sich ein Nutzer einloggt, weil dein Passwort
irgendwie eine Million mal hasht oder sowas.
Das ist bei uns auch mal so ein schönes Ding
bei Tests, wo man halt
Zeit sparen kann.
Die Passwort-Hash-Funktionen sind ja
genau die, sie sind ja
genauso gestaltet, dass sie möglichst langsam sind.
Und
genau, da will man dann vielleicht noch mal
MD5 verwenden oder sowas in der Art,
weil das ist halt dann deutlich schneller.
und man legt ja, wenn man jetzt ein Test-Suite durchlaufen lässt, oft ganz viele Nutzer an und das kann Dinge deutlich beschleunigen.
Sehr, sehr interessant. Da fallen mir ganz viele Sachen, glaube ich, noch zu ein, was man da so macht mit Vulnerabilities und Disclosure und all diesen Dingen.
Ja, PIX tatsächlich. Und die Frage, wollen wir ein Standard-Lib-Modul vorstellen?
Ich finde, der ist gerade ein Secret-Modul.
Ja, das ist super.
Kennst du dich mit Siegwitz auch?
Nicht im Detail.
Schade.
Ich dachte, ich kann dir die Verantwortung von mir schieben.
Ja, aber wenn du dich damit beschäftigt hast,
dann mach das doch.
Nein, nein, nein.
Nein.
Was wäre denn euer Blick?
Ja, also meiner
wäre jetzt
tatsächlich
youtube.dl
Wie kommst du denn da drauf?
Ja, ich habe damit in letzter Zeit
im letzten Jahr viel gemacht. Ich habe das so,
ich habe es früher vielleicht ab und zu mal benutzt, um irgendwie mal
Videos runterzuladen, die ich gerne
auf der Platte hätte. Also genau
dafür ist es ja da, aber
im letzten Jahr habe ich das auch viel
sozusagen
in Projekten verwendet, weil es
darum ging, wie man da Videos irgendwie
automatisch verarbeiten kann und so.
Ja, und
es ist ein sehr, sehr schönes Tool.
Es ist halt, genau, ja, aber ich glaube,
und Philipp kann das deutlich besser erklären, was das eigentlich
so tut und was so ein bisschen...
Ich habe auch so einen kleinen politischen Vorfall
beim YouTube.de, den müssen wir auch noch
natürlich erzählen.
Der Name von YouTube.de ist stark irreführend.
Das hat angefangen als ein
Download-Tool nur für YouTube
und als ich das damals übernommen habe,
da wurden glaube ich
noch Vimeo unterstützt und noch ein, zwei andere Seiten,
aber als ich das
abgegeben habe, also mittlerweile entwickle ich auch schon
länger nicht mehr daran,
oder entwickle schon ein bisschen dran, aber bin halt nicht mehr der Chef-Maintainer
oder Wappen-Maintainer und mittlerweile unterstützt es über 1000 Dienste.
Das heißt, du kannst es auch auf irgendeine komische Anime-Seite laufen lassen oder auf die ARD-Audiothek
oder auf archive.org
oder die CCC-Kongress-Seite und es wird dir halt immer ein ordentliches Video
zurückliefern. Du kannst natürlich auch sagen, ich möchte verschiedene Konfigurationen
also ich möchte das Video sortieren oder möchte direkt eine Playlist runterladen
und YouTube.dl ist komplett in Python geschrieben,
das ist vielleicht auch ein bisschen besonders, weil es eine Python-Anwendung ist,
die gar keine Dependencies hat.
YouTube.dl verlangt nur die Standard-Diplotik und das auch sehr, sehr flexibel.
Also bis vor kurzem noch konnten wir zwischen Python 2.6,
ging noch bis Python 3.8, wurde alles unterstützt,
hat sehr, sehr viele Benutzer
und ist halt hoffentlich ein super flexibles Tool,
das man auch sowohl programmatisch als auch als Commodore-Zeitanwendung verwenden kann
um schnell was runterzuladen. Viele
grafische oder serverseitige Programme
verwenden auch intern YouTube.de
um halt Videos runterzuladen aus
verschiedensten Quellen. Typischerweise, also
oft YouTube, aber kann auch was ganz anderes sein.
Und der Vorfall,
der halt passiert war, ist, also
vor dem öffentlichen Vorfall
bin ich und ein Host da angeschrieben
worden von einer deutschen Anwaltskanzlei,
die Rush heißt die,
die sind, wenn man nach denen googelt,
ich hab sie erst natürlich nach denen gegoogelt, als ich
das schreiben bekommen hab, sieht man, okay, die
für schickende malen Abnahmen wegen Tauschbörsenvorfällen oder sowas.
Irgendwie bekannt für den Namen, ja.
Und die haben halt da typischen, also ich kann das jetzt nicht so beurteilen, ich bin kein Jurist,
aber die haben ein sehr langes Papier geschrieben, wo sehr große Drohungen drin standen,
was für mich eigentlich jetzt irrelevant ist, weil ich bin ja nicht mehr in ein Projekt involviert,
also ich habe noch gelegentlich Contributions geleistet, aber auch nichts mehr zu YouTube,
sondern nur noch zu ganz anderen Seiten.
und dann haben die wohl aber mitbekommen, dass YouTube.dl auf GitHub gehostet ist.
Und dann an die amerikanischen, ja, richtig technisch drauf waren sie nicht,
aber gut, sie sind auch Rechteinwälte, sind keine Programmierer,
haben halt nur so ein bisschen was gefunden und haben auch viele Sachen nicht richtig verstanden.
Also das ist halt, ja, kann man halt nicht machen.
Und dann sind sie halt zu den Amerikanern gegangen und die RIA
und die hat dann halt GitHub eine Notiz geschickt, eine DMCA-Notiz, dass sie halt die YouTube.js sperren sollen.
Und davon haben die meisten Leute erst mitbekommen, dass irgendwas nicht stimmt.
Also diese Vorgeschichte, das war schon Wochen davor in Deutschland und auch andere Sachen waren Wochen davor,
aber was die Öffentlichkeit mitbekommen hat, war okay, GitHub ist gesperrt.
Und GitHub ist freundlicherweise für das YouTube.js Projekt, das haustet die Downloads.
und die Programmiersprache Python.
runterladen kann. Also der Stein des Anschlusses war nicht die normale YouTube-Downloads, sondern die
YouTube-Musikvideos. Das war das Problem, was die
Rechtsanwälte bemängelt hatten. Und was jetzt aber passiert ist,
dass glücklicherweise die IFF, die Electronic
Frontier Foundation, in den USA die Verteidigung
übernommen hat von YouTube.dl und da eine Gegennotiz geschickt hat und jetzt auf
GitHub wieder alles da ist und GitHub das wieder hostet und das Projekt wahrscheinlich
und ich bin jetzt ganz normal weitergelaufen und es alles wieder klappt.
Ich war da auch gar nicht so viel involviert, ich bin halt nur von zig Leuten angeschriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenriebenrieben
wo das die IFS sich darum gekümmert hat.
Und auch über die Unterstützung von GitHub
und zuletzt wollte ich vielleicht auch erwähnen,
es gibt einen deutschen Hoster, der daran beteiligt ist,
das ist Uberspace,
da kann man super leicht
seinen eigenen Dienst hosten und
die sind auch rechtlich
angeschrieben worden, auch von den Rechtsanwälten
rasch und die haben sich
auf eigene Kosten, haben die ihre eigene
Verteidigung organisiert. Die hosten halt nur die Webseite,
die hosten nicht das Programm selber
aber auch das fand die Rechtsanwälte
verwerflich. Glücklicherweise ist
und Jochen unterhalten sich über die Programmiersprache Python
und die Programme.
Ja
Aber ja, also ich glaube
auch eher, das ist der, also
sagen wir mal so, das hat dem Projekt wahrscheinlich doch
eher stark genützt
das hat jetzt nochmal sehr viel Aufmerksamkeit
bekommen und hat
der Streisand-Effekt voll zugeschlagen
Ja, auf jeden Fall
Also ich bin tatsächlich froh, dass es mittlerweile soweit ist, dass
solche Sachen nicht mehr einfach so dann weggeblockt
werden, sondern dass die Leute sich anfangen
mit solchen Dingen auch juristisch dann auszukennen
und dass diese komischen Kanzleien
oder wie man ja auch immer das dann nennen soll
langsam aber sicher gegen die Wände rennen.
Ja, ist natürlich als Open Source
Programmierer. Ich bin halt nur eine Person.
Ich habe da keine
große juristische Know-how.
Also ich kann das halt technisch beurteilen,
was im Gesetz steht. Aber offensichtlich
gibt es auch einige Gerichte, die
das sehr flexibel
ausgelegt haben, was da im Gesetz steht.
Also das Landgericht Hamburg hat gesagt,
okay, im Wesentlichen,
da steht, dass es
eine
eine technisch
durchsetzbare
Verschlüsselung oder Verschleierung geben muss
und das hat er einfach interpretiert als, ja, das
hört sich aber komisch an, das interpretieren wir jetzt anders
und jetzt haben sie es gesagt in dem Urteil,
eigentlich alles, was ein normaler Benutzer nicht machen kann,
ist verboten. Das heißt,
es gab ein
vergleichbares Urteil und da hatte jemand argumentiert,
okay, das kann man aber auch in den Browser-Tools machen
und da hat das Landgericht Hamburg gesagt, nee, das ist
aber kein normaler Benutzer nicht,
weil das ist nicht im Internet Explorer drin oder so.
Und das ist halt eine sehr
fragt über die Argumentation.
Der Jurist hat das dann selber ausprobiert
und dann festgestellt, nee, er kann das nicht.
Ja, genau.
Und YouTube-DLS funktioniert eigentlich
wie ein normaler Browser.
Nicht grundsätzlich unterschiedlich wie Chrome.
Es hat auch der eigene JavaScript-Engine in Python geschrieben.
Ach, äh,
ah, okay.
Naja, stimmt.
Dann kann er ja externe Abhängigkeiten geben.
Das hätte ich jetzt auch gedacht, dass das vielleicht irgendein
Headless-Browser-Engine
noch mit dabei ist oder so.
Gar keine Python-Abhängigkeiten.
Klar, wenn ich jetzt normale
Python-Anwendungen schreibe, dann verwende ich Abhängigkeiten.
Wir haben ja eben gerade besprochen, dass es eigentlich gut ist,
wenn ich fertige Bibliotheken verwende.
Aber YouTube.de muss halt auf ganz unterschiedlichen
Systemen laufen. Da gibt es halt Leute, die kommen an mit
Red Hat und haben halt, weiß ich,
Python 2.6 oder bis vor kurzem noch
Python 2.5 haben die noch drauf
oder Python 2.4, keine Ahnung.
Und da kannst du halt nicht darauf vertrauen, dass die auch überhaupt
irgendwas installieren können. Die sind halt froh,
wenn die ein Binary bekommen.
und das geht ja in Python relativ gut. Man kann die Datei einfach als ZIP verpacken und dann ist es ausführbar.
Und man kann es auch mit YouTube.acx freeze verwenden, um halt auch eine Excel für Windows zu erzeugen
und das läuft dann wirklich überall ohne das man es installieren muss.
Und ich glaube das ist auch ein Grund für den Erfolg dieser Software, dass man das halt einfach so laufen lassen kann,
dass man sich keine Gedanken machen muss, auch wenn das System komplett zerschlossen ist als Python-Entwickler.
Das klappt immer. YouTube.acx braucht nur eine schnelle Politik.
Sehr gut, sehr gut
Ja, es klingt sehr spannend
Ja, ja, mir war das auch gar nicht so klar
dass man da tatsächlich irgendwie die meisten Seiten
mit bedienen kann
und dann, ja, ich
hatte früher auch immer gedacht, das wäre eigentlich für
YouTube, aber
ja, es ist wirklich sehr, sehr praktisch, es nimmt einem auch viel ab
also ich benutze das jetzt halt
immer so
quasi um halt
automatisiert von allen möglichen Seiten Dinge runterzuladen
und das ist halt sozusagen die Schnittstelle
die YouTube-DL ist sozusagen meine
API zu Seiten, die Videos
haben, um das Video
da rauszukriegen.
Genau.
Ja, Pix.
Also ich würde dieses Mal gleich Python Date
Tutorial picken, weil irgendwie das ein schöner
Rapper ist, über wie man
Datumsangaben irgendwie machen kann.
Verschiedene Zeitkalendern mit Deltas
irgendwie. Ich wollte es mal erwähnt haben,
das stand irgendwo noch auf meiner Liste, hat jetzt nicht den Topic gar nicht
mehr so viel zu tun.
Ja, Datutils
ist tatsächlich auch sehr nett
also ich, das Datutil
Parse, das Parse, erstaunt
nicht viel, also dem kann man irgendwelche Strings
geben, die so, also man hat ja oft irgendwie
sieht man dann irgendwo so ein String
mit Datums und Zeitangaben drin und dann
denkt man sich, oh, wie waren
jetzt nochmal die Format-String-Dinger
wie hießen die nochmal alle?
Und dann nimmt man Datutil Parse
und dann passt das automatisch
aber dann muss man irgendwie noch, ich glaube
das geht aber auch irgendwie, man kriegt auch aus dem
DTutorial Pass dann raus, wie der
Formatstring eigentlich sein müsste.
Und andere Kalender. Genau, weil
DTutorial Pass sollte man nicht
über größere Datenmengen
irgendwie aufrufen, weil das wird dann halt sehr langsam,
wenn man das Inhaltschleife verwendet, aber
um rauszukriegen, wie man das denn jetzt eigentlich
aufpasst und dann halt an den Formatstring zu
kommen, den man dann letztlich verwendet
für Strip-Time oder so,
das ist super.
Und dein Pickoffen?
Hatte ich doch schon.
und Jochen unterhalten sich über die Programmiersprache Python
oder sowas wie Bequipped.
Da haben wir das auch noch reinge...
Ja,
schön, dass ihr alle dabei seid. Danke, Philipp, dass du
Zeit gefunden hast für uns. Ja, voll gut.
Eine sehr interessante Episode.
Ja, auch für mich sehr interessant.
Ja, vielen Dank, dass ich dabei sein durfte.
Ja, mir geht's auch.
Wenn ich noch einmal ganz kurz Werbung machen darf,
bei Poxine suchen wir immer Python-Entwickler.
Oder was immer,
aber aktuell suchen wir auf jeden Fall Python-Entwickler
oder auch Leute, die mit Java oder mit
und Javascript arbeiten, speziell mit React.
Also wenn ihr ein guter Entwickler seid, vielleicht sogar im Raum Düsseldorf
oder auch nur ganz grob in NRW irgendwo,
dann meldet euch bei Vaboxine.
Box zu programmieren.
Die Dienste rund um die Tony Box zu programmieren
macht sehr viel Spaß. Es ist total
toll zu wissen, okay,
jede Nacht
gehen Tausende oder Millionen
Kinder mittlerweile mit der Tony Box
ins Schlaf und wir machen gute Dienste,
die hoffentlich den Eltern
das Leben einfach machen
und dafür sorgen, dass die Kinder gute Geschichten
hören. Das war die erste Werbeanzeige
am Python Podcast.
Ja, aber ich kann nicht nur...
Könnt ihr rausschneiden.
Nein, nein, nein, das finde ich super.
Das ist ein schönes Projekt hier aus der Gegend.
Ja, alles klar, dann würde ich sagen.
Vielen Dank, Philipp.
Bleibt uns gewogen, egal wann ihr uns hört.
Schaltet wieder ein.
Morgens, mittags, abends, tags, nachts.
Zum Einschlafen ist auch immer super.
Liebe Grüße und bis zum nächsten Mal.
Tschüss.