1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Linux: Sicherheitslücke in Systemd

So ist es halt mit 70er-Jahre-Sprachen

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. So ist es halt mit 70er-Jahre-Sprachen

    Autor: Hello_World 29.10.18 - 22:57

    Es ist unverantwortlich, heutzutage noch Software in C zu schreiben, und dieser Vorfall beweist dies wieder einmal eindrücklich. Denn egal, wie gut die Entwickler sind – und die systemd-Entwickler gehören sicherlich zu den besten – irgendwann übersieht man doch irgendein kleines Detail, und schon hat man einen Buffer Overflow. Das Problem ist, dass C weder zur Lauf- noch zur Compilezeit ausreichende Garantien bietet, um Sicherheitslücken zu verhindern. Hinzu kommt, dass die Sprache schlichtweg nicht die Möglichkeiten bietet, um die Abstraktionen zu entwickeln, die die Grundlage für moderne, robuste Software bilden. Und wer das bestreitet, hat wahrscheinlich noch nie eine ordentliche Programmiersprache aus der Nähe gesehen (oder er hat sie nicht verstanden).



    1 mal bearbeitet, zuletzt am 29.10.18 22:57 durch Hello_World.

  2. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: Crmro 29.10.18 - 23:22

    Welche wäre denn so eine ordentliche Programmiersprache?

  3. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: shoggothe 29.10.18 - 23:31

    C wird im Lowlevel-Bereich eingesetzt, weil es keine Abstraktionen beinhaltet. Man kann genau sehen wo welches Byte landet. Und wer das bestreitet, hat wahrscheinlich noch nie eine ordentliche Programmiersprache aus der Nähe gesehen (oder er hat sie nicht verstanden).

  4. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: Hello_World 29.10.18 - 23:38

    Ganz allgemein gesprochen würde ich auf statisch typisierte, funktionale Sprachen setzen. Beispiele sind Haskell, Ocaml, Scala, aber es gibt natürlich noch viele mehr. Für den Low-Level-Bereich gibt es beispielsweise Rust.

  5. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: Hello_World 29.10.18 - 23:49

    shoggothe schrieb:
    --------------------------------------------------------------------------------
    > C wird im Lowlevel-Bereich eingesetzt, weil es keine Abstraktionen
    > beinhaltet.
    Das würde Sinn ergeben, wenn jede Form von Abstraktion zwangsläufig Laufzeit- oder Speicheroverhead mit sich bringen würde. Das ist aber nicht der Fall, beispielsweise könnte man Generics mittels Erasure implementieren. Der Overhead gegenüber dem, was man heute macht, wenn man generischen Code will (nämlich void-Pointer) wäre gleich 0.

    > Man kann genau sehen wo welches Byte landet.
    Nein, kann man nicht, sehr viel Verhalten in C ist implementierungsspezifisch (Alignment, struct-Padding, Endianness etc. pp.)

    > Und wer das
    > bestreitet, hat wahrscheinlich noch nie eine ordentliche Programmiersprache
    > aus der Nähe gesehen (oder er hat sie nicht verstanden).
    Ich habe jahrelang als C-Entwickler gearbeitet, und gerade _weil_ ich die Sprache kenne, weiß ich, welche gravierenden Schwächen sie aufweist. Glücklicherweise steht mit Rust mittlerweile eine weit überlegene Alternative bereit.



    1 mal bearbeitet, zuletzt am 29.10.18 23:50 durch Hello_World.

  6. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: shoggothe 30.10.18 - 00:24

    Type Erasure kennt man aus Java. In Java hat jedes Object einen 12 Byte Overhead gegenüber einem C-Zeiger. Wie würde man einen Kernel in Java implementieren wobei auf Cache-Lokalität zu achten ist? Man kann in Java strukturierte Daten nicht dicht packen (es geht immer noch um Low Level-Programming).

    Ich habe jahrelang Java, C, C++ (und mit anderen Sprachen) entwickelt und bin jetzt bei Go gelandet.

  7. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: mnementh 30.10.18 - 00:39

    shoggothe schrieb:
    --------------------------------------------------------------------------------
    > C wird im Lowlevel-Bereich eingesetzt, weil es keine Abstraktionen
    > beinhaltet. Man kann genau sehen wo welches Byte landet. Und wer das
    > bestreitet, hat wahrscheinlich noch nie eine ordentliche Programmiersprache
    > aus der Nähe gesehen (oder er hat sie nicht verstanden).
    Ehrlich? Was ist mit Integer-Typen, die von Plattform zu Plattform unterschiedliche Bitbreiten haben? Oder mit undefiniertes Programmen[1]? C hat viele Unwägbarkeiten. Es ist einfach nur alt genug und hat sich vor moderneren Sprachen verbreiten können. Das ist alles.

    [1] https://de.wikipedia.org/wiki/Undefiniertes_Verhalten

  8. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: honna1612 30.10.18 - 00:40

    in zukunft nur noch RUST
    Keine bufferoverflows oder implizite speicherleaks.
    Geschwindigkeit gleich bis SCHNELLER weil SIMD intrinsic nicht überlappen darf und das in C nicht garantiert werden kann.

  9. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: shoggothe 30.10.18 - 00:54

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > shoggothe schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > C wird im Lowlevel-Bereich eingesetzt, weil es keine Abstraktionen
    > > beinhaltet. Man kann genau sehen wo welches Byte landet. Und wer das
    > > bestreitet, hat wahrscheinlich noch nie eine ordentliche
    > Programmiersprache
    > > aus der Nähe gesehen (oder er hat sie nicht verstanden).
    > Ehrlich? Was ist mit Integer-Typen, die von Plattform zu Plattform
    > unterschiedliche Bitbreiten haben? Oder mit undefiniertes Programmen[1]? C
    > hat viele Unwägbarkeiten. Es ist einfach nur alt genug und hat sich vor
    > moderneren Sprachen verbreiten können. Das ist alles.
    >
    > [1] de.wikipedia.org

    Nenne die moderneren Sprachen die C ablösen.
    Der zweite Satz war nur die Wiederholung des gleichen "Arguments" des Davorposters gegen ihn selbst.

    Ich selbst mag Go. Aber selbst das kann C nicht ablösen, wenn es um Low-Level-Code geht.

  10. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: tingelchen 30.10.18 - 01:23

    > > C wird im Lowlevel-Bereich eingesetzt, weil es keine Abstraktionen
    > > beinhaltet.
    > Das würde Sinn ergeben, wenn jede Form von Abstraktion zwangsläufig
    > Laufzeit- oder Speicheroverhead mit sich bringen würde. Das ist aber nicht
    > der Fall, beispielsweise könnte man Generics mittels Erasure
    > implementieren. Der Overhead gegenüber dem, was man heute macht, wenn man
    > generischen Code will (nämlich void-Pointer) wäre gleich 0.
    >
    Ja, void* ist eine Krankheit ^^ Die Sprache ist alt. Ja, aber nicht schlecht. Sie ist sehr einfach, Hardwarenahe und vor allem schnell. Sie kann natürlich einige Konstrukte nicht. Auch gibt es für diverse Anwendungen keinen direkten Typ. So sind z.B. Strings eine echte Krankheit in C.

    > > Man kann genau sehen wo welches Byte landet.
    > Nein, kann man nicht, sehr viel Verhalten in C ist
    > implementierungsspezifisch (Alignment, struct-Padding, Endianness etc.
    > pp.)
    >
    Läst sich in einigen Compilern einstellen, bzw. ist in diesen definiert. Teils geht dies sogar per Präfix Anweisung. Daher ja, man kann exakt bestimmen welches Byte, sogar welches Bit wo landet.

    > > Und wer das
    > > bestreitet, hat wahrscheinlich noch nie eine ordentliche
    > Programmiersprache
    > > aus der Nähe gesehen (oder er hat sie nicht verstanden).
    > Ich habe jahrelang als C-Entwickler gearbeitet, und gerade _weil_ ich die
    > Sprache kenne, weiß ich, welche gravierenden Schwächen sie aufweist.
    > Glücklicherweise steht mit Rust mittlerweile eine weit überlegene
    > Alternative bereit.
    >
    Mittlerweile. Wobei Rust noch immer so ein paar Dinge hat, die ebenfalls eine Krankheit sind. Turbo Fish inc :D Aber der könnte in Zukunft auch, glücklicherweise, verschwinden ^^

  11. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: Hello_World 30.10.18 - 08:56

    Der aussichtsreichste C-Konkurrent wurde schon mehrfach hier genannt: Go.

  12. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: Hello_World 30.10.18 - 09:33

    Argh! Ich meinte natürlich Rust, nicht Go!

  13. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: Hello_World 30.10.18 - 09:41

    shoggothe schrieb:
    --------------------------------------------------------------------------------
    > Type Erasure kennt man aus Java. In Java hat jedes Object einen 12 Byte
    > Overhead gegenüber einem C-Zeiger. Wie würde man einen Kernel in Java
    > implementieren wobei auf Cache-Lokalität zu achten ist?
    „Linsen kennt man aus Linseneintopf. In Linseneintopf sind Würstchen drin, die bekanntlich Fleisch enthalten. Wie würde man ein vegetarisches Gericht mit Linsen kochen, wobei auf die Abwesenheit von Fleischprodukten zu achten ist?“

    Ungefähr so viel Sinn macht deine Aussage. Aber Spaß beiseite: die 12 Byte Overhead haben exakt gar nichts mit Erasure oder Generics zu tun, sondern mit Introspektion, Garbage Collection und Locking. Deswegen war dieser Header auch schon lange bevor die Generics in Java eingeführt wurden vorhanden.

    > Man kann in Java
    > strukturierte Daten nicht dicht packen (es geht immer noch um Low
    > Level-Programming).
    Es ging hier aber zu keinem Zeitpunkt um Java.

  14. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: bernd71 30.10.18 - 13:46

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > Ganz allgemein gesprochen würde ich auf statisch typisierte, funktionale
    > Sprachen setzen. Beispiele sind Haskell, Ocaml, Scala, aber es gibt
    > natürlich noch viele mehr. Für den Low-Level-Bereich gibt es beispielsweise
    > Rust.

    Vor allem war Rust ja schon einsatzbereit als man mit systemd startete.

  15. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: sodom1234 30.10.18 - 14:41

    wenn ich das schon lese "unverantworklich" ..

    man kann in jeder Sprache Scheiße bauen in einigen leichter als in anderen.

  16. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: Hello_World 30.10.18 - 15:55

    tingelchen schrieb:
    --------------------------------------------------------------------------------
    > Ja, void* ist eine Krankheit ^^ Die Sprache ist alt.
    Das Alter ist nicht das Problem, sondern die Fehleranfälligkeit. Anfang der 70er, also wenige Jahre nach C, wurde ML entwickelt. Da sind schon all die Sachen enthalten, die eine ordentliche Programmiersprache ausmachen: Lambdas, statische Typen, Typinferenz, parametrischer Polymorphismus (aka Generics).

    > Ja, aber nicht
    > schlecht.
    Doch, schlecht.

    > Sie ist sehr einfach, Hardwarenahe und vor allem schnell.
    networkd ist ein Daemon zur Netzwerkkonfiguration, der also 99,999% der Zeit gar nix tut. Performance ist so ungefähr das letzte, was bei solcher Software eine Rolle spielt. Was hingegen eine Rolle spielt, sind Sicherheitslücken.

    > Sie
    > kann natürlich einige Konstrukte nicht. Auch gibt es für diverse
    > Anwendungen keinen direkten Typ. So sind z.B. Strings eine echte Krankheit
    > in C.
    Das Problem ist aber nicht, dass es keine Strings gibt, sondern dass die Sprache es schwer macht, eine ordentliche String-Bibliothek zu schreiben. Natürlich gibt es trotzdem String-Bibliotheken, aber die sind dann halt immer noch unbequem.

    > Läst sich in einigen Compilern einstellen, bzw. ist in diesen definiert.
    Mit anderen Worten: es ist nicht im C-Standard definiert. Danke, dass Du das bestätigst. Klar, es gibt Compiler, die diesbezüglich weitere Garantien bieten, aber das ist dann eben nicht mehr C sondern GNU-C, oder Microsoft-C oder was auch immer.

    > Teils geht dies sogar per Präfix Anweisung.
    „Präfix-Anweisung“ gibt es in C nicht, Du meinst wohl Pragma. Das ist aber erst recht nicht standardisiert. Du hast übrigens noch nicht erklärt, warum man das für ein Netzwerk-Konfigurationstool überhaupt brauchen sollte.

    > Daher ja, man kann exakt
    > bestimmen welches Byte, sogar welches Bit wo landet.
    Bits schon gar nicht, da C keinerlei Garantien über die Repräsentation auf Bitebene liefert.

    > Mittlerweile. Wobei Rust noch immer so ein paar Dinge hat, die ebenfalls
    > eine Krankheit sind. Turbo Fish inc :D Aber der könnte in Zukunft auch,
    > glücklicherweise, verschwinden ^^
    Die Probleme von Rust sind nicht ansatzweise so gravierend wie die von C.

  17. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: Hello_World 30.10.18 - 16:01

    sodom1234 schrieb:
    --------------------------------------------------------------------------------
    > wenn ich das schon lese "unverantworklich" ..
    >
    > man kann in jeder Sprache Scheiße bauen in einigen leichter als in anderen.
    Ja, und? Früher hatten die Kreissägen keine Schutzhauben, und wenn man unachtsam hingelangt hat, war der Finger ab. Heute haben sie einen, und ein Arbeitgeber, der seine Tischler mit einer Kreissäge ohne geeignete Sicherheitsvorkehrungen arbeiten lässt, handelt unverantwortlich. Ich weiß gar nicht, warum so etwas kontrovers sein sollte.

  18. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: Hello_World 30.10.18 - 16:03

    > Vor allem war Rust ja schon einsatzbereit als man mit systemd startete.
    Es gab auch damals schon brauchbare Programmiersprachen, die waren halt nicht so tauglich für Low-Level-Arbeit wie Rust es ist. Das braucht man für ein Netzwerk-Konfigurationstool wie networkd aber auch nicht.

  19. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: sodom1234 30.10.18 - 17:25

    ich habe mir einfach eine Schutzhabe gekauft (Valgrind) und gut war. Musst mir deswegen keine komplett neue Säge kaufen.

  20. Re: So ist es halt mit 70er-Jahre-Sprachen

    Autor: Hello_World 30.10.18 - 18:04

    Valgrind kann nur Fehler erkennen, die beim Testen auch tatsächlich ausgelöst werden. Wenn überhaupt, dann könnte man an der Stelle Fuzzing-Tools nennen… IMO ist das aber auch nur herumdoktorn an den Symptomen, die durch eine veraltete Programmiersprache verursacht werden.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. PASCAL Beratungsgesellschaft für Datenverarbeitung m.b.H., Stuttgart, Hamburg-Altona
  2. Vodafone GmbH, Unterföhring
  3. Bahlsen GmbH & Co. KG, Berlin
  4. Universität Potsdam, Potsdam

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Lenovo Q27q 27 Zoll IPS WQHD FreeSync für 223,23€, Lenovo Legion 5 15,6 Zoll FHD IPS...
  2. 629€ (Vergleichspreis: 721€)
  3. (aktuell u. a. Das neue Fire HD 8 Kids Edition-Tablet für 92,58€, Hoseili Bluetooth-In-Ear für...


Haben wir etwas übersehen?

E-Mail an news@golem.de


UX-Designer: Computer sind soziale Akteure
UX-Designer
"Computer sind soziale Akteure"

User Experience Designer schaffen positive Erlebnisse, wenn Nutzer IT-Produkte verwenden. Der Job erfordert Liebe zum Detail und den Blick fürs große Ganze.
Ein Porträt von Louisa Schmidt

  1. Coronapandemie Viele IT-Freelancer erwarten schlechtere Auftragslage
  2. IT-Fachkräftemangel Es müssen nicht immer Informatiker sein
  3. Jobporträt IT-Produktmanager Der Alleversteher

Norbert Röttgen: Kandidat für CDU-Vorsitz streut alternative Fakten zu 5G
Norbert Röttgen
Kandidat für CDU-Vorsitz streut alternative Fakten zu 5G

In der explosiven Situation zwischen den USA und China zündelt Norbert Röttgen, CDU-Politiker mit Aspirationen auf den Parteivorsitz und die Kanzlerschaft, mit unrichtigen Aussagen zu 5G und Huawei.
Eine Analyse von Achim Sawall

  1. Handelskrieg Australiens Regierung greift Huawei wegen Rechenzentrum an
  2. 5G Verbot von Huawei in Deutschland praktisch ausgeschlossen
  3. Smartphone Huawei gehen die SoCs aus

8Sense im Test: Vibration am Kragen gegen Schmerzen im Rücken
8Sense im Test
Vibration am Kragen gegen Schmerzen im Rücken

Das Startup 8Sense will mit einem Ansteckclip einer Bürokrankheit entgegenwirken: Rückenschmerzen. Das funktioniert - aber nicht immer.
Ein Test von Oliver Nickel

  1. Rufus Cuff Handgelenk-Smartphone soll doch noch erscheinen
  2. Fitnesstracker im Test Aldi sportlich abgeschlagen hinter Honor und Mi Band 4