Sicherheits-GAU Nummer Drölfzig: Cloudbleed

Man sollte einfach abseits von wirklichen High-Performance-Anwendungen und systemnaher Entwicklung einfach kein C mehr verwenden, gibt inzwischen nun wirklich genug schnelle und vor allem sicherere Alternativen, bei denen man nicht jede Zeile zweimal umdrehen muss, um potenzielle Gefahren zu sehen.

 

">=" statt "==" kann einem aber schnell passieren, auch abseits von C, oder nicht?

 

Im Sicherheitsdesign der Sprachen gibts schon große Unterschiede, die viel Fehlverhalten automatisch verhindern können.

Bisschen Lesestoff:
http://security.stackexchange.com/questions/55723/are-there-secure-languages

 

Menschliches Versagen bleibt menschliches Versagen, dagegen hilft die beste Technik nichts.

 

Genau deshalb sollte man den Menschen möglichst gut unterstützen.

 

Doch, genau das wird doch laufend getan. Spurhalteassistenten, oder dass der Geldautomat dir erst das Geld gibt wenn du deine Karte herausgezogen hast, so dass du sie nicht vergessen kannst.

Da gibts genug Unterstützung, moderne Entwicklerumgebungen fangen da wirklich viel ab.

 

Bspw. über Patreon?
Oh man ey...selbst die sind betroffen.

 

Ja, und wer braucht bei TB-weise Caching und SSL-Offloading schon High Performance

 

Amüsant ist ja, dass PCGH, PCG und HWLuxx betroffen sind, aber Gamestar nicht.

Und ein bisschen Schadefreude: Es hat auch deutsche-wirtschafts-nachrichten.de getroffen.

 

Ich würde nicht mal in jedem Fall sagen, dass higher level Sprachen zwangsläufig langsamer laufen.

Siehe z.B. diesen "Wettbewerb".

Eine recht einfache Anwendung. Dennoch musste einer der weltbesten Performance Optimierer in C++ sechs Anläufe nehmen, um die Performance des (wirklich simplen) C#-Programms schlagen zu können; inklusive, dass er eigene Klassen für Strings, Speicherallokatoren & Co schreiben musste, und der Code imho am Ende durch die Optimierungen in einem solchen Zustand war, dass er definitiv nicht mehr ohne weiteres les- und wartbar war.

Klar gibt es auch eine ganze Menge Anwendungen, wo du mit C++ deutlich einfacher mehr Performance rausholen kannst. Und teils mit Techniken, die dir sonst nicht zu Verfügung stehen.

Aber die modernen Sprachen holen sehr schnell in Performance auf; und das schöne ist natürlich auch, dass zumindest bei interpretierten Sprachen auch schon fertige/veröffentlichte Programme noch im Nachhinein von neuen Optimierungen profitieren können.
Auch sehr performante, skalierbare und komplexe Server lassen sich z.B. wunderbar in C# umsetzen, sehe nichts was da prinzipiell dagegen spricht.

 

Vlt. das ich meine Software auch auf nicht-bastelrechnern - vulgo 'Windows' genannt - laufen lassen kann? Und C# ohne .net ist halt nur begrenzt spassig

Diese 'einfachen' Sachen sind gut und schoen. Es hat aber sehr gute Gruende das Sachen wie Varnish in C geschrieben werden - offenbar wirds dann spaeter eben DOCH hinreichend schnell.

Ich habe selbst mit C nichts am Hut, meine Programmierkenntnisse hoeren nach Python auf. Das ist allerdings die Meinung unserer C- und C# Developer, die tw. ueber 20 Jahre Berufserfahrung haben.

Das einzige was ggf. bei Caching Sachen interessant werden koennte ist eine Implementierung in Erlang. Asynchrones foo koennen die naemlich richtig richtig gut

 

Da zahlt es sich einmal aus technisch zurückgeblieben zu sein!^^

 

Du stellst dir hier eine einfache Lösung für ein komplexeres Problem vor, die so in der Praxis nicht funktioniert.

 

Unrecht hat er aber nicht.

Buffer Overflows dürften z.B. wohl vielen ein Begriff sein - eben gerade weil sie früher mal ein so beliebtes Einfalltor waren für Hacks.
Und auch kein Problem, dass man mal eben mit ein klein wenig Aufmerksamkeit vermeiden konnte, solche und ähnliche Anfälligkeiten waren - und sind - in den allermeisten, wenn nicht fast allen auch professionellen Programmen, die etwa mit C / C++ geschrieben wurden.

