1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › OpenSSL: Wichtige Fragen und…

C-Bashing greift zu kurz

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. C-Bashing greift zu kurz

    Autor: Mingfu 09.04.14 - 17:10

    Sätze wie "Es gilt aus diesem Grund als extrem schwierig, in C wirklich sicheren Code zu schreiben." halte ich in dem Kontext für absoluten Unfug. Ich habe mir den Blogbeitrag, der den Fehler beleuchtet, durchgelesen. Sicher, bei einer Sprache mit Managed Code wäre es in dem Fall nur zu einem Laufzeitfehler gekommen. Aber wäre damit alles in Butter? Alles nur eine Frage der Programmiersprache? In meinen Augen nicht.

    Das wahre Problem liegt im Programmierparadigma. Fremdgesteuerte Eingaben wurden nicht auf Plausibilität getestet und direkt verarbeitet. Programmierer, die die Notwendigkeit derartiger Tests übersehen oder gar absichtlich aus Performancegründen o. ä. weglassen, werden auch in anderen Programmiersprachen als C Code abliefern, der hochgradig gefährdet ist, unfreiwillige Aktionen auszulösen. Solche Nachlässigkeiten sind immer gefährlich. C zu geißeln, greift also zu kurz.

  2. Re: C-Bashing greift zu kurz

    Autor: The-Master 09.04.14 - 17:46

    Sicherlich hast du recht, dass es in der Verantwortung der Programmierer liegt, die Eingaben zu Prüfen, und das Programm so zu gestalten, dass es nicht zu derartigen Sicherheitslücken kommt. C hat dabei den Vorteil, dass es einem leicht macht, sehr performante Programme zu schreiben, allerdings auch auf Kosten der Sicherheit. Das Speichermodell von C schränkt einen nicht künstlich ein, so wie es bei Managed Code der fall wäre. D.h. als Programmierer besitzt man bei C Freiheiten, welche man Natürlich einsetzen kann, um auf sehr elegante Art und Weise gute und schnelle Programme zu erstellen.
    Allerdings sollte man schon die Diskussion zulassen, ob es sinnvoll ist, wenn man derart sicherheitsrelevante Programme in einer Sprache schreibt, die einem Solche Freiheiten einräumt. Wohlwissend, dass Fehler IMMER passieren können. Auch in einem sehr gut gepflegtem Open Source Projekt wie OpenSSL.
    Oder man lieber auf diese verzichtet, und so dem Schutz vor kritischen Sicherheitslücken bzw. vor Exploits einen höheren Stellenwert einräumt. Z.B. indem man sich darauf einigt eine Sprache zu verwenden, die anders als C, den Zugriff auf den Hauptspeicher generell - oder auch nur in Teilen - reglementiert. So dass schon durch die Verwendung der richtigen Plattform (hier also Programmiersprache) sichergestellt wird, dass Speicherfehler nicht mehr Auftreten können, oder zumindest abgefangen werden.

    Für mich ist C zwar eine schöne Sprache, und natürlich kann jemand der Fehlerfreien Code schreibt, damit auch sehr gute und sichere Programme erzeugen. Aber die Realität sieht doch so aus, dass es in Projekten wie OpenSSL immer Fehler geben wird. Womöglich solche, die erst dann entdeckt werden, wenn es zu spät ist. Warum betreibt man also keine Prävention, indem man den Programmierern ein Werkzeug zur Hand gibt, was zumindest die Auswirkungen der Fehler beschränkt?

  3. Re: C-Bashing greift zu kurz

    Autor: Gamma Ray Burst 09.04.14 - 17:56

    Ich wurde einmal durch eine Codestelle traumatisiert die sah so aus:

    int *********************a;

    Ich hielt es zu erst für einen Kommentar.

    Es können auch mehr Sternchen gewesen sein, ich weiß nur das ich mich in dem Augenblick entschlossen habe, diesen Code nicht zu verwenden.

    Ich mag C, super schnell und in der geübten Hand eine sehr mächtige Sprache. Allerdings verhält es sich wie ein extrem scharfes Sushi Messer man muss damit umgehen können und wissen was man tut.



    1 mal bearbeitet, zuletzt am 09.04.14 17:56 durch Gamma Ray Burst.

  4. Re: C-Bashing greift zu kurz

    Autor: bernd71 09.04.14 - 17:59

    Welche Sprache kann man denn nehmen wenn man eine Bibliothek entwickeln möchte die in möglichst vielen Programmiersprachen und Platformen verwendet werden soll. Bleibt da noch was anderes als C?

  5. Re: C-Bashing greift zu kurz

    Autor: twothe 09.04.14 - 18:04

    Das ist das klassische OpenSource-Problem: Code wird von Leuten in ihrer "Freizeit" geschrieben, d.h. eher Helden-Code, wenig bis gar keine Tests und schon gar keine externe QA die das mal auf Herz und Nieren prüft.

    Der Vorteil von OpenSource: es war schon gefixed bevor die Meldung durch die Blogs ging.

  6. Re: C-Bashing greift zu kurz

    Autor: pythoneer 09.04.14 - 18:09

    Gamma Ray Burst schrieb:
    --------------------------------------------------------------------------------
    > Ich wurde einmal durch eine Codestelle traumatisiert die sah so aus:
    >
    > int *********************a;
    >
    > Ich hielt es zu erst für einen Kommentar.

    immernoch besser als

    int a[100][100][100][100][100][100][100][100][100][100][100][100][100][100][100][100][100];

    :D

  7. Re: C-Bashing greift zu kurz

    Autor: EWCH 09.04.14 - 18:09

    in C macht man die Speicherverwaltung groesstenteils selbst. Wenn aber die
    Sprache einem alles abnimmt dann steckt die Komplexitaet und damit auch
    die Fehler eben dort. Wenn ich mir ansehe wieviele Sicherheitsluecken Java bereits
    hatte (davon sind dann alle Java-Programme betroffen) bleibe ich lieber bei C.
    Und Daten des Netzwerk Sockets vor der Weiterverarbeitung zu pruefen ist
    ja nun wirklich kein Hexenwerk.

  8. Re: C-Bashing greift zu kurz

    Autor: Kasabian 09.04.14 - 18:09

    Ja ja... alle Freizeitentwickler... immer diese Hobbyschreiber...

    Schon einmal überlegt dass dort keine Noobs sitzen, sondern Experten wie oder in richtigen Unternehmen?

    Ich denke es ist ein zeitliches Problem, weil irgendso ein BWL'er mal wieder langeweile hatte und ein terminiertes Storyboard dazu ablieferte... ;)

  9. Re: C-Bashing greift zu kurz

    Autor: Perry3D 09.04.14 - 18:12

    Du hast wirklich eine falsche Vorstellung von OS-Entwicklern. Das sind meist richtige Profis.

    Und meiner Erfahrung nach ist Code aus Unternehmen oft nicht besser. Das liegt dort nicht an schlechten Programmierern, sondern am Termindruck. Da kann ich aus eigener Erfahrung sprechen :-) .

  10. Re: C-Bashing greift zu kurz

    Autor: Mingfu 09.04.14 - 18:14

    Zumindest eine Bibliothek wird man in den Sprachen und Umgebungen anbieten müssen, in der die Anwender sie verwenden wollen. Es würde also wenig bringen, wenn OpenSSL zur Laufzeit eine JVM o. ä. benötigt. Insoweit ist die Diskussion bereits grundsätzlich etwas müßig.

    Aber davon mal ganz abgesehen: Die Fehlermuster, die hier dahinter stecken, führen auch in anderen Umgebungen zu ganz fatalen Sicherheitslücken. Nehmen wir z. B. die FritzBox-Lücke der letzten Wochen (technische Details siehe hier). Da wurde ein URL-Parameter ungeprüft an eine Shell weitergereicht. Das wäre dann selbst unter Java und Co kein Stück anders abgegangen. Mangelnde Eingabeprüfung ist ein so grundlegendes Problem, dass es in meinen Augen wenig lohnt, mit der Programmiersprache anzufangen zu argumentieren.

  11. Re: C-Bashing greift zu kurz

    Autor: pythoneer 09.04.14 - 18:30

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    > Mangelnde Eingabeprüfung ist ein so grundlegendes Problem, dass es in
    > meinen Augen wenig lohnt, mit der Programmiersprache anzufangen zu
    > argumentieren.

    Da finde ich z.b. diese "Tainted Objects/Data" aus Ruby/perl eine ganz gute Idee, die man weiterverfolgen könnte. Ich selber habe Ruby noch nicht für ein größeres Projekt eingesetzt und kann daher die Alltagstauglichkeit nicht beurteilen, die Idee an sich fand ich aber ganz nett.

    Sowas kann man auch ziemlich simpel (zumindest für C++/C#/Java und ähnliche Sprachen) selber zusammen schustern. http://www.codeproject.com/Articles/169504/A-Simple-Taint-Checking-Solution-for-C



    3 mal bearbeitet, zuletzt am 09.04.14 18:46 durch pythoneer.

  12. Re: Alternative

    Autor: Rock_Bottom 09.04.14 - 18:32

    bernd71 schrieb:
    --------------------------------------------------------------------------------
    > Welche Sprache kann man denn nehmen wenn man eine Bibliothek entwickeln
    > möchte die in möglichst vielen Programmiersprachen und Platformen verwendet
    > werden soll. Bleibt da noch was anderes als C?

    Die Frage würde mich auch mal ernsthaft interessieren. Gäbe es eine reale Alternative neben C?

  13. Re: C-Bashing greift zu kurz

    Autor: Gamma Ray Burst 09.04.14 - 18:38

    Stimmt.

    Allerdings glaube ich, dass es da elegantere Ansätze gibt. Ich weiß nicht bei welchem Problem man ein 10-20 Dimensionales Array braucht.

    Und wenn man schon Leute verwirren will, dann doch am Besten gleich mit rekursiven Aufrufen und einem Function Pointer Array gemischt mit einer verketten Liste.

  14. Re: C-Bashing greift zu kurz

    Autor: NeoTiger 09.04.14 - 19:24

    Wer behauptet, dass fehlerfreier Code nur eine Sache von Erfahrung und strenger Disziplin sei, demonstriert nur seine eigene Unerfahrenheit.

  15. Re: C-Bashing greift zu kurz

    Autor: chris m. 09.04.14 - 19:46

    ich fühl mich an diesen ccc talk von einer frau erinnert, in dem es quasi auch um null-terminated vs length prefixed (heartbleed) ging

    ich glaub, die schlussfolgerung war, dass daten am besten immer mit delimitern sein sollen, die nicht zur menge der nutzdaten gehören

    leider find ich das video nimmer :I

  16. Re: C-Bashing greift zu kurz

    Autor: hannob (golem.de) 09.04.14 - 19:56

    chris m. schrieb:
    --------------------------------------------------------------------------------
    > ich fühl mich an diesen ccc talk von einer frau erinnert, in dem es quasi
    > auch um null-terminated vs length prefixed (heartbleed) ging

    Du meinst vermutlich den hier:
    http://media.ccc.de/browse/congress/2011/28c3-4763-en-the_science_of_insecurity.html

  17. Re: C-Bashing greift zu kurz

    Autor: EWCH 09.04.14 - 20:08

    "ich glaub, die schlussfolgerung war, dass daten am besten immer mit delimitern sein sollen, die nicht zur menge der nutzdaten gehören"

    warum nicht beides ? Die Laenge an den Anfang zu schreiben erleichtert die
    Netzkommunikation. Und bei sicherheitsrelevanter Software sollte ein paar Byte
    mehr und ein Check mehr keine Rolle spielen.

  18. Re: C-Bashing greift zu kurz

    Autor: chris m. 09.04.14 - 20:30

    hannob (golem.de) schrieb:
    --------------------------------------------------------------------------------
    > chris m. schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ich fühl mich an diesen ccc talk von einer frau erinnert, in dem es
    > quasi
    > > auch um null-terminated vs length prefixed (heartbleed) ging
    >
    > Du meinst vermutlich den hier:
    > media.ccc.de

    ja, den meinte ich, danke! :)

  19. Re: C-Bashing greift zu kurz

    Autor: der_wahre_hannes 09.04.14 - 21:30

    Gamma Ray Burst schrieb:
    --------------------------------------------------------------------------------
    > Und wenn man schon Leute verwirren will, dann doch am Besten gleich mit
    > rekursiven Aufrufen und einem Function Pointer Array gemischt mit einer
    > verketten Liste.

    Für sowas gibt es doch Anleitungen: https://www.thc.org/root/phun/unmaintain.html
    ;)

    Mein Vor-vorgänger bei meinem derzeitigen Job muss sich ein paar dieser Ratschläge sehr zu Herzen genommen haben. Es macht einfach keinen Spaß, Code zu lesen, der mit
    string a, b, c, d, d2, f, g, h;
    anfängt...

  20. Re: C-Bashing greift zu kurz

    Autor: JP 09.04.14 - 21:48

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Das ist das klassische OpenSource-Problem: Code wird von Leuten in ihrer
    > "Freizeit" geschrieben, d.h. eher Helden-Code, wenig bis gar keine Tests
    > und schon gar keine externe QA die das mal auf Herz und Nieren prüft.
    >
    > Der Vorteil von OpenSource: es war schon gefixed bevor die Meldung durch
    > die Blogs ging.

    Oh was für eine Arroganz. Es mag sicherlich viele Open-Source Projekte geben die keine Tests/QA haben. Aber es eben auch viele Open-Source Projekte die sehr gut abgedeckt und gemanged sind. Und nun willst du erzählen, dass viele professionelle proprietäre Closed-Source Projekte grundsätzlich besser durch Tests/QA abgedeckt sind? Da tun sich in der Quote glaube ich beide Bereiche einfach nichts.

    Und an OpenSSL arbeiten sicherlich nicht mal irgendwelche Code-Helden, sondern Leute die schon Ahnung haben.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Stadtwerke München GmbH, München
  2. Hays AG, München
  3. Sky Deutschland GmbH, Unterföhring bei München
  4. Schwarz Dienstleistung KG, Raum Neckarsulm

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,99€
  2. 20,99€
  3. (-55%) 4,50€
  4. (-70%) 11,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Workflows: Wenn Digitalisierung aus 2 Papierseiten 20 macht
