Wenn du darüber nachdenkst, in welchem System du dich tagtäglich anmeldest und welche Daten du regelmäßig über das Internet schickst, was würdest du sagen, wenn viele deiner sensiblen Daten seit 2 Jahren potenziell in falsche Hände geraten konnten? Du sagst, es wäre fatal, fatal, richtig und genau mit dieser Information wurden Menschen weltweit im Jahr 2014 konfrontiert, wie das passieren konnte, das erfährst du in dieser Folge.
Coating Boys, Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Herzlich Willkommen zur neuen Folge ist Coding Buddies Podcast. Schön, dass ihr wieder eingeschaltet hast, deine Gastgeber wie immer meine Wenigkeit Tino und auch der fantastische Fabi, den ich hier schon im Bildschirm sehe. Fabi, Grüße dich was geht ab? Tino, Was geht? Schön, dass wir alle wieder zusammengefunden haben zu einer neuen Folge.
Es geht, es geht wieder los. Ja, es geht einfach nahtlos weiter, Woche für Woche und wir haben immer noch richtig Bock. Also du siehst auch richtig motiviert aus, deswegen habe ich umso mehr Bock auf die heutige Folge, weil ich habe ein wirklich geiles Thema mitgebracht, wirklich ein wahnsinnig geiles Thema und zwar ich bin voll koffein, wir können. Loslegen. Okay also, das heißt Kaffee, hast du am Start, kann losgehen. Eigentlich nur ein. Ich habe heute schon Pause getrunken. Pass auf.
Ich möchte mit dir heute eine neue Folge Big Fails der Software Entwicklung machen. Sehr geil und ich will jetzt auch nicht direkt spoilern um welchen Bug es sich handelt, aber wir. Gehen zurück in das Jahr 2014 und geben dann noch einen kleinen Blick in die Vergangenheit bis ins Jahr 2011 sogar zurück und möchte mit dir, ich sag's doch, es geht um den Heartbleed Bug, wir gucken uns heute den Heartbleed Bug an, der einfach Apps berühmt ist.
Und ich hab richtig Bock das mit dir mal zu analysieren und deswegen Liebe zu lieber zu sei. Gespannt, das wird ne geile Folge ist n absoluter Klassiker, auf jeden Fall muss ich ganz ehrlich sagen, also der ist mir auch schon n paar mal über den Weg gelaufen, ist aber trotzdem immer wieder spannend.
Also das ist ja im Endeffekt wirklich n Bug, der damals also als er aufgetreten ist beziehungsweise entdeckt wurde man ja schon davon reden konnte, dass er so fast das Internet zerstört hat, wenn man es richtig dramatisch ausdrücken möchte, weil ja einfach sehr, sehr viele davon betroffen waren und ich weiß gar nicht genau, ob ich das auch so sehen würde, wahrscheinlich schon, weil im Endeffekt ja schon so ein bisschen. Der Glauben an das Internet
untergraben wurde. So würde ich, so würde ich es ausdrücken. Ja, man hat auf jeden Fall das Vertrauen ein bisschen verloren. Genau, und was du meintest mit der fast das Internet zerstört hätte, man muss halt sagen, dass er einfach ein enorm hohes Potential hatte Schaden zu verursachen. Aber wie es genau dazu kam? Werden wir an dieser heutigen Folge analysieren und mal so wirklich auseinandernehmen, was auch der Grund war.
Der technische Grund hinter dem Bug finde ich nämlich, ist auch eine super spannende Geschichte und. Deswegen würde ich dich bitten, magst du vielleicht einfach mal so bisschen unseren Rahmen schaffen, indem wir uns bewegen und mal so? Im ganz allgemein erklären, was da so vor sich ging. Ja, also erstmal wie gesagt, es war ja ein also dieser Bug hat jetzt über 2 Jahre existiert, ohne dass er überhaupt wahrgenommen wurde.
Ne, also der war einfach. Musst du dir vorstellen, es war kann man ja schon mal so n bisschen spoilern, ne gewisse Art von Sicherheit Lücke die 2 Jahre unentdeckt blieb, das heißt wenn du ein Angreifer gewesen wärst und du hättest das gewusst, dann hättest du 2 Jahre lang. Angriffsvektor nutzen können und das ist echt schon richtig krass. Und das.
Ist eine lange Zeit, ja. Und dieser Bug, der wurde auch so, also der, der war deshalb auch, weil er eben so kritisch war, richtig populär geworden, weil ich glaube, das war der erste Bug so in der Geschichte der Bugs, der auch wirklich so ein eigenes Logo und einen eigenen Namen bekommen hat. So später wurde. Das ja öfter mal so wieder. Also das war dann so Trend, dass es so gehandhabt wurde. Aber es war auch ein bisschen dem geschuldet, weil die.
Bug so kritisch war und auch sehr viele Leute betroffen waren, musste. Man das ja irgendwie publizieren, irgendwie in die Öffentlichkeit bringen. Ja, das kann man ja nicht untern untern Tisch kehren unter den Tisch oder unter den Teppich, was sagt man? Alles okay und deswegen wurde halt dieses Logo, diese dieses nette Logo wurde sozusagen erschaffen, damit es auch ein medienfreundlicheres Gesicht bekommen hat als es.
So nach außen getragen wurde, und das fand ich auf jeden Fall total interessant, einfach das mal so diesen Fun Fact zu hören, weil das ist so nett, eine nette Zeitnote. Ich finde es, was man auch mal so da hinterfragen könnte, ist mal angenommen, das wird jetzt in den Medien gezeigt, ob sich da. Viele dachten so, oh mein Gott, das ist krass, oh, das ist ne krasse Sicherheitslücke gewesen oder ist aktuell, falls noch nicht gefixt war oder sich denken soll, ja. Mir egal.
Weißt du, so ich? Glaube also so Normalos, nicht IT ler mal so als Normalus bezeichnet. Ob die sich dachten OK krass oder sich dachten ja ist mir doch egal. Zeig mir die fußballergebnisse. Ich glaube, da gibt es so und so wie wie er heutzutage auch ne. Also auch wenn heute was auftritt glaub ich gibt es die Leute die sich denken oh mein Gott das ist richtig krass und andere die sich denken langweilig irgendwas mit Computern. Weil ich.
So aber die Frage. Die Frage, die wir uns jetzt eigentlich mal stellen wollen ist, wieso war dieser Bug eigentlich so gefährlich und warum hat man da jetzt so n riesen Wind drum gemacht? Warum machen wir jetzt noch mal so n Wind drum ja. Warum sind wir so gehyped und finden das so spannend, dass der war? Ja, schafft doch mal bitte den Frame, in welcher Welt wir uns jetzt bewegen, um das mal einzuordnen.
Genau. Also wir müssen erstmal dazu einen kleinen Exkurs in die Internet Kommunikation machen und zwar hat dieser Heartbleed Bug hat was mit dem TLS Produkt zu tun und dieses TLS Protokoll dient dazu.
Also es ist ein kryptographisches Protokoll was dazu dient um Kommunikation. Wie zum Beispiel auch Kommunikation im Internet einfach zu verschlüsseln, das heißt rein theoretisch, wenn du Daten über das Internet verschickst, hättest du ja rein theoretisch die Möglichkeit, diese Daten einfach zu lesen und wenn diese Daten nicht verschlüsselt sind, würdest du ja alles im Klartext lesen können und es ist ja weiß ich nicht, kommt jetzt ein bisschen
auf die Person drauf an, aber ich würde jetzt mal so weit gehen, dass man, dass jeder wahrscheinlich irgendwie so bestimmte Geheimnisse hat und die erzählt man ja auch nicht
jedem einfach. So ne also zum Beispiel sowas wie Passwörter. Jetzt im Internetgenre ist ja ein gewisses Geheimnis, was du ja gerne für dich behalten möchtest, ne und diese dieses TLS Protokoll wird eigentlich fast überall verwendet ne also du hast zum Beispiel allein wenn du dich irgendwo bei Social Media irgendeinem Social Media Kanal einloggst. Wenn du bei Amazon oder anderen E Commerce Shops, shoppst, Shops, Shops, Shops. Oder Shops. Oder halt auch online Banking
machst. Also du möchtest ja auf gar keinen Fall, zumindest kenne ich eigentlich jetzt keine Person, die das gerne möchte, dass man irgendwie, dass das Risiko liebt, aber dass das eigene Passwort vom eigenen Online Banking irgendwie an andere Personen weitergeht, so und Heartbleed, dieser Heartbleed Bug ist jetzt kein Bug oder kein Designfehler dieses Protokolls, also dieser ist jetzt genau von
TLS selbst. Weil das ist ja im Endeffekt nur ne Rahmenrichtlinie, wie man sich in der Kommunikation verhalten soll ne, sondern dieses Protokoll, also dieses diese rahmenrichtlinien wie man kommunizieren soll, das wurde umgesetzt, also implementiert. Durch eine Open Source Software, genannt Open SSL, so da haben bestimmt einige, kennen das vielleicht ein andere vielleicht nicht. Und diese Software ist im Endeffekt bis heute weit verbreitet, ja damals auch heute auch.
Nutzt eben dieses Protokoll. Zur Verschlüsselung bei einer Kommunikation. Und das wird halt, es ist frei zugänglich, weil es ist ja open Source und es wird eben auch von vielen genutzt. Also zum Beispiel wird Open SSL auf Linux Systemen sehr sehr häufig verwendet, ja und Linux Systeme sind ja ein großer Bestandteil oder Linux Server sind ja ein großer Bestandteil im Internet, also die mit dem Internet verbunden sind. Und genau so.
Diese Sicherheit, die da geherrscht hat, darauf haben sich halt eben auch sehr, sehr viele Leute verlassen und gesagt Okay, pass auf, da wird meine Daten werden verschlüsselt, alles super, ich bin sicher, ich kann ordentlich im Internet kommunizieren, ohne dass irgendjemand meine, ich nenne es jetzt nochmal Geheimnisse irgendwie lesen kann und genau.
Das Ding ist. Dass, wie gesagt, es hat ja nichts mit TLS selber zu tun, sondern dieser Bug hat ja in dieser Software gesteckt, am Ende, der kam ja irgendwann in die Software rein, in diese Open assl Software und. Und damit wir aber erst mal verstehen können, ja wie diese. Wie dieser Bug überhaupt auftreten konnte, müssen wir einmal auch noch mal ganz kurz gucken.
OK, wie funktioniert denn ein, die die Kommunikation im Internet zwischen einem Client, also ein Client ist ja zum Beispiel ein Webbrowser wie Firefox oder so und einem Server und das kannst du ja mal kurz einmal vielleicht umreißen. Ja, also was ich dazu noch anmerken möchte, bis zu dem Punkt. Dass diese TLS das TLS Protokoll ist ja nicht quasi so in. Auf dem Papier schon eine 10
gewesen. Klar ist es sowieso die erste Version des Protokolls, aber es hat ja eine lange Historie gehabt, es gab ja vorher schon die SSL Protokolle in verschiedenen Versionen, darauf hat denn TLS aufgebaut, ist optimiert, verbessert, das heißt man war eigentlich schon an einem Punkt, wo man von Sicherheit sprechen konnte, das waren ja nicht so protestypen. Sondern man hatte eigentlich wirklich ne gute Basis, auf die man sich auch verlassen hat,
weil du ja meintest. So, man hat diesen Glauben daran verloren zu der Zeit oder man sprach davon, dass Leute den Glauben dran verliert, weil es ja wirklich etabliert war und jetzt ist die Frage, wie kommt dann? So ein kritischer Bug in dieser Open SSL Software wie du gesagt hast, rein die quasi dieses Protokoll implementiert und.
Das lag halt daran. Dass natürlich so ne Protokolle sich auch weiterentwickeln, ne, weil wie gesagt, es gab ja auch vom SSL Protokoll schon ne Einser zweier dreier Version und genauso sollte sich ja auch das TLS Protokoll weiterentwickeln und dafür gab es halt, weil du meintest wie sieht so diese Kommunikation aus, da gab es halt nämlich das Problem wenn ich jetzt quasi als Client, also mit meinem Rechner zu Hause eine Verbindung auf so einer Website, also zum Serveraufbau im
Internet weiß. Ich irgendwas googeln möchte ist. Aber ein klassisches Beispiel, das macht einfach jeder, glaube ich.
Dann wird natürlich diese Verbindung aufgebaut und verschlüsselt und das kostet halt ja Rechenaufwand und Ressourcen und man hat halt sich überlegt, wie kann ich denn diese Verbindung effektiv aufrechterhalten ohne immer Daten auszutauschen, weil man kann sich das so vorstellen, man baut diese Verbindung auf, tauscht diese Daten aus und dann in der Regel ist die Verbindung eigentlich erledigt. Obsolet, weil die Daten wurden ja ausgetauscht.
Aber um nicht jedes Mal wieder diese Verbindung aufzubauen, zu verschlüsseln hat man sich halt überlegt, wie kann ich denn effizient diese Verbindung aufrechterhalten? Ohne ständig Daten austauschen zu müssen oder viel Daten austauschen zu müssen. Und da gab es halt dieses typische Keep Alive Prinzip, das begegnet ja eigentlich in sämtlichen Bereichen wieder und deswegen. Hat man es auch Heartbeat genannt?
Das war das heartbeat Update, dass man gesagt hat okay wir erweitern unser Protokoll um eine Funktionalität. Einem ganz kleinen Datenaustausch zwischen Client und Server, was im Endeffekt nichts anderes aussagt. Der Client meldet hey, ich bin noch da und der Server antwortet sinngemäß Ich bin auch noch da cool, wir haben immer noch eine Verbindung, weil du halt sonst keine Gewährleistung hast ob die gegenüberliegende Seite noch da ist. Das ist ja. Ein ganz simples.
Problem eigentlich. Was aber gelöst werden muss. Mal angenommen man telefoniert also wir beide würden jetzt telefonieren und wir sehen uns nicht in dem Sinne, sondern ganz klassisches Telefonat, keine Videocall, ne. Und wir würden reden und ich würde auf einmal nicht mehr antworten. Ja, dann würdest du ja nicht wissen oder oder beziehungsweise noch besser wir wir, wir sagen
einfach, wir schweigen jetzt. Ja. Und wie weißt du, ob ich wirklich noch am Telefon bin oder wenn ich auflege, ist die Verbindung getrennt okay, aber wenn ich einfach nicht mehr antworte. Woher willst du wissen, ob ich wirklich noch am Telefon bin oder es auf den Tisch gelegt habe und eigentlich gerade im Kühlschrank bin oder mir einen Kaffee ziehe?
So weißt du das ohne zu kommunizieren, das ist ja das witzige an der ganzen Geschichte und das Ding ist, wenn man jetzt sagt, weil du meintest ja, diese Verbindung wird ja aufrechterhalten so lange, weil man kann sich das ja auch so vorstellen, ein normales Telefonat funktioniert ja auch so, dass ich zum Beispiel, ich rufe dich an, Tino, Na, wie geht's dir und du so, ja, mir geht's super, und dann sagen wir auch nicht okay wir legen auf dann.
Rufe ich dich wieder an. Und was hast du heute so gemacht? Ja, ich war heute Bouldern, ja super okay dann legen wir wieder auf, also dass man sozusagen nur diese eine Frage und Antwort absetzen und dann auflegen und wieder anrufen, ach was ich noch wissen wollte, was machst du morgen, du antwortest, dann lege ich auf und da kann. Man ja schon relativ schnell sehen, dass diese Zeit, die du zum Auflegen. Zum neu die Telefonnummer eintippen, dann tut es, dann geht jemand ran.
Diese Zeit, die willst du ja ne über im übertragenen Sinne nicht bei der serverkommunikation Client Server Kommunikation jedes Mal wieder haben. So genau. Weil das das Thema ist. Ja, auch das kann man auch gut an dem Telefonbeispiel bringen. Angenommen du wärst noch am Telefon, dann ist ja deine Leitung blockiert, dann kann ich in der Zeit kein anderer Anrufen, aber du weißt eigentlich gar nicht, ob du wirklich noch mit mir telefonierst, ob ich jetzt je Moment wieder.
Als dran bin und was sage oder weiter schweige und du hängst am Telefon und denkst ja hm, sagt er jetzt noch, was sagt er nichts, sind wir fertig. Eigentlich haben wir uns nicht nicht wirklich verabschiedet, ich weiß nicht so wirklich, weißt du und das blockiert dich aber in der.
Krankenwagen rufen irgendwann. Und das blockiert dich ja derzeit für andere Telefonate und so ist es ja auch beim Server. Er kann ja ne gewisse Anzahl an Verbindungen entgegennehmen und aufbauen und wenn du jetzt anfängst, da diese ganze Verbindung zu blockieren, dann kann kein anderer sich mehr verbinden und das sind halt alles Gründe warum dieses Keep Alive bzw Heartbeatprinzip in sämtlichen Bereichen oft in der Kommunikation halt einfach
existiert. Um zu sagen, Pass auf, wir müssen nicht die ganze Zeit Daten austauschen, aber in einem festen Zyklus möchte ich doch bitte noch wissen, ob du noch da
bist und du mir antwortest. Und da gibt es halt unterschiedliche Namen. Es gibt, manche nennen es auch Ping Pong Prinzip, das heißt einer sendet ein Ping und der antwortet also der andere antwortet mit Pong gibt es ja 1000 Sachen und Heartbeat ist halt auch sehr gängig, einfach nur sinngemäß, dass der Herzschlag noch gefühlt wird, so wie sind hier noch da beide. Und ja, aber. Das ist ja beim Telefonat genau. Also das Kennwort kennt man ja
wirklich auch beim Telefonat, also wirklich. 1 zu 1 weil, wer hat das nicht schon mal gehabt? Man telefoniert, einer der Telefonierenden ist irgendwie gerade beschäftigt und antwortet nicht direkt auf die Frage und dann kommt es was noch da genau. Ja, und genau das ist es ja. Und dann sagt der andere natürlich ja, sorry, was hast du noch da noch mal genau so und das ist ab sofort Liebe zu Liebe zuhören, wenn dir das übern Weg läuft, das Problem dann immer Ping und Pong.
Warten, bis ein Pong zurückkommt. OK, kleiner Spaß am Rande. Auf jeden Fall wurde denn dementsprechend das TLS Protokoll erweitert um diese Heartbeatfunktionalität. Und zwar wurde das dann auch in der Open SSL Library implementiert. Das hat funktioniert. Es hat auf jeden Fall funktioniert, die Implementierung, da gab es nichts auszusetzen und das ist auch der Grund, warum mit diesem Update der Bug in die Software gekommen ist.
Aber erst 2 Jahre später gefunden wurde, weil es war rein funktional kein Bug, das heißt also es hat funktioniert, das heartbeat Signal. Trotzdem. Gab es ja jetzt diesen Bug als Sicherheitslücke, so gesehen. Also das war jetzt kein Fehler in der Implementierung, sie war, sagen wir mal, einfach nicht vollständig, ja richtig, und magst du da vielleicht mal drauf eingehen? Genau also wie das Ganze jetzt ungefähr. Also ich versuch das jetzt mal immer grob, ganz, ganz einfach
verständlich zu erklären. Und zwar ist dieses heartbeat Signal was vom Client gesendet wurde um halt eben zu prüfen, sind wir noch da haben wir noch ne Kommunikation. Wurde gesendet und das können wir uns so vorstellen, dass einfach ein Text gesendet wurde, wie zum Beispiel der Text heißt jetzt XYZABC, was auch immer ne, also sagen wir mal nur, dass man sich es einfacher vorstellen kann, XYZ wird gesendet.
Und zusätzlich ne, also in der Programmierung ist es ja auch so, dass man immer sehr sehr genau ist und das ganze vielleicht noch mal checkt oder was auch immer, wurde dazu noch gesagt, OK pass auf, ich sende dir jetzt den Text XYZ und der hat die Länge 3 so und der Server hat dann diese heartbeat Nachricht bekommen vom Client und hat sich gedacht okay ich krieg hier gerade die heartbeat Nachricht mit dem Inhalt XYZ die Verbindung bleibt offen da werde ich doch mal den Client
antworten und werde ihm genau diese Nachricht eben auch zurücksenden. Er weiß, OK, das ist jetzt auch unser kleiner Handhack hier. Und sagt, OK, du bist noch da und ich möchte dir mitteilen, dass ich auch noch da bin und sende dir das XYZ zurück. So oder Abigail, was auch immer, nimm was du möchtest, ne soeben dieser spezifische Text.
Genau, du sendest quasi genau den gleichen Text zurück, damit der Client weiß, OK, es ist auf jeden Fall die heartbeat Antwort Antwort, dass der die Gegenstände noch am Leben ist, weil es ja die gleiche Nachricht ist, die ich. Gesendet hab ne, also dadurch kann ich mir sicher sein, dass die Gegenseite auch auf meine Anfrage, also spezifisch auf meine Anfrage reagiert hat. Deswegen macht man das mit dem Text. Wie sah denn das jetzt n bisschen technischer aus? Ja, guter Punkt, da wollt ich
nämlich gerade drauf eingehen. Lass uns da mal n bisschen tiefer eintauchen wie die technische Umsetzung aussieht. Also im Prinzip hat das Protokoll. Eine Nachricht, ein Nachrichten, also message Format vorgegeben, wie quasi so eine heartbeat Nachricht codiert sein muss.
Das heißt, man hat halt so verschiedene Felder gehabt, die es auszufüllen galt, um dann ne gültige Nachricht, dass man sagen kann, laut dem TLS Protokoll ist das eine gültige heartbeat Nachricht. Ist es wichtig, dass die halt
auch dem Protokoll entspricht? Deswegen musste man als Client die dementsprechend aufbauen, als Server natürlich genauso und das sah folgendermaßen aus, dass man gesagt hat, OK, wir haben erstmal ein Byte, was quasi belegt ob es sich um eine Anfrage. Oder eine Antwort handelt. Also im Prinzip stand da codiert mit ich glaube 1 oder 2 waren die Werte, die da eingetragen werden konnten, dass.
Es sich entweder um ein Request handelt, das heißt ich starte diesen Handshake, nenn ich es mal diesen heartbeat Austausch oder ich antworte, das heißt der andere Wert war denn die Response. Beispielsweise der Client sendet dann ne 1, weil er die Anfrage an den Server stellt und der Server antwortet in dem Feld mit ner 2, weil es die Antwort ist.
Das ist eigentlich ne relativ einfache Codierung gewesen und dafür wurde denn ein Byte in der Nachricht ganz vorne belegt und danach und das ist jetzt ein sehr entscheidender Punkt, gab es ein 2 Byte Feld für die Payload und Payload ist im Prinzip nichts anderes als das was du gerade erklärt hast. Und zwar der Text den ich sende. Das ist im Prinzip. In mein Content der Nachricht sozusagen.
Was auch immer ich schicke, das spielt gar keine Rolle, aber es ist auf jeden Fall meine Nachricht an sich und diese 2 Bytes haben darüber entschieden oder mitgeteilt, wie lang diese Nachricht ist. Du hattest jetzt glaube ich ABC oder XYZ gesagt, also sagen wir mal Länge 3, dann müsste ich in diesem Feld eintragen, dass die Payload die Länge 3 hat. Das hat den Sinn, dass die Gegenseite weiß, weil sie muss ja mit der gleichen Nachricht antworten.
Muss sie ja wissen, was aus der Nachricht, die du gesendet hast, ist jetzt die Pay load und wie lang ist sie und wenn da denn steht Länge 3, also beispielsweise also dann 3 Byte sozusagen. Weiß sie okay die nachfolgenden Bereiche in dieser Nachricht sind die Pay load, also meine Nachricht, die ziehe ich mir raus und antworte, ich antworte einfach genau mit der gleichen Länge zurück, so vom Prinzip vom Protokoll her macht das der absolut Sinn, weil wie gesagt
das. Der Sinn ist ja, mit der gleichen Nachricht zu antworten. Genau, und nach diesem Lenkfeld kam denn die eigentliche Payload, also die Nachricht, und es gab noch n padding Feld, das spielt jetzt für uns an der Stelle nicht so ne große Rolle, nur kurz. Der Vollständigkeit halber. Es ist n Feld wo random Daten eingetragen werden um einfach diesen Security Aspekt zu
bedienen. Weil das halt gewisse Angriffe erschwert, weil du dann es fällt dann halt schwieriger, also schwerer zu erkennen, wo die eigentliche Nachricht liegt. Das heißt, du haust wirklich random Daten rein, die einfach keinen Sinn ergeben und dadurch kannst du halt.
Gewisse aber da hast du eine höhere Sicherheit gegenüber ja feindlichen Angriffen. Sagen wir es mal so ne aus Security Sicht, deswegen macht man das öfter, das heißt eigentlich im Prinzip n rauschen was du da mit rein codierst.
Genau. Und ja, jetzt kann man sich vorstellen, ich bau mir diese Nachricht zusammen, nehme ich noch mal dein Beispiel. Ich sag in dem typfeld sag ich 1, weil ich möchte jetzt n request stellen, dann sag ich Länge 3 wie du meintest in dem Payload Lengsfeld also die Länge des Payloads und dann sende ich die Nachricht ABC an den Server der sieht okay es ist request, das heißt ich schalte auf Response und der baut jetzt genauso seine Nachricht protokollgemäß auf sagt Ok response.
Länge liest der aus 3 Ah. OK, dann guck ich mir jetzt die nächsten 3 Byte an. Ah, da steht ja ABC oder XYZ, was hab ich grad gesagt digger ihr wisst was ich meine und ich antworte quasi ich zieh mir das da raus und antworte genauso. Wieder und schick die Nachricht zurück. Genau mit dem Padding. Wie gesagt, das Padding ist egal, der kann da selbst random Daten reinhauen. Ja ne das ist wirklich auch da ist die Länge auch egal.
Das ist dann halt einfach nur so zusätzlich dazu aber diese ersten 3 Felder sind entscheidend, also der Typ, die Länge der Nachricht und die Nachricht das muss ich halt einhalten und so wieder als Antwort zurückschicken und dann ist quasi dieses heartbeat Protokoll befriedigt sage ich
mal. Jeder weiß, Hey, der gegenüber ist noch da. Ja, ich meine, man kennt das ja auch, wenn du keine Ahnung ein online Formular ausfüllst, dann hast du ja bestimmte Einträge die du machen kannst und du hast bestimmte Restriktionen vielleicht wo du wo es dann heißt hier bitte den Namen, da zum Beispiel dein Alter in das Alter kannst du keine Buchstaben eingeben sondern nur zahlen und vielleicht hast du noch irgendwo ein Freitext.
So Freitext ist dann keine Ahnung wünsche Anforderungen was auch immer ist dann das Padding. Und der Rest ist halt fest definiert. So und jetzt hat es, gab es aber vielleicht so diese Kleine, das kleine Problem. An der Stelle, dass man zum Beispiel, wenn ich jetzt dieses online Formular Ding nehme, dass man sagt, so, du konntest jetzt aber vielleicht auch. In deinen Alter oder was auch immer konntest du jetzt aber zum Beispiel auch.
Buchstaben eintragen. Also du konntest halt ein bisschen schummeln, ne, das ist das, worauf ich hinaus möchte, das heißt? Das ist die eigentliche Sicherheitslücke an der ganzen Geschichte. Du hast die Möglichkeit gehabt zu sagen, XYZ musstest aber nicht zwangsläufig sagen, das ist jetzt mein Text ist 3 lang, sondern du konntest sagen, ich sende xyz und der Text, den ich aber dir schicke ist 100 lang, das bedeutet, dass der Server.
Das XYZ wieder zurückgibt, aber zusätzlich noch 97 weitere Zeichen, die dann im Endeffekt wieder mit zurückkamen und dann ist natürlich die Frage, wo kommen diese 97 Zeichen her, denkt er sich die aus oder was auch immer und da ist es. Im Endeffekt so, dass so ne Anwendung hat ja so n gewissen Speicher der Allokiert wird mit dem so n Programm arbeitet. Mhm oder dann der Server. Ne der solche Requests
entgegennimmt. Also angenommen du hast jetzt beispielsweise Onlinebanking und bei diesem Onlinebanking kommt jetzt irgendwie vorher weiß nicht Lisa Müller und meldet sich an mit ihrem Usern. Meldet sich an mit ihrem Usernamen und ihrem Passwort. So, und diese Daten werden für eine gewisse Zeit in diesem Memory Speicher der Anwendung gehalten und wenn du jetzt aber sagst, ich möchte gerne.
Xyz haben plus 100 weitere Zeichen, dann kann es muss nicht, aber es kann durchaus sein, wenn du Glück hast werden diese XYZ genommen und gleichzeitig noch 97 weitere Zeichen und diese 97 weitere Zeichen, das ist einfach ein Bereich der auf den Speicher zugreift und dann Daten aus diesem Speicher einfach willkürlich rauszieht und wenn du wie gesagt Glück hast als Angreifer kriegst du die Credentials, also Username und Passwort von dieser Möglichkeit.
Und hast dann im Nachhinein halt eben die Möglichkeit, dich beim Onlinebanking von Lisa Müller anzumelden. Und das ist im Endeffekt genau der Knackpunkt, was das eigentliche Problem war in dieser Heartbeat beziehungsweise dann deswegen harte Bleed Message am Ende. Ja. Gut zusammengefasst, weil das ist halt wirklich das gefährliche dabei, weil weil. Wir auch anfangs meinten, es hatte Potenzial. Sehr sehr viel Schaden anzurichten und Potenzial in dem Sinne, wie du so schön erklärt hast.
Es wird halt unerlaubterweise Speicher oder Inhalt des Speichers herausgegeben. An die Anfrage an den Client oder beziehungsweise in dem Fall, dann kann man ja sagen an den Angreifer. Wenn du Glück hast, sind da halt komplett unbrauchbare Daten drin, weil das halt sonst wie geschnitten ist im Speicher, dass du halt keine sinnvolle Zusammenarbeit. Bekommst aber die Chance war da und sie war auch nicht klein, dass du sehr, sehr sensible
Daten da rausschneiden konntest. Dann ja und rausschneiden im Sinne von das hast du ja schon cool erklärt, weil wenn wir es dir noch mal kurz technisch machen, dieses Payload lenkfeld sagt ja, also dann sagst du quasi gehen wir mal wieder vom Client aus oder beziehungsweise jetzt reden wir mal von einem Angreifer, du sagst jetzt dem Server. Was hast du gesagt? 100 Byte und Sendest ihm aber nur Zeichen im Sinne von 3 Byte dann.
Wird er natürlich sagen. Ok, ich habe jetzt diese 3, diese 100 Bytes, die ich zurückgeben muss und er fängt an. Vorne und nimmt den Speicher von 100 Bytes und gibt dir diesen Block zurück. So und 3 Byte davon sind aber jetzt quasi eigentlich nur das, was du ihm geschickt hast. Wie du ja so schön meintest, das heißt du kriegst jetzt 97 sagen wir mal Zeichen oder was auch immer, Daten unerklärlich, unerlaubt dabei. Und der Server agiert nicht dagegen und duldet das.
Und er duldet es immer wieder, weil wie gesagt, das ist dieses heartbeat Signal, das heißt, es ist ja dieses Keep Alive Prinzip, das heißt das ist ja ne ständige Kommunikation, ja. Ne, also das kannst du nicht einmal machen. Dann Finger Cross im Sinne des Angreifers. Hoffentlich ist da was Sinnvolles drin, sondern du kannst ja die ganze Zeit. Quasi immer wieder versuchen da Daten rauszuziehen. Das ist wie, als würde man damals. Kennst du noch die pokémon
Booster Packs? Ja, du hast einen aufgemacht und hast dir gehofft, bitte ne richtig gute Karte, bitte ne richtig gute Karte genau so, aber du musstest die ja kaufen, aber das war ja quasi der Kiosk stand offen für dich, du konntest so viel Booster Packs dir holen, bist du deine goldene Superkrasse Karte hattest. Das ist man.
Muss da gleich und man muss dazu sagen, es ist es handelt ja sich, es handelt sich ja hier nicht um einen Zeitraum von 10 Minuten, sondern um über 2 Jahre, in denen diese Sicherheitslücke offen stand, und jetzt kann man sich langsam vielleicht. Erschließen, wieso man. Wenn man das so mitkriegt, vielleicht so n bisschen den Glauben verloren hat oder verlieren könnte, wenn man denn sagt, Oh OK, also es ist jetzt hier ein wirklich
sicherheitskritisches. System, was ja aber über 2 Jahren Bug hatte und meine ganzen theoretisch meine ganzen sensiblen Daten innerhalb von 2 Jahren absnacken könnte. Also Angreifer hätten das ne verwenden können und das hätte ich genug versuche gehabt, quasi genau und das ist echt krass was
man sagen muss. Also wie gesagt das sind ja so ein bisschen diese Auswirkungen, man kann sich jetzt natürlich hinstellen und sagen gut, Open SSL ist eine Software die läuft halt auf Linux, also Windows nutzt eigentlich im Normalfall
nicht Open SSL. Auf jeden Fall weniger als Linux und da könnte man sagen ja okay Linux Server sind betroffen okay das Problem ist, dass natürlich die meisten Server im Internet sind, Linux Server, weil Linux ist ja auch ein Open Source Betriebssystem und es kostet nichts, du kannst es einfach verwenden, was natürlich viele auch nutzen um halt eben ihre Server laufen zu lassen logischerweise und wenn man dann aber jetzt denkt okay Windows war bei Safe, also zum Beispiel
Windows Server, dann ist es halt auch.
Weit gefehlt. Weil, und das ist auch so ein Ding, wenn du. Große Serverfarmen hast und zum Beispiel Du hast NE Commerce System und du hast zum Beispiel so ne Art. Prime Day, wo ganz viele Leute nach Angeboten shoppen und alle greifen auf, zum Beispiel n Server zu, dann würdest du ja nicht sagen, ja komm, wir probieren mal alle auf den Server zuzulassen 100000000 Leute die da drauf wollen weil wie du ja auch schon meintest Dino diese Kapazität der Leitung ist ja belegt also nicht belegt
sondern begrenzt. Und da hast du deswegen natürlich mehrere Server. So und damit das aber gut funktioniert, gibt es meistens sogenannte Load Balancer, die diesen Traffic verteilen auf die verschiedenen Server, sodass sagen wir mal, wenn 100 000 Leute kommen, dass jeder Server 1000 Anfragen bekommt, je nachdem wieviel Server man hat und selbst wenn du Windows Server hast, ist meistens ist es so, dass dieser Load Balancer, der davor sitzt um diese Last zu
verteilen. Läuft meistens auf einem Linux System und damit hast du genau an dieser Stelle wieder diese sensiblen Daten, die dort sozusagen drüber laufen. Ja, und damit hast du genau wieder diesen Angriff, obwohl eigentlich theoretisch man sagen könnte, ja, Windows war dann nicht so gefährdet. Und am Ende waren dann doch gefühlt wieder alle betroffen davon.
Ja, richtig und? Es ist ja auch nicht so, dass man zum Beispiel sagt, Ja gut, das, es geht jetzt nur um Websites, ne, also TLS wird ja von verschiedenen Sachen benutzt, also Mails verwenden, TLSVPNS verwenden, TLS Firewalls verwenden, TLS, also es gibt sehr sehr viele Komponenten die TLS verwenden. Vpn ist zum Beispiel auch ein guter Grund gewesen, dieses heartbeat Update umzusetzen, weil du halt diese aufrechte Verbindung die ganze Zeit dann
hast. Ja, das ist schon das ist, das ist schon krass, was das für Auswirkungen hatte. Ich würde gerne noch einen anderen Punkt eingehen, weil ich weiß nicht, wie es dir da ging, aber als ich mich mit dem Bug beschäftigt habe, habe ich mich halt gefragt, wie kann es denn sein, dass ich jetzt ein Update mache und so eine enorm große Sicherheitslücke da reinkommt und vor allem, wie kann es sein, dass unerlaubterweise Speicher der Anwendung, also vom Server heraus. Gegeben wird und.
Dann hab ich mir quasi das in Open SSL angeguckt.
Also findet man ja auch schnell Liebe zu liebe Zuhörer, wenn du Bock hast dir das mal anzuschauen, dann Google einfach den Bug und sag Source Code dazu oder so, dann findest du auch recht schnell genau den Ausschnitt, der dafür verantwortlich war, also das Update und die Antwort ist eigentlich relativ schnell gegeben, weil Open SSL Inc. Entwickelt ist und versteht mich nicht falsch, ich habe auch sehr lange in C entwickelt und ich mag die Sprache auch sehr.
Aber das erklärt Halt auch relativ schnell, wie es denn sein kann, dass so so ein Speicher da einfach mal rausgegeben wird. So ein klassischer Fall ist ja meistens immer die Rede von Memory Leaks, das heißt das Speichern nicht mehr freigegeben wird und damit tot ist.
Aber hier haben wir genau den umgekehrten Fall, dass man sagt, Wir geben Speicher wirklich nach außen, also wir liegen die die Data dahinter und das fand ich halt total krass und wenn man sich diesen Source Code anguckt, das sind wirklich nur ein paar Zeilen. Fabi, das ist so krass und das ist echt sauberer C Code, das ist nicht nicht schlecht
programmiert. Also da wirklich kein Blame, nur es ist halt so dieses typische Happypass Coding, das heißt es ist einfach da man man ging halt davon aus serverseitig, dass der Client einem realistische Informationen schickt, also man ging davon aus dieses Pay Load Lengfeld ist ein wahrer Wert, dass niemand die Absicht hat da was falsches einzutragen,
sondern wer würde stimmt immer. Wer würde auch sowas tun, sondern dass quasi diese angegebene Länge auch immer zur Nachricht passt und dementsprechend hat man dann ganz ein typischer C Code. Manier ist ja klassische Pointer Arithmetik dann man hat sich halt einen Pointer darauf gesetzt, hat die Nachricht genauso wie ich es vorhin gesagt habe, der ist ja vorgegeben, der Aufbau, das heißt du konntest genau sagen erstes Byte gut request oder Response hattest du
schon mal deine Unterscheidung wie du antwortest, dann hast du. Du die nächsten 2 Bytes genommen hast gesagt, aha okay länger. Was war es bei dir 3 so dann. Da iteriere ich den Point da weiter und gucke auf die Nachricht. Schneid mir diese Nachricht der Länge 3 raus. Reservier mir n Speicher für meine Nachricht, hau da alles rein und ab damit wirklich Straight Forward entwickelt.
Das heißt du allokierst dir dein eigenen Speicher, dass du genug hast, um diese Nachricht aufzubauen und kopierst dann mit dieser typischen Ich glaube jeder der man C entwickelt hat, kennt die Funktion mit der man copy Funktion sagst. Du kopier bitte aus der Speicheradresse von da an zu einer anderen die eine Zieladresse.
Also Quelle und Destination mäßig mit der Länge Pay load length, die angegeben war und dann macht die Funktion, dass dann sagst du bitte von A nach B 3 Bytes, dann wären genau diese 3 Bytes die da anfangen bei A nach B gekopiert so und der Funktion ist es voll egal was du für eine Länge da übergibst oder ob in der ursprünglichen Nachricht überhaupt so viel Bytes drin waren, das ist der Funktionär egal. Und jetzt genau das ist nämlich das Problem.
Weil du sagst, jetzt 100 Bytes bitte kopieren, gibst ihm aber nur 3, dann allokiert er sich aber den Bereich und sagt jetzt an der Stelle 100 Bytes bitte und nach dem vierten Byte sind es eigentlich deine eigenen Daten die du da rein schreibst und nicht mehr das was du Empfang hast und 97 Bytes deines eigenen Speichers schreibst du schön in diese Antwortnachricht und ab damit und der Client denkt sich alles klar, ich habe 3 bytes gesendet, die nächsten 97 mal gucken was drinsteht.
Da und eigentlich wäre doch genau der fix dann an der Stelle und das was vergessen wurde war ja okay du sendest mir 3, sagst aber 100, also sende ich dir dann nur maximal 3 so weil mehr darf ich dir nicht senden oder? Das wäre doch jetzt die logische Konsequenz daraus. Genau, also die Konsequenz ist, einfach mal zu überprüfen und so wurde es am Ende auch gefixt. Es ist ein Einzeiler gut. Wir 2 mit dem Return noch. Es ist eigentlich nur eine If Bedingung am Anfang.
Dass du sagst, wenn. Payload Lenks, die angegeben ist, nicht realistisch ist also nicht gleich der Nachrichtenlänge, die ich empfangen hab, ist plus dem
Overhead von. Also du musst natürlich noch drauf rechnen, dass du ein Byte hast für die Typisierung, was ich meinte 2 Bytes für die eigentliche Länge, das ist ja dieses 16 bit Feld, das rechnest du drauf ja dann aber die gesamte Länge der Nachricht muss dann einfach dementsprechend was in Payload längs steht und wenn das nicht der Fall ist, dann wird es halt verworfen und genauso am Ende sah auch der fix aus, das heißt es sind 2 Zeilen die zwischen der absoluten
Katastrophe und sicherer Software entschieden haben und das ist mind blowing finde ich. Ich finde das halt so krass, was so 2 Zeilen ausmachen können, vor allem weil wir halt 2 Jahre. Sind ja richtig, weil das Halt so eine Riesensicherheitslücke ist. Durch 2 Zeilen Code. Ich stelle mir das ungefähr so vor, weil das wurde ja dann sozusagen per Zufall eigentlich gefunden und dann konnte es auch
gefixt werden. Dann musste das natürlich öffentlich publiziert werden und so weiter aber ich stelle mir das ungefähr so vor, als würde man in einer Bank arbeiten. Nach 2 Jahren mitkriegen, Ach du Scheiße. Die ganze Zeit konnte man einfach in den Safe gehen und sich da was rausholen. Ja, so ungefähr so, als du dir nach 2 Jahren denkst. Alter. Wie kann ich das irgendwem erklären?
Also weißt du, das ist das ist echt krass und da kommt man eigentlich auch n bisschen zu dem Punkt, natürlich, so wie konnte das eigentlich überhaupt passieren? Also das klingt natürlich jetzt so wie okay, aber warte mal, warte mal, warte mal. Also aus heutiger Sicht natürlich, wir schreiben Tests, das macht ja hoffentlich jeder klare Sache, auf jeden Fall, aber einfach nur die Frage wie das passieren konnte und ich finde es auch interessant bei Open SSL ist ja eine Open Source Software.
Und diese Open Source Software wurde eigentlich mehr oder weniger von der Hand voll freiwilligen Leute gepflegt und Gemain, taint und so weiter und es gab auch nen finanziellen Zuschuss. Also es wurde sozusagen gespendet dafür, dass so eine Open Source Library, die ja sehr sehr wichtig ist, also eine wirklich unglaublich wichtige essentielle Software, die für die Sicherheit von Millionen.
Servern sorgt. Natürlich wird da gespendet und es wurde ungefähr jährlich $2000 gespendet, damit diese Software. Wird von einer Handvoll Leuten, das ist doch also, das ist krass und du musst dir das so vorstellen, dass ein Doktorand.
Hat diesen Code, also diesen Heartbeat ne, also das genau dieses Update, diese Weiterentwicklung ne damit man eben genau dieses Problem was wir besprochen hatten mit dieser Kommunikation die aufrechterhalten werden kann, wurde implementiert von diesem Doktoranden und kleiner Fun Fact, es wurde Silvester 2011 committed eine Minute von Neujahr. Schön.
Also ich weiß nicht, was das damit zu tun hat, aber ich dachte mir so, vielleicht ist es auch n Learning, dass man vielleicht zu Silvester keinen Code mehr schreibt, sondern einfach mal. Rausgeht mit n paar Leuten Verknaller loslässt. Oh, stell doch covid. Das Update muss fertig werden, gleich ist Neujahr, das nehme ich nicht mit ins nächste. Jahr und das wurde dann halt von einem Mitarbeiter oder von einem anderen zuständigen.
Sag ich mal approved und das heißt einer committed etwas mit diesem kleinen Fehler, einer übersieht es und am Ende hast du halt dann einfach ein 2 Jahre lange Sicherheitslücke, die absolut krass ist. Und das find ich halt so krass, weil man kann jetzt sagen, ja gut, das musst du testen und hier warum, wer weiß was da lief. An Tests weiß ich jetzt nicht, aber selbst wenn du eine hohe Testabdeckung hast oder sehr sorgfältig testet, es ist.
Auch verständlich, dass so ein Edge Case oder bzw. Diese Annahme, dass jemand keine fairen oder echten Daten damit schickt, die passen, dass man sonst Fall auch mal übersieht das das passiert. Du kannst ihm ja auch keinen Vorwurf machen, weil wie gesagt, das war ja nicht schlecht gecodet, das war ne saubere Funktion, ich weiß keine Ahnung wie lange die da noch drin geblieben ist, ob die noch drin ist, ob er da noch quasi contributed drauf weiß ich
nicht. Ansonsten liebe Grüße. Aber Fakt ist, das war eine gut geschriebene C Funktion, nur dass dieser eine Fall nicht berücksichtigt wurde und das ist absolut legitim, dass das passiert, da kann man niemand
strikt raus drehen. Ich muss sagen, wenn du das in einem unternehmerischen Kontext hättest, glaube ich, dass man schon strikt daraus drehen könnte, weil wenn du zum Beispiel wirklich in einer großen Firma beispielsweise arbeitest und man dann sagt, ja okay, also man sollte solche Sicherheitschecks sozusagen machen, also gucken, wo sind denn mögliche? Angriffsvektoren, das sollte man auf jeden Fall checken und sicherheitsprofil davon aufbauen, da bin ich fest von überzeugt.
Nur man muss ja bedenken und das ist finde ich das was die ganze Sache irgendwie entschuldigt, weil erstens ist es guter Code gewesen. Meintest und auf der anderen Seite waren das Leute, die das freiwillig contributed haben und da ist ja sozusagen auch ein bisschen selber schuld, wenn alle auf der ganzen Welt eine sehr, sehr wichtige Sicherheits, also eine sehr, sehr wichtige Software benutzen, die
sicherheitsrelevant ist. Für das sage ich jetzt mal das gesamte Internet, und dann gibt man aber nur $2000 Spenden jährlich an so ein paar Mitarbeiter, die eigentlich nur Gutes tun wollen und sozusagen unterstützen wollen. Also da kannst du diesen Menschen keinen Strick. Aber nee, deswegen ne nur ich finde halt auch. Also ich verstehe deinen Punkt, dass man sag ich mal unter unternehmerischen Kontext das so nicht passieren darf. Es darf allgemein nicht passieren, ganz klar.
Nur ich finde, die Schwierigkeit ist eher oder was problematisch ist, dass das so spät aufgefallen ist. Also es ist ja absolut nicht verwerflich, dass man so n Fall übersieht, aber man muss es halt relativ schnell mitbekommen und fixen, weil 2 Jahre ist einfach zu lang für so ne Sicherheitslücke und was ich extrem krass auch dabei finde, um das noch mal kurz zu beleuchten, du kannst einfach nicht. Ermitteln, wieviel Schaden
entstanden ist. Du weißt nicht, was innerhalb dieser 2 Jahren an Daten abgegriffen wurde? Ja, und diese Unbekannte, also dieses, diese Ungewissheit, wer weiß jetzt über was Bescheid? Am Ende finde ich ist halt das krasse und nahezu schon unheimliche dabei, weil es 2 Jahre sind lang, das heißt du als Unternehmen, wenn du jetzt deine Server hast mit dieser Version. Also. Unter dieser Protokoll Version laufen lassen hast und diese Sicherheitslücke drin war.
Du weißt ja nicht ob jetzt einfach sämtliche Firmen interne Geheimnisse oder was auch immer auf den Servern war, jetzt nach außen gedrungen ist. Ja richtig, das ist auch eine Sache, die sehr, sehr einen bitteren Nachgeschmack zurück lässt. Was ich noch interessant fand, war, dass es dann natürlich Lösungen gab, nachdem es aufgedeckt wurde. Das heißt, du konntest natürlich eine gefixte Version einspielen. Auf deinen Servern
logischerweise. Das heißt, dass die Serverseite, wenn du aber zum Beispiel ein Client warst und kein Server betrieben hast und damit eigentlich nichts am Hut hattest, gab es sogar auch Plugins für Browser, die dann im Vorfeld, wenn du auf eine Seite gegangen bist, gecheckt haben, ist dieser Server, mit dem du gerade kommunizieren möchtest, anfällig dafür. Ja, also fand ich auf jeden Fall interessant und irgendwie auch ne coole Sache.
Klar kann man sich jetzt hinstellen und sagen, Ey Pass auf, wenn du dieses Plugin hast, dann kann ja n Angreifer auch sozusagen die Server scannen und gucken, ob die dafür sozusagen anfällig sind, aber das kann man ja auch so.
Ja, also ausprobieren, im Endeffekt wichtig, dann für die, für die Leute. Aber was haben wir denn, also was konnte man jetzt denn daraus irgendwie lernen, weil ich finde, es ist ja irgendwie wichtig, dass man am Ende noch irgendwie n Learning draus zieht und sagt, OK, das ist was passiert. Und was können wir damit jetzt machen? Am Ende, weil das Kind ist im Brunnen gefallen, das Ding ist durch, ne, also da wurden Daten abgegriffen über 2 Jahre oder auch nicht, wer weiß es schon.
Wir wissen nicht was, aber was können wir denn für die Zukunft daraus lernen? Ja, also ein großer Punkt, den hast du auch angesprochen. Ist das so Open Source Projekte echt essentiell sind für unsere ganze Tag Landschaft und es gibt so viele davon, die aber auf den Rücken privater Leute aufgebaut sind, die das einfach. Ja, freiwillig und aus Spaß an der Freude oder so sagt man auch ne machen, weil sie einfach dahinter stehen und überzeugt davon sind, aber gar nicht.
Also man muss. Sich ja überlegen wieviel Zeit das benötigt. Sowas zu maintain und wenn dann keine finanzielle Förderung dahinter ist oder spenden was auch immer Geld einfach Geld dann. Wie soll das denn auch alles immer reibungslos laufen? Also das muss man auch schon mal wirklich wertschätzen, was diese Open Source Projekte bedeuten und ruhig auch mal donaten würde ich mal sagen, das kann man ruhig mal auch mal so sagen.
Weil man sieht, wenn das alles mit Zeitdruck und ja, sie müssen nebenbei arbeiten und haben eigentlich gar keine Zeit, das zu 100% zu verwalten und dann schnell noch ein Update, was sich gewünscht wird hier und da, dann passieren halt Fehler am Ende. Also ich bin Fan von Open Source. Man muss sich 1 klar machen, glaube ich, nur weil jeder Open Source Software. Blick drauf werfen kann, bedeutet das noch lange nicht, dass es auch jeder tut. Ne.
Also da wird glaub ich auch oftmals so n bisschen dann sich drauf verlassen und gesagt ja Open Source Software, da kann ja jeder drauf gucken und so weiter. Aber. Das passiert halt nicht immer ne und da muss man dann halt gucken, dass man vielleicht so bestimmte wirklich kritische Softwarekomponenten, die sowas wie halt eben dieses Beispiel zeigt, auch vielleicht mal n bisschen genauer unter die Lupe nimmt.
Deswegen ist es auch immer hilfreich, dass auch jeder zum Beispiel. Ne, also liebe Zuhörerin, lieber Zuhörer, auch du kannst dir Open Source Code angucken. Ja. Absolut. Dann find ich so n Learning, was ich dabei auch wieder rausziehe ist also hinsichtlich C Code, dass man halt echt ne Menge Unfug damit treiben kann. Und Speicher? Verwaltung einfach ein riesen Punkt ist, gerade wenn man C codet. Das heißt da auch aus Security Aspekten ordentlich darauf achtet was man da auf dem
Speicher macht. Ich finde halt das ist auf jeden Fall auch wichtig ist sich vor Augen zu fühlen, egal wo man dran codet aber wenn du irgendwo rein theoretisch Schnittstellen nach außen hast in deiner Software, dann ist es ein Blick wert zu sagen gibt es potenzielle Sicherheitsrisiken an dieser Stelle und was könnte sein, da hilft es auch einfach mal vielleicht sich ein bisschen zu unterhalten.
N bisschen in den Austausch zu gehen und zu sagen, du Pass auf, ich hab jetzt das und das diesen Sachverhalt, wie sieht es aus, könntest du dir vorstellen, dass da irgendein Mist passieren könnte? Sowas hilft natürlich auch, ich meine es gibt ja auch n Learning, was natürlich auch sicherlich jetzt mittlerweile schon überall angekommen ist.
Das ist die sogenannte 2 Faktor Authentifizierung, das heißt wenn jemand ein Username und Passwort hat, bedeutet das noch lange nicht, dass man auch wirklich überall reinkommt, heißt aber nicht, dass überall 2 Faktor angewendet wird, aber es ist natürlich eine Sache, dass dieses 2.
Faktor immer mehr kommt. Genau aus solchen Gründen, dass du halt eben nicht nur über solche Sachen, wenn auch wenn es geleakt werden würde, dass man dann trotzdem nicht genau in diese Systeme reinkommt oder ein online Banking, was auch immer. Sehr gut zusammengefasst. Also ich würde sagen, haben wir es auch wieder ausführlich besprochen, aber ich find das Thema super spannend und ich find es, ich muss es einfach
noch mal sagen. Ich find es krass wie 2 Zeilen Code über sowas entscheiden können. Es ist Zeit und ich find es halt. Und wie lange, vor allem und wie riesig dieses Potenzial war für Schaden. Die tut man einfach nicht, weiß, wieviel Scharen wirklich entstanden ist. Find ich auch krass dabei in. Diesem Sinne blutet mein Herz, weil die Folge wieder vorbei ist, hart blieb und so. Schön schön, Fabi, der war gut. Oh, weil heute bin ich aber auch, ja. Muss.
Ich mich für entschuldigen, aber ich möchte in dem Sinne auf jeden Fall sagen, Tino, Es hat mir wieder Spaß gemacht mit dir darüber zu reden. Dann gib mal Zuhörer, lass auf jeden Fall mal eine Bewertung da empfiehl den Podcast weiter.
Uns würde brennend interessieren, was du auch zum Beispiel selber mitbekommen hast von diesem Heartbleed Bug ist ja nicht so lange her 2014 und schreibt uns das gerne oder schreibt uns auch dein Feedback gerne über die Podcast Mail wenn du sagst ich finde das cool, das macht richtig Spaß hier zuzuhören. Die Coding Buddies ist ein geiles Projekt, das macht Spaß, dann unterstützt uns gerne auch in den Show. Ist ein Link für eine kleine Spende, wären wir dir super dankbar für.
Weil wir wollen alles, was wir darüber bekommen, nehmen wir und verbessern unseren Content, damit du noch schöneren Content bekommen kannst. Und Yeah. Genau und deswegen andere Unterstützung ist halt in dem Sinne auch Feedback, konstruktives Feedback, das hilft uns auch sehr weiter in dem Sinne würde ich sagen, empfehlen den Podcast noch 2 Freunden weiter, wenn er dir gefällt und ansonsten sind wir raus für heute. Ich wünsch euch noch nen schönen Tag bis zum nächsten Mal deine
Coding Buddies gemeinsam. Besser.