Nun versuch mal, ein C# Programm zu schreiben dass dadurch angreifbar wäre. Das ist fast nicht möglich (esseidenn du schreibst entsprechenden unsafe code, das würde ich dann aber schon fast als Vorsatz zählen lassen...)

Nicht, dass Programme in solchen Sprachen nicht mit Sicherheit auch Anfälligkeiten haben. Aber sehr viele der bekannten Schwachstellen gibt es dort schlicht nicht wirklich - nicht zuletzt, weil es dort eben sehr viele Standardfeatures gibt die von wirklich sehr intelligenten Leuten designed wurden, und so die "gefährlichen" Operationen vom Ottonormalprogrammierer fern halten.

Kannst du mit .Net aber auch
Mit Mono bereits jetzt, und vor allem mit .Net Core - wobei letzteres noch eine ziemlich neue Sache ist, und erst in den nächsten Monaten/Jahren richtig durchstarten dürfte.

Zu Varnish kann ich nicht sagen weil ich's schlicht nicht kenne.

Meiner Erfahrung nach gibt's aber oft viel simplere Gründe, warum Software in Unternehmen mit Sprache XYZ programmiert wird: "weil wir das schon immer so gemacht haben!"
Wenn die Entwickler seit >20 Jahren etwa mit C++ entwickelt haben, dann wird die Firma im Normalfall eher nicht auf eine andere Sprache umschwenken, auch wenn sie vielleicht theoretisch geeigneter/besser für den Einsatzzweck wäre.
Erst recht, wenn Legacysysteme, die aber noch supported werden müssen/sollen, sowieso noch darin geschrieben wurden. Grüße an den Cobol-Programmierer bei meinem letzten Arbeitgeber

Asynchronität ist übrigens auch eine Sache, die in den "neueren" .Net Versionen absolut grandios umgesetzt ist, Stichwort async/await und etwa - ich liebe es - Reactive Extensions.

Egal, genug Offtopic von mir - gute Nacht!

 

Ich red ja nicht von Java.

Okay, man tut Java eigentlich zunehmend unrecht. Die haben die JVM schon wirklich flott gemacht. Man schaue sich Twitter an. Fast alle Services sind in Scala geschrieben und laufen damit über die JVM. Das Zeug mag lange zum Staren brauchen, aber wenn's mal läuft, ist es auch schnell.

Mit entsprechend modernen Sprachen wie Rust oder Swift kann aber auch zunehmend solche High Performance-Programme schreiben ohne große Einbußen zu haben. Wer's härter und rein funktional mag, Haskell-Programme sind verdammt schnell und der Compiler ist eines der größten Arschlöcher überhaupt, weil er wirklich jeden Dreck bemängelt. Dafür hat man aber auch dann zur Laufzeit kaum noch Probleme.

 

Cloudflare würde ich jetzt nicht unbedingt als "technisch fortgeschritten" sehen. Man kann das ganze auch selber machen.

 

klar, aber warum sollte man? Es gibt diese services und soweit ich weiß sind die ja nichtnur für ddos protection, und grade beim thema uptime hat das gspb und die ganze gamestar seite doch ab und an mal hänger

 

CloudFlare hat ziemlich coole Caching-Möglichkeiten, um die Seiten-Performance deutlich zu verbessern und im Gegensatz zu AWS CloudFront, das zwar einen recht vergleichbaren Funktionsumfang hat, ist CloudFlare doch deutlich einfacher zu konfigurieren.

Wenn man das richtig einsetzt, kann man sich einen Haufen Kosten sparen. Zu meiner Zeit bei Chip lief das alles über Akamai und hat enorm geholfen. Damit konnten über 200 Mio. Page Impressions/Monat mit einer Hand voll Server gestemmt werden, weil den Großteil der Last Akamai bereits vorher abgefangen hat. CloudFlare und AWS CloudFront können heute wesentlich mehr als dieses recht simple CDN-Caching von Seiten und Assets, das man damals bei Chip hatte.

 

Warum sollte High-Performance nur mit C gehen?

Ist sehr oft, vorallem im industriellen Umfeld, gar kein Kriterium.

 

Gamestar benutzt ja auch kein https...

 

Die anderen drei auch nicht.

Welche IT-Seiten nutzen das denn? Selbst Heise und Golem nicht. Mir fällt da nur Computerbase ein.

 

Öh doch? Eine von beiden schon länger, die andere hat vor ein paar Wochen umgestellt. Da haben sich dann User drüber lustig gemacht, weil die andere Seite eben deutlich schneller war.

 

Der TLS-Handshake dauert bei Heise und Golem mitunter tatsächlich recht lange.

 