Workflows
Wenn Digitalisierung aus 2 Papierseiten 20 macht

Die Digitalisierung von Prozessen scheitert selten an der Technik. Oft ist es Unwissenheit über wichtige Grundregeln, die Projekte nach hinten losgehen lässt - ein wichtiges Change-Modell hilft dagegen.
Ein Erfahrungsbericht von Markus Kammermeier

  1. Digitalisierung Aber das Faxgerät muss bleiben!
  2. Arbeitswelt SAP-Chef kritisiert fehlende Digitalisierung und Angst
  3. Deutscher Städte- und Gemeindebund "Raus aus der analogen Komfortzone"

Grünheide: Umweltbewegung agiert bei Tesla-Fabrik unglücklich
Grünheide
Umweltbewegung agiert bei Tesla-Fabrik unglücklich

Es gibt gute Gründe, die Elektromobilität nicht nur unkritisch zu bejubeln. Einige Umweltverbände und Klimaaktivisten machen im Fall der Tesla-Fabrik in Grünheide dabei aber keine besonders gute Figur.
Ein IMHO von Hanno Böck

  1. Gigafactory Berlin Der "Tesla-Wald" ist fast gefällt
  2. Grünheide Tesla darf Wald weiter roden
  3. Gigafactory Grüne kritisieren Grüne Liga wegen Baumfällstopp für Tesla

