1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Security: Sicherheitslücke in Mac OS…

Meistens haengt es ja an C oder einem Derivat

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Meistens haengt es ja an C oder einem Derivat

    Autor: carsti 03.11.14 - 12:06

    Ich denke mittlerweile ist es hinreichend bewiesen, dass viele Sicherheitsluecken an C, Objective-C, C++ usw. haengen. Oft ist es auch die Toolchain die dahinter steckt.

    Aergert mich schon ein bischen, dass wir kurz vor 2015 noch immer nicht weiter sind als bei Windows95 :(

    Jedes Element des Programmierprozesses (Sprache, Toolchain, usw.) sollte darauf fokussiert sein, dass man selbst im besoffenen Zustand nur schwer Fehler produzieren kann die zu solchen Sicherheitslecks fuehren.

    Im Moment ist es doch so, dass bei der OS-Entwicklung selbst denn besten Leuten im ausgeruhten Zustand viele Fehler unterlaufen. Und der Ruf nach mehr Code-Reviews zur Fehlerbeseitigung ist zwar besser als gar nichts aber warum sorgt man nicht lieber dafuer, dass viele Fehler erst gar nicht passieren koennen?!

    Im Flugverkehr, im OP und in vielen anderen Bereichen hat man eben akzeptiert, dass man eben nicht den Menschen beschuldigen kann fuer kleine Nachlaessigkeiten. Das System darf solche Nachlaessigkeiten erst gar nicht zulassen.

    Android macht es leicht besser. Da ist es Standard, dass 100% der 0815 Apps eben nicht mit C oder einem Derivat geschrieben werden. Ein gutes Beispiel fuer Sicherheit ist Android damit alleine nicht aber es ist ein Anfang.

  2. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: al-bundy 03.11.14 - 12:12

    Was für ein Quatsch.

  3. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: carsti 03.11.14 - 12:19

    al-bundy schrieb:
    --------------------------------------------------------------------------------
    > Was für ein Quatsch.

    Genau. Beim Thema Softwaresicherheit haben wir seit Jahren das Maximum erreicht.

  4. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: al-bundy 03.11.14 - 12:21

    Mit Quatsch waren deine Einlassungen gemeint. Aber das weisst du ja.

  5. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: andi_lala 03.11.14 - 12:24

    carsti schrieb:
    --------------------------------------------------------------------------------
    > Android macht es leicht besser. Da ist es Standard, dass 100% der 0815 Apps
    > eben nicht mit C oder einem Derivat geschrieben werden. Ein gutes Beispiel
    > fuer Sicherheit ist Android damit alleine nicht aber es ist ein Anfang.
    Für iOS gibt es ja mittlerweile auch Swift und selbst Objective-C ist unter iOS auch kein so großes Problem, da Apps in einer Sandbox laufen und die vollständige Plattform API ihnen nicht zur Verfügung steht.
    Android selbst ist aber auch nicht in Java geschrieben, sonst wäre die Performance wohl noch deutlich schlechter und das Problem hier sind ja nicht 3rd Party Apps, sondern das Betriebsystem selbst.
    Edit:
    Noch was, auch unter Android gibt es Apps, die C verwenden um eine bessere Performance zu erreichen. Es sind also nicht 100% der Apps in Java geschrieben, siehe hierzu [developer.android.com]



    1 mal bearbeitet, zuletzt am 03.11.14 12:27 durch andi_lala.

  6. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: ( Alternativ: kostenlos registrieren) 03.11.14 - 12:32

    selten so einen blödsinn gelesen.

    wieso sollte C unsicherer sein als Java bei Android? Wegen der Speicherverwaltung für Dummies die Java mitbringt? Sicher nicht.

    carsti schrieb:
    --------------------------------------------------------------------------------
    > Ich denke mittlerweile ist es hinreichend bewiesen, dass viele
    > Sicherheitsluecken an C, Objective-C, C++ usw. haengen. Oft ist es auch die
    > Toolchain die dahinter steckt.
    >
    > Aergert mich schon ein bischen, dass wir kurz vor 2015 noch immer nicht
    > weiter sind als bei Windows95 :(
    >
    > Jedes Element des Programmierprozesses (Sprache, Toolchain, usw.) sollte
    > darauf fokussiert sein, dass man selbst im besoffenen Zustand nur schwer
    > Fehler produzieren kann die zu solchen Sicherheitslecks fuehren.
    >
    > Im Moment ist es doch so, dass bei der OS-Entwicklung selbst denn besten
    > Leuten im ausgeruhten Zustand viele Fehler unterlaufen. Und der Ruf nach
    > mehr Code-Reviews zur Fehlerbeseitigung ist zwar besser als gar nichts aber
    > warum sorgt man nicht lieber dafuer, dass viele Fehler erst gar nicht
    > passieren koennen?!
    >
    > Im Flugverkehr, im OP und in vielen anderen Bereichen hat man eben
    > akzeptiert, dass man eben nicht den Menschen beschuldigen kann fuer kleine
    > Nachlaessigkeiten. Das System darf solche Nachlaessigkeiten erst gar nicht
    > zulassen.
    >
    > Android macht es leicht besser. Da ist es Standard, dass 100% der 0815 Apps
    > eben nicht mit C oder einem Derivat geschrieben werden. Ein gutes Beispiel
    > fuer Sicherheit ist Android damit alleine nicht aber es ist ein Anfang.

  7. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: carsti 03.11.14 - 12:36

    Ich kenne das NDK. Und wie ich oben schreibe ist fuer 100% der STANDARDAPPS der Code eben nicht C/C++.

    Ich beschwere mich uebrigens nicht, dass unter der Haube C/C++ steckt. Zumindest im Moment kann man das nicht ganz entfernen. Jedoch koennte man den Bereich von C/C++ auf den absoluten Kernbereich des OS beschraenken. Alles darueber (also Anwendersoftware) sollte eben nicht mehr in C/C++ geschrieben werden - vor allem nicht ohne triftigen Grund.

    Vor allem mit ART ist es schwer normale Anwenderapps zu schreiben die langsamer sind als wenn man alles mit dem NDK machen wuerde. Spiele ausgenommen!

    Es gibt absolut keinen Grund mehr heute fuer Anwenderapps ausser Spielen und aehnlich extrem grafiklastigem noch irgendwas wie C/C++ zu verwenden.

  8. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: ( Alternativ: kostenlos registrieren) 03.11.14 - 12:40

    Doch.

    Ein Beispiel: Mir gefällt C++ als Sprache besser als beispielsweise Java. Daher verwend ich C++. Und nicht Java. Und Pointer hab ich so wahnsinnig lieb und sie mich auch. Wieder ein Grund mehr. Brauchst du noch welche?

    carsti schrieb:
    --------------------------------------------------------------------------------
    > Es gibt absolut keinen Grund mehr heute fuer Anwenderapps ausser Spielen
    > und aehnlich extrem grafiklastigem noch irgendwas wie C/C++ zu verwenden.

  9. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: carsti 03.11.14 - 12:47

    ( Alternativ: kostenlos registrieren) schrieb:
    --------------------------------------------------------------------------------
    > selten so einen blödsinn gelesen.
    >
    > wieso sollte C unsicherer sein als Java bei Android? Wegen der
    > Speicherverwaltung für Dummies die Java mitbringt? Sicher nicht.

    Wie war das nochmal beim OpenSSL Bug? Die haben ihren eigenen Allokator gebaut? Aus deiner Sicht sind in dem Fall die Programmierer die dummen nehme ich an? Warum duerfen die das ueberhaupt? http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

    Oder Apple goto fail bug?

    Oder oder oder!

    Warum haben neue Autos tausende Funktionen eingebaut, die verhindern, dass man erst gar keinen Quatsch bauen darf?! Mittlerweile piepst es sogar wenn einem als Fahrer die Augen zufallen oder wenn man nicht richtig angeschnallt ist, die Handbremse noch festgestellt ist oder man sich einem Objekt bei Rueckwaertsfahren naehert. Oft gibt es dann noch eine Kamera damit man sieht was hinter dem Auto los ist. Und das waren nur eine handvoll Beispiele.

    Die Leute die hier C/C++ Einsatz (ausser fuer den inner core des OS) verteidigen fahren wohl auch noch mit ihrem durchgerosteten Oldtimer auf der Autobahn ohne Sicherheitsgurte, Spiegel oder sonstigen Kram der viele Fehler von vorneherein ausschliesst.

    Dann nenn doch mal ein paar Mechanismen bei C/C++ die Fehler von vorneherein ausschliessen?! Bei den Toolchains hat sich einiges getan. Aber viel viel zu wenig!

  10. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: carsti 03.11.14 - 12:50

    ( Alternativ: kostenlos registrieren) schrieb:
    --------------------------------------------------------------------------------
    > Doch.
    >
    > Ein Beispiel: Mir gefällt C++ als Sprache besser als beispielsweise Java.
    > Daher verwend ich C++. Und nicht Java. Und Pointer hab ich so wahnsinnig
    > lieb und sie mich auch. Wieder ein Grund mehr. Brauchst du noch welche?
    >
    > carsti schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Es gibt absolut keinen Grund mehr heute fuer Anwenderapps ausser Spielen
    > > und aehnlich extrem grafiklastigem noch irgendwas wie C/C++ zu verwenden.


    Genau. Gewohnheit. Eigensinn. Nostalgie. Wenn du zufaellig 10 Jahre frueher oder spaeter geboren worden waerst wuerdest du Cobol, Fortran77 oder C# nutzen :)

    Ich lesen keinen einzigen sachlichen Grund in deinen Ausfuehrungen warum man es Programmierern erlauben sollte mit Zeigern rumzuspielen wenn es lediglich um 0815 Standardapps (keine Spiele) geht, wo es doch eindeutig auf Kosten der Sicherheit geht OHNE irgendwelchen Mehrwert?

  11. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: Anonymer Nutzer 03.11.14 - 12:52

    Ja, schaffen wir auch noch den Maschinencode ab, damit da nicht auch noch ... oh wait!

    Echt selten so einen Humbug gelesen.

  12. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: carsti 03.11.14 - 12:58

    Ja: Maschinencode sollte nur der Compiler ausgeben! Ich hoffe selbst bei Spielen schreibt keiner mehr selbst Maschinencode?!

    Einfach "Humbug" schreien und nicht ein einziges Gegenargument. Dann geh doch mal Schritt fuer Schritt die Analyse durch die ich oben und jetzt hier nochmal zitiert habe und entkraefte die "Lesson" am Ende! Ach, eh alles Humbug? Okay...schon kapiert :D


    http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

    Lessons
    What can we learn from this?

    I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before.

    Between this and the GnuTLS bug, I think that we need to do three things:

    Pay money for security audits of critical security infrastructure like OpenSSL
    Write lots of unit and integration tests for these libraries
    Start writing alternatives in safer languages
    Given how difficult it is to write safe C, I don't see any other options.

  13. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: Anonymer Nutzer 03.11.14 - 13:09

    Ich programmiere seit ueber 35 Jahren und habe mit Hex-Werten in den Speicher poken auf dem PET2001 ueber Trash'M-One auf dem Amiga bis zur heutigen Programmierung in allen moeglichen Sprachen auf dem PC, Mobile und Konsolen alles durch was geht. Und glaube mir, ich kenne den Wahnsinn des Overheads von C#, Java und Co. der dann auf der Maschinenebene ankommt. Da behaupte ich das sich da wesentlich mehr Fehler einschleichen als wenn ich das in Maschinencode oder C zusammensetze, ist naemlich eine Sache des Codes den man selber pflegt.

    Und meine "Analyse" heisst Erfahrung und nicht Berichte von $Leuten aus $Netzforen ...



    1 mal bearbeitet, zuletzt am 03.11.14 13:13 durch Humma Kavula.

  14. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: ( Alternativ: kostenlos registrieren) 03.11.14 - 13:12

    So Schwachsinnig die Argumentationslinie von carsti ist, das von dir ist nicht viel besser.

    Ich bin kein Fan von C# oder Java, aber das Argument mit "ich kenne den Wahnsinn des Overheads von C#, Java und Co. der dann auf der Maschinenebene ankommt" ist ja Schwachsinn pur. Wenn du wüstest wie unglaublich bis ins letzte optimiert die CLI --> CLR Chain ist würdest du sowas nicht absondern.

    Humma Kavula schrieb:
    --------------------------------------------------------------------------------
    > Ich programmiere seit ueber 35 Jahren und habe mit Hex-Werten in den
    > Speicher poken auf dem C64 ueber Trash'M-One auf dem Amiga bis zur heutigen
    > Programmierung in allen moeglichen Sprachen auf dem PC, Mobile und Konsolen
    > alles durch was geht. Und glaube mir, ich kenne den Wahnsinn des Overheads
    > von C#, Java und Co. der dann auf der Maschinenebene ankommt. Da behaupte
    > ich das sich da wesentlich mehr Fehler einschleichen als wenn ich das in
    > Maschinencode oder C zusammensetze, ist naemlich eine Sache des Codes den
    > man selber pflegt.
    >
    > Und meine "Analyse" heisst Erfahrung und nicht Berichte von $Leuten aus
    > $Netzforen ...

  15. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: Anonymer Nutzer 03.11.14 - 13:19

    CLI -> CLR mag optimiert sein, aber C# -> CLI ist es z.b. definitiv nicht.

    Und ich bin nunmal generell kein Fan von irgendwelchen Zwischenschichten, wozu auch ...



    1 mal bearbeitet, zuletzt am 03.11.14 13:21 durch Humma Kavula.

  16. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: The-Master 03.11.14 - 13:19

    al-bundy schrieb:
    --------------------------------------------------------------------------------
    > Was für ein Quatsch.


    Aber natürlich, wenn das so ist, ist das alles gleich in einem ganz anderen licht.
    Wie konnte ich diese stichhaltigen argumente nur übersehen?

    Deine aussage überzeugt auf ganzer linie.


    /ironie

  17. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: andi_lala 03.11.14 - 13:35

    carsti schrieb:
    --------------------------------------------------------------------------------
    > Oder Apple goto fail bug?
    Davor schützt dich aber Java genau so wenig wie C#, denn der Bug ist entstanden, weil bei einer If-Anweisung kein Block-Syntax verwendet wurde. Das wäre bei Java und Co genau so möglich gewesen. Außerdem gibt es auch bei C++ Entwicklungen, die einen vor Fehlern schützen bzw. warnen. Wenn man die nicht nützt ist das etwas anderes, aber ich gebe dir recht, dass man für den Großteil der Anwendungen keine derartigen Low-Level Sprachen wie C/C++ benötigt und der Trend geht ja eh in diese Richtung.

  18. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: tomate.salat.inc 03.11.14 - 13:35

    Für Plattformunabhängige Pakete wäre C/C++ z.B. sinnvoll. Diese werden für die jeweilige Plattform einmal kompiliert und deine Geschäftslogik läuft auf allen Plattformen. In der nativen Sprache (Swift/C#/Java/...) greifst du dann auf die dll/so/... zurück und musst die Logik nicht x mal neu schreiben.

  19. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: Trollversteher 03.11.14 - 13:48

    Nett gemeint, aber leider völlig an der Praxis vorbei...

    Eine "Idiotensichere" Programmiersprache gibt es nicht. Wer glaubt, mit einer Interpretersprache/sandboxed Sprache würde man per se weniger Sicherheitslücken produzieren können irrt und hat vermutlich nicht sonderlich viel Praxis Erfahrung.

    Natürlich sind gewisse Dinge in einer sandboxed Umgebung nicht erlaubt, aber native Sprachen wie C und C++ werden ja nicht aus reiner Spass an der Freude eingesetzt, sondern weil sie in gewissen Anwendungen eben unabdingbar sind. Und Treiber/Kernelroutinen schreibt man eben nicht in Java.
    Egal wieviele Schichten Du in einem System aufbaust, die untersten Schichten so wie performancehungrige Komponenten werden immer maschinennah nativ implementiert sein.

    Von daher hilft tatsächlich nur, die QR Prozesse zu verbessern.

  20. Re: Meistens haengt es ja an C oder einem Derivat

    Autor: carsti 03.11.14 - 14:09

    Humma Kavula schrieb:
    --------------------------------------------------------------------------------
    > CLI -> CLR mag optimiert sein, aber C# -> CLI ist es z.b. definitiv nicht.
    >
    > Und ich bin nunmal generell kein Fan von irgendwelchen Zwischenschichten,
    > wozu auch ...

    Hehe...wozu auch! Genial :D

    Du bist echt das Paradebeispiel fuer jemanden den ich meine. Besser geht eigentlich nicht mehr :D
    Fehler machen nur die OHNE Ahnung!

    Und der Overhead den Java z.B. raushaut ist verglichen mit C/C++ nicht so riesig. Die Sun JVM tut da wunder (und von dem Code den die ausspuckt hast du bestimmt noch nie was gesehen, oder?). Uebrigens schaut euch mal den Code an, den LLVM rausspuckt. Da ist auch sehr viel Overhead zu handgeschriebenen Maschinencode drin weil es oft nicht besser geht um Spezialfaelle abzudecken.

    Performance und Overhead ist schon lange kein Thema bei Java oder C# mehr. Vor allem wenns ums Thema Sicherheit geht.

    Disclaimer: ich bin jetzt wirklich kein Java/C# Fan und kenne C/C++ von der Pike auf.

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. operational services GmbH & Co. KG, München
  2. Stadtwerke München GmbH, München
  3. BSI Systeme GmbH, Mönchengladbach
  4. über duerenhoff GmbH, Hannover

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 349,00€
  2. (aktuell u. a. Deepcool Castle 240EX Wasserkühlung für 109,90€, Asus VG248QZ LED-Monitor 169...
  3. (u. a.Battlefield V für 21,49€ und Star Wars Jedi: Fallen Order für 52,99€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Tesla-Fabrik in Brandenburg: Remote, Germany
Tesla-Fabrik in Brandenburg
Remote, Germany

Elon Musk steht auf Berlin, doch industrielle Großprojekte sind nicht die Stärke der Region. Ausgerechnet in die Nähe der ewigen Flughafen-Baustelle BER will Tesla seine Gigafactory 4 platzieren. Was spricht für und gegen den Standort Berlin/Brandenburg?
Eine Analyse von Dirk Kunde

  1. Gigafactory Tesla soll 4 Milliarden Euro in Brandenburg investieren
  2. 7.000 Arbeitsplätze Tesla will Gigafactory bei Berlin bauen
  3. Irreführende Angaben Wettbewerbszentrale verklagt Tesla wegen Autopilot-Werbung

Neuer Streamingdienst von Disney: Disney+ ist stark bei Filmen und schwach bei Serien
Neuer Streamingdienst von Disney
Disney+ ist stark bei Filmen und schwach bei Serien

Das Hollywoodstudio Disney ist in den Markt für Videostreamingabos eingestiegen. In den USA hat es beim Start von Disney+ technische Probleme gegeben. Mit Blick auf inhaltliche Vielfalt kann der Dienst weder mit Netflix noch mit Amazon Prime Video mithalten.
Von Ingo Pakalski

  1. Disney+ Disney korrigiert falsches Seitenverhältnis bei den Simpsons
  2. Videostreaming im Abo Disney+ hat 10 Millionen Abonnenten
  3. Disney+ Disney bringt seinen Streaming-Dienst auf Fire-TV-Geräte

Autonomes Fahren: Wenn der Wagen das Volk nicht versteht
Autonomes Fahren
Wenn der Wagen das Volk nicht versteht

VW testet in Hamburg das vollautonome Fahren in der Stadt - und das recht erfolgreich, wie eine Probefahrt zeigt. Als größtes Problem erweist sich ausgerechnet die Höflichkeit der Fußgänger.
Ein Bericht von Werner Pluta

  1. Elektroauto Volkswagen ID.3 wird auch in Dresden montiert
  2. Volkswagen ID. Space Vizzion als Elektrokombi vorgestellt
  3. Elektroauto von VW Es hat sich bald ausgegolft

  1. Microvast: US-Akkuhersteller produziert bald in Brandenburg
    Microvast
    US-Akkuhersteller produziert bald in Brandenburg

    Brandenburg meldet eine weitere Investition im Bereich Elektromobilität. Der US-Hersteller Microvast verlegt seinen Europasitz nach Ludwigsfelde und will dort Akkus für Fahrzeuge herstellen.

  2. Elektroauto: Audi stellt E-Tron Sportback mit Pixellicht vor
    Elektroauto
    Audi stellt E-Tron Sportback mit Pixellicht vor

    Audi hat sich als Teil des VW-Konzerns der Elektromobilität verschrieben und nun mit dem E-Tron Sportback das nächste Modell seiner Elektroautoserie offiziell vorgestellt. Das Fahrzeug ist ein SUV-Coupé mit einer Reichweite von rund 450 km.

  3. Nubia Z20 im Test: Zwei Bildschirme statt einer Frontkamera
    Nubia Z20 im Test
    Zwei Bildschirme statt einer Frontkamera

    Die ZTE-Tochter Nubia experimentiert mit Smartphones, die keine Frontkamera, dafür aber zwei Displays haben. Beim neuen Z20 ist der rückseitige Bildschirm auf den ersten Blick kaum zu erkennen. Das Handling der beiden Screens funktioniert gut, die Software braucht aber noch etwas Feinschliff.


  1. 09:38

  2. 09:24

  3. 09:03

  4. 07:59

  5. 18:54

  6. 18:52

  7. 18:23

  8. 18:21