1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Linux: Vom einfachen…

Lösung: ...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


  1. Lösung: ...

    Autor: spiegelneuron 20.10.21 - 21:05

    eine vernünftige Programmiersprache, und das ist sicher nicht C.
    C gehört ins Museum. Besser C++ oder Rust.

  2. Re: Lösung: ...

    Autor: jkow 20.10.21 - 21:29

    Inwiefern ist C++ sicherer?

  3. Re: Lösung: ...

    Autor: Wuestenschiff 20.10.21 - 22:11

    Du kannst in modernen c++ speicher fehlerfrei arbeiten. Du darfst einfach nur RAI verwenden und Smartpointer benutzen. Rust hat noch ein pasr garantien mehr aber Dpeicherfehler kriegst du weg mit )modetnem) c++



    1 mal bearbeitet, zuletzt am 20.10.21 22:11 durch Wuestenschiff.

  4. Re: Lösung: ...

    Autor: oleid 20.10.21 - 22:41

    Wuestenschiff schrieb:
    --------------------------------------------------------------------------------
    > Du kannst in modernen c++ speicher fehlerfrei arbeiten. Du darfst einfach
    > nur RAI verwenden und Smartpointer benutzen

    Ach, dangeling references bekommt man in c++ damit immer noch hin. Trivialbeispiel: nimm eine Referenz auf ein Element eines Vektors und dann häng was an den Vektor an. Kam gut gehen, muss aber nicht.

  5. Re: Lösung: ...

    Autor: ultim 21.10.21 - 00:39

    oleid schrieb:
    --------------------------------------------------------------------------------
    > Ach, dangeling references bekommt man in c++ damit immer noch hin.

    Stimmt. Die Frage ist aber nicht was man hinbekommt oder was überhaupt möglich ist, sondern was einfach geht. Und wenn man ein paar Spielregeln einhält ist das Fernhalten von Speicherfehlern in modernem C++ einfach. Aber ja, in der Sprache selbst sind Speicherfehler im Prinzip nicht ausgeschlossen.

  6. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 06:32

    jkow schrieb:
    --------------------------------------------------------------------------------
    > Inwiefern ist C++ sicherer?

    Mit RAII wird ein Objekt zum richtigen Zeitpunkt freigegeben.

  7. Re: Lösung: ...

    Autor: Walter Plinge 21.10.21 - 07:02

    Naja, die Spielregeln können bei C++ aber beliebig komplex werden. Stichwort this-ptr in lambdas.

  8. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 07:08

    Walter Plinge schrieb:
    --------------------------------------------------------------------------------
    > Naja, die Spielregeln können bei C++ aber beliebig komplex werden.
    > Stichwort this-ptr in lambdas.

    Es gibt sicher in c++ komplexe Dinge.
    Aber ein this-Pointer in einem Lambda isses ganz sicher nicht.

  9. Re: Lösung: ...

    Autor: RicoBrassers 21.10.21 - 07:32

    ultim schrieb:
    --------------------------------------------------------------------------------
    > Und wenn man ein paar Spielregeln einhält ist das Fernhalten von Speicherfehlern in modernem C++ einfach.

    Ich denke mal, dass das ja die Crux an der Sache ist.
    Wenn man sich an ein paar Spielregeln hält, könnte das vermutlich auch in C möglich sein.

    Die Problematik ist doch dabei, dass man diese ganzen Spielregeln dabei im Kopf haben muss - und manchmal vergisst man halt, sich an jeden Punkt zu erinnern. Irren ist nunmal menschlich.

    Da ist es doch dann von Vorteil, wenn die Sprache selbst diese Spielregeln als Grundvoraussetzungen nimmt und der Compiler bereits auf die gemachten Fehler hinweist, BEVOR es zu einem Bruch der Spielregeln kommt. ;-)

  10. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 07:34

    > Ich denke mal, dass das ja die Crux an der Sache ist.
    > Wenn man sich an ein paar Spielregeln hält, könnte das vermutlich auch in C
    > möglich sein.

    Eben nicht - wie so gut wie jedes große C-Projekt zeigt.

  11. Re: Lösung: ...

    Autor: sebi2k1 21.10.21 - 08:05

    C++ ist mit Nichten die Lösung.

    C++ mit seinen fancy shared_ptr/weak_ptr/… kann nicht die Lösung sein wenn man das Grundproblem verstanden hat. Es geht hier nicht einfach um einfache use-after-free Problematik, sondern hier geht es auch um Threading. Ist ja schön wenn du in Thread A den shared_ptr löscht aber wenn es in Thread B nicht geschützt wurde bringt es nichts. Und wenn du es schützt z.B. mit Atomics (weil Mutexe im Kernel extrem teuer) wird jeder Zugriff trotzdem teuer und nimmt dem Compiler Möglichkeiten der Optimierung (z.B. wegen Reordering usw.).

    Es gibt sehr gute Gründe warum die erfolgreichsten System (Windows, Linux, QNX und sogar FreeRTOS) allesamt in C geschrieben sind.

    Ob Rust eine Möglichkeit wurde ist schwer zu sagen,
    grundsätzlich finde ich die Konzepte sehr interessant, sie müssen sich aber erstmal in Realwelt Anwendung beweisen. Also z.B. in der Hardware-nahen Entwicklung wo man mit Interrupts & Co. arbeitet, aber da stößt es schnell an seine Grenze. Interessant ist Rust aktuell primär wegen der Immutable Policy und besseren Schutz von Speicherproblemen z.B. bei Parsen von externen Daten (Protokolle wie IP). Aber auch das muss sich im Kernel erst beweisen.

  12. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 08:18

    > Ist ja schön wenn du in Thread A den shared_ptr löscht aber
    > wenn es in Thread B nicht geschützt wurde bringt es nichts.

    Das passiert eben nicht weil shared_ptr<> einen Referenzzähler auf dem Heap hat.

    > Es gibt sehr gute Gründe warum die erfolgreichsten System (Windows,
    > Linux, QNX und sogar FreeRTOS) allesamt in C geschrieben sind.

    Ja, ein idiotisches Mindset. C++ wäre an der Stelle eine meilenweit überlegene Sprache.

  13. Re: Lösung: ...

    Autor: BangerzZ 21.10.21 - 08:48

    sebi2k1 schrieb:
    --------------------------------------------------------------------------------
    > Es gibt sehr gute Gründe warum die erfolgreichsten System (Windows, Linux,
    > QNX und sogar FreeRTOS) allesamt in C geschrieben sind.

    Sind halt alle stein alt. Und C hat sich nun mal in diesem Sektor festgesetzt.
    Wenn du also Kernel Entwickler werden willst must du C können. Wenn die Entwickler dann einen neuen Kernel entwickeln wollen werden die das wohl in C machen weil sie das schon können.

    Klassisches: "Das haben wir schon immer so gemacht."

  14. Re: Lösung: ...

    Autor: Thinal 21.10.21 - 08:50

    Aber nicht, weil die Regeln nicht ausreichend sind, sondern weil sich nicht dran gehalten wird. In dem Artikel geht es doch darum, dass eben nicht beweisbar ist, dass sich an die Regeln gehalten wird, sodass eine automatisierte Überprüfung nicht zu einem sicheren Ergebnis führt. Und das gleiche Problem ergibt sich bei C++. Solange es der Compiler/die Sprache zulässt, dass du unsicher programmierst, wird es diese Probleme gebe, weil Menschen nun mal Fehler machen.

  15. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 08:50

    > Klassisches: "Das haben wir schon immer so gemacht."

    Nicht unbedingt deswegen, sondern weil solche Lowlevel-Frickler halt ein Lowlevel-Mindset haben. Und dazu passt C++ eben nicht. Würden die auf der Lowlevel- und Highlevel-Ebene denken können, dann kämen denen vielleicht auch C++ in den Sinn.

  16. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 08:53

    > Aber nicht, weil die Regeln nicht ausreichend sind, sondern weil sich nicht
    > dran gehalten wird. ...

    Es gibt in C keine entsprechenden Regeln weil es keine entsprechenden Sprachmittel dazu gibt.

    > In dem Artikel geht es doch darum, dass eben nicht beweisbar ist, dass sich
    > an die Regeln gehalten wird, sodass eine automatisierte Überprüfung nicht
    > zu einem sicheren Ergebnis führt.

    Eine automatisierte Untersuchung ist an der Stelle unmöglich.

    > Und das gleiche Problem ergibt sich bei C++.

    In C++ kannst du einene shared_ptr<> nehmen und dein Objekt lebt so lange wie nur ein Thread einen shared_ptr<> hält.

  17. Re: Lösung: ...

    Autor: RicoBrassers 21.10.21 - 09:05

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > Es gibt in C keine entsprechenden Regeln weil es keine entsprechenden
    > Sprachmittel dazu gibt.
    >
    > [...]
    >
    > In C++ kannst du einene shared_ptr<> nehmen und dein Objekt lebt so lange
    > wie nur ein Thread einen shared_ptr<> hält.

    Nur, weil es in C keine Sprachkonstrukte gibt, die den Programmierer dabei unterstützen, Speicherfehler zu vermeiden, heißt das nicht, dass es keine "Spielregeln" gibt, die helfen können, Speicherfehler zu vermeiden.

    Anstatt andere Datentypen/Sprachkonstrukte zu nutzen, sind die "Regeln" dann eben, manuell darauf aufzupassen, dass man Speicherbereiche nicht nutzt, nachdem man sie freigegeben hat.
    Also genau das, was bspw. der Rust-Compiler dem Entwickler abnimmt.

    So, wie in in C++ daran denken sollte, shared_ptr zu nutzen, muss ich halt in C daran denken, Speicherbereiche nach der Freigabe nicht mehr zu nutzen. Beides kann man durchaus vergessen.

    Natürlich KANN man mit C genauso Code ohne Speicherfehler schreiben, wie in C++ oder Rust auch. Aber C/C++ sind dazu auf die Fehlerquelle Mensch als kontrollierende Instanz angewiesen, weil entsprechende Fehler erst zur Runtime auftreten. Eine Sprache wie Rust bspw. hat diese Problematik nicht.

  18. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 09:07

    > Anstatt andere Datentypen/Sprachkonstrukte zu nutzen, sind die "Regeln"
    > dann eben, manuell darauf aufzupassen, dass man Speicherbereiche nicht
    > nutzt, nachdem man sie freigegeben hat.

    Wenn man es manuell machen muss gibt es keine Regeln.

  19. Re: Lösung: ...

    Autor: pythoneer 21.10.21 - 09:27

    Wuestenschiff schrieb:
    --------------------------------------------------------------------------------
    > Du kannst in modernen c++ speicher fehlerfrei arbeiten. Du darfst einfach
    > nur RAI verwenden und Smartpointer benutzen. Rust hat noch ein pasr
    > garantien mehr aber Dpeicherfehler kriegst du weg mit )modetnem) c++

    Das ist genau die Denkweise die uns seit Jahrzehnten zurückhält. Was ist denn das überhaupt für ein schwaches Argument?

    > Du kannst in modernen c++ speicher fehlerfrei arbeiten.

    Ja man "kann". Hier liegt doch genau der Fehler! Ich "kann" auch in C fehlerfrei arbeiten – ich darf nur keine Fehler machen. Es geht in der Angelegenheit nicht um die Frage ob man fehlerfrei arbeiten "kann" sondern ob man fehlerfrei arbeiten "MUSS".

    In dieser Argumentation klingt es ja fast so als sei es ausgeschlossen in C fehlerfrei zu arbeiten und die Neuerung von "modernem" C++ ist nun, dass man es endlich "kann". Nein, das ist von vorne bis hinten falsch aber leider eine gängige Meinung die immer und immer wieder seit Jahren verbreitet wird.

    Wir müssen als Programmiergemeinschaft endlich mal von dieser falschen Annahme weg. Vor allem aber "wenn ich nur genug Tools auf das Problem werfe (Asan, Msan, UBsan, Valgrind ... ) dann gehen die Probleme schon weg" ... nein tun sie nicht.

    Das haben nun schon Microsoft, Google und Mozilla erkannt und haben ziemlich ähnliche Zahlen was die Problemstellung anbelangt. Es sind ca. 70% der sicherheitskritischen Lücken auf fehlerhaftes Speichermanagement zurück zu führen und dass seit vielen Jahren unverändert auch MIT Einführung von "modernem" C++. Wer glaubt "modernes" C++ sei die Lösung ist Teil des Problems. Besonders muss man hier ein gewisses Gatekeeping hervorheben das von selbsternannten Gurus einhergeht. Diese säuseln nämlich daher, dass es nur "genug schlaue" Programmierer braucht um das Problem aus der Welt zu schaffen. Als würden diese nie Fehler machen.

    Die ganze Situation ist wirklich festgefahren an Personen die meinen, dass dieses Problem allein durch starken Willen und Disziplin zu lösen sei und nicht durch mathematisch korrekte Automatisierung. Das fühlt sich stellenweise so an wie Technikverweigerer die mit falschen Argumenten versuchen ihren Job zu verteidigen der droht automatisiert zu werden.

    ja es fühlt sich furchtbar schlecht an, wenn plötzlich ein Student mit wenig Erfahrung genauso sicheren Code schreiben kann wie Ich der 20 Jahre durch den Schützengraben namens C gegangen ist und die typische "Anfängerfehler" nicht mehr macht, weil man selber durch seine eigenen Narben erinnert wird. Da wird das eigene Ego nämlich erheblich angegriffen wenn jemand neues ohne diese Narben daherkommt und einfach von diese "schlimmen" Zeiten nichts mehr mit bekommt, weil für diese Person C/C++ einfach der Vergangenheit angehört – wohl verdient.

    Wer Interesse an der Meinung eines Microsoft Mitarbeiters zu dem Thema hat, kann sich gerne mal diesen Talk dazu ansehen

    https://www.youtube.com/watch?v=qCB19DRw_60

    https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/
    https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
    https://www.chromium.org/Home/chromium-security/memory-safety
    https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html
    https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/

  20. Re: Lösung: ...

    Autor: pythoneer 21.10.21 - 09:30

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > Wenn man es manuell machen muss gibt es keine Regeln.

    Damit trifft das gleiche auf C++ zu. Ich muss shared_ptr<> manuell verwenden. Wenn ich das Vergesse (genauso wie ein vergessen kann an der richtigen Stelle ein free zu machen) bekomme ich eben Fehler. C++ ist in der Hinsicht ähnlich schwach wie C. Davon abgesehen kann ich mit den "smart" Pointern immer noch genug Fehler machen die von anderen Programmiersprachen zur Compilierzeit erkennt werden können.



    1 mal bearbeitet, zuletzt am 21.10.21 09:35 durch pythoneer.

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

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. IT System Administrator (m/w/d)
    Gesellschaft für Grund- und Hausbesitz mbH, Heidelberg
  2. WLAN Administrator (m/w/d)
    willy.tel GmbH, Hamburg
  3. Specialist* Digital Production Systems
    Harting Electric GmbH & Co. KG, Espelkamp
  4. Information Security Architect (m/w/d)
    NEMETSCHEK SE, München

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de