Leistungsschutzrecht: Drei Wörter sollen ...
Leistungsschutzrecht
Drei Wörter sollen ...

Der Vorschlag der Bundesregierung für das neue Leistungsschutzrecht stößt auf Widerstand bei den Verlegerverbänden. Überschriften mit mehr als drei Wörtern und Vorschaubilder sollen lizenzpfichtig sein. Dabei wenden die Verlage einen sehr auffälligen Argumentationstrick an.
Eine Analyse von Friedhelm Greis

  1. Leistungsschutzrecht Memes sollen nur noch 128 mal 128 Pixel groß sein
  2. Leistungsschutzrecht Französische Verlage reichen Beschwerde gegen Google ein
  3. Leistungsschutzrecht Französische Medien beschweren sich über Google

  1. AMI: Citroën entwickelt kleines Elektroauto für 6.900 Euro
    AMI
    Citroën entwickelt kleines Elektroauto für 6.900 Euro

    Citroën hat mit dem AMI ein Elektroauto von der Studie zur Serienreife entwickelt. Das Fahrzeug für zwei Personen soll nur 6.900 Euro kosten. Dafür sind einige Abstriche erforderlich.

  2. Golem Akademie: IT-Sicherheit für Webentwickler
    Golem Akademie
    IT-Sicherheit für Webentwickler

    Welches sind die häufigsten Sicherheitslücken im Web, wie können sie ausgenutzt werden - und wie können Webentwickler ihnen begegnen? Diese Fragen beantwortet der Golem.de-Redakteur und IT-Sicherheitsexperte Hanno Böck in einem Workshop Ende März.

  3. Larian Studios: Baldur's Gate 3 rollenspielt mit Würfeln und Sekunden
    Larian Studios
    Baldur's Gate 3 rollenspielt mit Würfeln und Sekunden

    Die Klassiker bekommen endlich eine Fortsetzung: Golem.de konnte sich bei den Entwicklern die Welt und Neuerungen von Baldur's Gate 3 anschauen. Neben dem spektakulären Intro zeigen wir im Video auch, wie schön Fantasywelt und Kampfsystem in der Engine aussehen.


  1. 07:39

  2. 07:00

  3. 22:00

  4. 19:41

  5. 18:47

  6. 17:20

  7. 17:02

  8. 16:54