Ich meinte schneller im Sinne von "schon vor längerer Zeit umgesetzt".

 

Wer hat das gesagt? HP geht in C ggf. einfacher, bzw. findest du bei C einfach mehr Leute, die sich auf HP spezialisiert haben.

Da ich an der Quelle sitze... Stimmt gerade wenn du deine Services aber Container Ready haben willst, kannst du Windows vergessen. Horizontales Skalieren mit Windows ist wesentlich ineffizienter als bei Linux. Und das kann ich in diesem Fall sogar genau sagen, weil ich vor einem halben Jahr eine horizontal skalierende Caching Loesung mit IaaS Integration fuer eine Rundfunksendeanstalt aufgebaut habe Und wenn ich mir Cloudflares Software Stack so anschaue, dann spricht das doch in meinen Augen auch ganz klar fuer ein Linux Backend.

Aber klar, optimier deinen Windows Kernel mal auf Paketdurchdsatz.

Ich will Microsoft nicht bashen, die haben mit Azure eine gute Plattform mit tollen Services auf die Beine gestellt und es schon vor Jahren geschafft, fuer den Entanwender einfach verwendbare Betriebssysteme zu bauen. Ihre Office Anwendungen sind bis heute imho das beste was es gibt, zumindest fuer die nicht-Techniker.

Aber auf High Performance Servern haben die einfach nichts zu suchen, vor allem wenn du verteilte Architekturen baust. Da wird Windows ganz schnell zur traegen, fetten Bastelbude. Und jeglicher Overhead wie eben C# ihn bei ausreichend grossen Programmen mitbringt, ist da viel zu viel.

Und zu Java: Man 'kann' sicher tolle und schnelle Projekte in Java bauen. Ich hab allerdings noch keins gefunden Spaetestens wenn ein Java Application Server dazu kam, wurde das ganze etwas... gemaechlich und... interessant aufzusetzen.

 

Echt? Ok... Da ich da nicht bezahl und denen durch Adblock keine Einnahmen nehmen will, geh ich da nur selten drauf.

Aber wie du schon sagtest, ist erst seit relativ kurzer Zeit.

 

Das ist durchaus richtig, aber wirklich gute C-Entwickler gibt's auch nicht gerade viele -- deswegen passiert ja auch immer wieder so ein Dreck. Wenn man solche Fehler komplett vermeiden will, müsste man sich wohl an die Entwickler-Richtlinien der NASA halten.

Ich wüsste auch niemanden in dem Umfeld, der für solche Anwendungsfälle ernsthaft Windows in Betracht ziehen würde -- das ist Harakiri. Da würde vermutlich ein Cluster aus Android-Geräten noch besser skalieren.

In Sachen Bedienung würde ich macOS und iWork vor Windows bzw. Office stellen, aber Office kann dafür halt auch wesentlich mehr ... womit wir beim Thema der Excel-Helden wären.

Wie gesagt, Twitter. Okay, die nutzen nur die JVM für Scala, aber es kann wohl keiner abstreiten, dass das Ding schnell ist.

Ich arbeite ja selbst in einem Projekt, das einen Java-Teil (kein 300.000-Schichten-Abstract-Factory-Factory-Factory-Monster) als Backend hat. Der serverseitige Teil des Frontends ist in Ruby geschrieben (kein fuckin' Rails). Das ganze läuft mit JRuby, kann also dann direkt auf die Java-Methoden des Backends zugreifen.

Die Startup-Zeit ist beschissen, sowohl wenn man es einzeln startet als auch später im Tomcat, aber wenn's läuft, ist es schnell -- sehr schnell sogar.

 

Über kurz oder lang müssen eh alle. Chrome und Firefox zeigen ja heute schon Seiten mit Passworteingabe ohne TLS als unsicher an. Google wird außerdem zunehmend dazu übergehen die Verschlüsselung als Kriterium für die Reihenfolge der Suchergebnisse stärker zu gewichten.

Daraus ergibt sich ja noch ein weiterer Vorteil: läuft es dann schon mit TLS, kann man auch wesentlich problemloser auf HTTP/2 umstellen, was sich insbesondere für Leute mit schlechten Internetverbindungen und auf Mobilgeräten sehr positiv auf die Ladezeiten auswirken wird.

 

Na gerade Rest Schnittstellen kannste daraus extrem schnell kloppen (gebaut mit Spring Boot?), dazu gibts Libs fuer alles und jeden.

Das schafft Freude beim Entwickler wenn er das Ding testen muss, bzw Bugs fixt Und... Hast du mal die arme Sau gefragt, die den Tomcat upgraden muss? Habe da lustigste Dependencies gesehen zwischen Java Libs und einer bestimmten Tomcat Version

E: TLS ist in Zeiten von LetsEncrypt ja nun auch wirklich keine Sache mehr...

 

Defintiv.
Computerbase ist in der Hinsicht echt vorbildlich.

 

Das Ding kümmert sich primär um die Kommunikation mit dem eigentlichen Backend-System des Kunden und kapselt die Business-Logik. Der Ruby-Teil übernimmt dann HTML-Rendering etc. und stellt 'ne kleine REST-API für eine Angular-Applikation bereit.

Wir können die Ruby-Schicht unabhängig auch mit CRuby laufen lassen und entwickeln fürs Frontend dann primär damit. Die Kommunikation mit dem Java-Teil ist gekapselt und kann für diesen Zweck komplett mit einer Mock-Version ersetzt werden. Entwickeln wäre sonst quasi wirklich eine absolute Qual, wie Du schon sagst und aufgrund diverser Setup-Themen mit Test-Nutzern usw. mit dem Staging-Systemen des Kunden, wären umfangreiche, vollautomatische Integration-Tests wie wir sie fahren, quasi unmöglich.

Also wir entwickeln unser Zeug vernünftig, da käme niemand auf die Idee irgendwelche Libs zu verwenden, die auf bestimmte Tomcat-Versionen angewiesen sind.

Eben. Mein privates Blog läuft bei uberspace, da ist Let's Encrypt via SSH in Sekunden eingerichtet und nach der ersten Lauf, kann man's sogar automatisieren, dass alle drei Monate das Zertifikat automatisch erneuert wird.

Bei webcodr war ich noch fauler. Das wird über 'nen Static Site Generator (Hugo) gebaut und bei GitHub Pages deployed. Da kümmert sich dann gleich GitHub um TLS.

 

Fuer den haertestmoeglichen Aufschlag in der Realitaet empfehle ich zwei Jahre bei einem Automobilhersteller Ich sehe da regelmaeesig Java 1.6 Installationen.

 

Kenn ich schlimmer ... in einem Fall wurde erst 2016 auf Java 1.6 umgestellt und das auch noch groß gefeiert.

 

Ugh, ich schiebe das nun echt schon viel zu lange vor mir her, aber es wird echt Zeit mal auf einen ordentlichen Passwort-manager umzusteigen. Hat da jemand Empfehlungen? Was ich brauche:

- Läuft (ohne root-zugang, also ohne Installation zu benötigen) unter Linux, OSX, Android
- Verwaltet Liste von Passwörtern, verschlüsselt über Master-PW
- Speichert nichts in der Cloud, die Synchronisation mache ich selbst
- Ich bin bereit einmalig dafür zu zahlen, aber ich schließe keine Abos für Software ab.

Wünschenswert außerdem:
- Kopiert gewähltes Passwort automatisch in die Zwischenablage
- Erstellt automatisch einen zufälligen String bei Bedarf eines neuen Passwortes (Länge und Alphabet am besten Konfigurierbar)

Gibt's sowas? Wenn nicht, warum?

 

Enpass mit Geld, dafuer nicht Open Source.

Ansonsten Keepass2 fuer Windows und KeePassXC fuer Linux. Mobile Clients gibts auch, die muessen halt mit den kdbx2 Files umgehen koennen. Habe ich so im Einsatz, bin sehr zufrieden.

 

Bis auf die Linux-Unterstützung kann 1Password alles, was Du willst. Sync zum Telefon funktioniert dann im lokalen WLAN. AgileBits forciert zwar gerade massiv das Abo-Angebot mit Cloud-Anbindung, man kann aber 1Password auch nach wie vor als Einzellizenz kaufen.

Ansonsten bliebe wohl wirklich nur KeePass oder eine web-basierte Lösung, die Du ja nicht willst.

 

Ich bin mit KeePass happy, nutze mehrere Windows Rechner, ein iPad und ein Android Handy - keine Probleme.

 

Hm, danke. Enpass sieht ganz gut aus, aber Open Source wäre mir hier lieber. Will nicht in ein paar Jahren vor dem gleichen Problem stehen, nur weil eine Firma pleite gegangen ist.

Leider ist an meinem Rechner an der Uni wohl kein Mono installiert, das schränkt Keepass dann wohl auch wieder ein. Ich schaue mir dann mal KeepassXC an.

 

Ich habe KeepassXC auf Linux weil es einfach via Snap instaliert werden kann, nicht dutzende Abhaengigkeiten hat und vor allem mit ChromeIPass zusammen arbeitet.