Wie am besten anfangen?
-
Tim schrieb:
Insgesamt ist es ziemlich lächerlich gets() als Argument zu verwenden.
Keineswegs, es ist ein Anzeichen der Sicherheitsunkultur die in C-Kreisen herrscht. gets() existierte schon vor der ANSI-Norm, wie konnte es also sein, daß dieser Dreck Einzug in die ANSI-Norm fand? Zu diesem Zeitpunkt hätte man schon wissen müssen, daß diese Funktion rotten by design ist.
Es wird fortlaufend gepfuscht. Das krasse Gegenbeispiel ist Ada, da gibt es eine Sicherheitskultur. Eine Sicherheitskultur macht zwar Fehler nicht unmöglich reduziert aber deren Auftreten deutlich.
Das nächste Negativbeispiel sind die ganzen IO-Funktionen von C, diese werden mit Formatstrings benutzt. Da C aber kein RTTI kennt, wird zur Laufzeit nicht überprüft, ob Formatstring und Parameter der Funktion überhaupt zusammenpassen. Der Notbehelf sind Compilezeitüberprüfungen, die aber nicht vollständig sind, und natürlich funktioniert dies nicht, wenn man während der Laufzeit die Formatstrings zusammen baut oder Zeiger statt Stringliterale nutzt.
Das absolut ägerlichste ist es, daß selbst in der ISO Norm es niemand für notwendig erachtet, das korrekte Einlesen eines Strings zu beschreiben.
Folgender Code ist direkt aus der ISO-Norm herauskopiert.
#include <stdio.h> /* ... */ int n, i; float x; char name[50]; n = fscanf(stdin, "%d%f%s", &i, &x, name);Das ist ein Exploit! Wie kann man so einen Mist in eine ISO-Norm schreiben?
Was ist denn so schwierig daran, den korrekten Umgang mit scanf & Co. zu lehren? Warum muß faktisch jeder Autor eines C-Lehrbuch es falsch machen? Warum gibt es darauf keine Antwort sondern die immer gleichen Sprechblasen mit Unsinn? Warum ist Pfusch unter C-Programmieren die Regel und nicht die Ausnahme? Wie soll mit einer solchen Unkultur des Pfuschs ein Anfänger jemals korrektes C lernen?
Es wäre schön, wenn es Hinweise auf Literatur gäbe, die C korrekt vermittelt, aber wahrscheinlich läuft es wieder nur darauf hinaus, daß die C-Programmierer hier aufschreien, weil man ihnen ihr Schäuffelchen weggenommen hat.
-
Ist doch totaler Schwachsinn. Das hat nix mit der Sprache zu tun und auch nicht jede Funktionerklärung muss über alles Sicherheitsaspekte aufklären.
Das Thema Sicherheit ist in jeder Sprache wichtig und für jede Sprache gibt es auch genug Exploits wenn bestimmte Standardfunktionen einfach genutzt werden ohne deren Parameter zu validieren. Du kannst in C genauso sicher programmieren wie in alle anderen Sprachen auch. C User haben wohl eher ein Sicherheitsbewusst entwickelt als ein PHP oder C++ Programmierer weil Leute wie du denen suggerieren bei Sprache X muss ich mich nicht so sehr um Sicherheit bemühen.
In einem gebe ich dir recht, Fachbücher egal für welche Sprache sollten auch auf das Thema Sicherheit nochmals gesondert eingehen bei den eigentlichen typischen Grundlagenthemen hat das aber nicht viel zu suchen, da der Programmieranfänger schon genug damit zu tun hat die Grundlagen zu lernen, Sicherheit sollte dann immer extra behandelt werden am besten als eigenes Buch denn ein Fachbuch was beides gut behandeln will wird sicherlich scheitern.
-
~john schrieb:
gets() existierte schon vor der ANSI-Norm, wie konnte es also sein, daß dieser Dreck Einzug in die ANSI-Norm fand?
Ok, wo fängt man da an ...
(1) Mit gets() kann man sich sehr bequem Kommandos für einen Worker-Thread aus einer Message Queue, einer temporären Datei u.ä. pflücken, und das sogar ziemlich OS - unabhängig. Ich nehme an, Sie haben gets() bisher wohl nur als Lesefunktion für Konsoleneingaben kennengelernt, sonst würden Sie auch die Vorzüge von gets() kennen. Dazu nur soviel: Viele OS erlauben eine sog. Stream-Umleitung, gets() kann also auch mit Daten aus einer temporären Datei gefüttert werden.
(2) Man kann umgekehrt auch mit der sichersten Funktion der Welt unsicher programmieren, wenn man will.
(3) Arbeiten mehrere Leute an einem Projekt zusammen, dann haben sie idR nicht das Ziel, Funktionen eines Mitstreiters absichtlich mit fehlerhaften Parametern, zu kleinen Buffern oder sonstwie unter Missachtung der Sicherheitshinweise des Implementierers aufzurufen. Wenn es gar nicht vorgesehen oder gar unmöglich ist, dass eine derartige Funktion eines Tages von nicht-eingebundenen Dritten verwendet werden wird, sondern nur innerhalb des Teams, und zudem ihren Job hervorragend erfüllt, dann pfeift man eben auch auf die Sicherheitsbedenken (verständlicher Weise!) zu Gunsten eines optimierten Moduls. Niemand zwingt einen Programmierer dazu, seinen Quellcode zu öffnen und damit eventuelle Verwundbarkeiten oder Unsicherheitsfaktoren darin preiszugeben. Ist das Ding erst mal kompiliert, wird es ohnehin schwierig und aufwendig genug, derartige Sicherheitslücken (per Disassembly o.ä.) auszunutzen. Diejenigen, die sich diese Mühe antun, wird man auch trotz Super-Sicherster Programmierung nicht davon abbringen können, irgendwelche Verwundbarkeiten aufzuspüren und in boshafter Weise auszunutzen.
Aber alle anderen, 'ehrlichen' Anwender des Programms (99%) interessieren diese internen (aber eben nur innerhalb des Entwickler-Teams tolerierten) Sicherheitsbedenken ohnehin nicht, dafür können sie die Gewissheit haben, dass ihre Copy der Anwendung auch auf ihrem Uralt-Rechner noch das Maximum rausholt und sich nicht mit performance-technisch überflüssigen Doppel- und Dreifachprüfungen irgendwelcher Zeiger und Rückgabewerte beschäftigt, weil nämlich alle Entwickler des Teams an einem Strang gezogen haben und sie in eine Funktion niemals boshafter Weise eine 10 reinstecken, wenn nur 16 oder 32 erlaubt ist.
Alles klar?
--> Es krankt bei den modernen OOP-Entwicklern generell daran, dass sie den potentiellen Nutzern ihrer Monsterobjekte mit Misstrauen begegnen, was aber selbstverständlich unangebracht ist, wenn man man im Team arbeitet, jeden Beteiligten kennt, man sich aufeinander verlassen kann, da fällt es dann auch leichter diese Sicherheitsprobleme zu tolerieren, weil ja von der Source ohnehin niemals geplant ist, dass sie je open oder gar public wird.
Ein Hoch auf Closed Source
MFG
-
Ausnahmeerscheinung schrieb:
Ist das Ding erst mal kompiliert, wird es ohnehin schwierig und aufwendig genug, derartige Sicherheitslücken (per Disassembly o.ä.) auszunutzen. Diejenigen, die sich diese Mühe antun, wird man auch trotz Super-Sicherster Programmierung nicht davon abbringen können, irgendwelche Verwundbarkeiten aufzuspüren und in boshafter Weise auszunutzen.
WTF? Wir können Programme nicht zu 100% sicher machen, also können wir es auch gleich sein lassen?
-
Bis heute hat es kein Mensch geschafft sichere Software zu schreiben, also haltet den Ball flach. Es gibt auch hier keinen der das auch nur annähert könnte sonst wäre der schon durch die Presse gegangen.
-
ITPolizei schrieb:
Bis heute hat es kein Mensch geschafft sichere Software zu schreiben, also haltet den Ball flach. Es gibt auch hier keinen der das auch nur annähert könnte sonst wäre der schon durch die Presse gegangen.
Dann sollten wir es auch gar nicht mehr versuchen
-
ITPolizei schrieb:
Bis heute hat es kein Mensch geschafft sichere Software zu schreiben, also haltet den Ball flach. Es gibt auch hier keinen der das auch nur annähert könnte sonst wäre der schon durch die Presse gegangen.
Ich schreibe nur sichere Software. Warum sollte der Normalzustand durch die Presse gehen?
-
Schon klar, na dann fang mal bei den BigPlayern an wie Apple, MS, Oracle oder Adobe. Denn die haben es bis jetzt noch nicht geschafft sichere Software zu schreiben. Du wärst also der erste Mensch der sichere Software schreiben kann.
Ich glaube als Politiker würdest du auch sagen dass du immer die Wahrheit erzählst
An den Poster davor, klar sollte weiter versucht werden an die Software sicherer zu machen. Da die IT-Branche aber noch sehr jung ist kann man das eher mit Architekten vergleichen die aus ein paar Palmenblätter Behausungen bauen können, aber erzählen ein Wolkenkratzer wäre kein Problem.
In 50 Jahren werden die Menschen zurückblicken und darüber lachen das sich einige aus der heutigen Zeit als Softwarearchitekten bezeichnet haben.
Softwareentwicklung ist doch im Vergleich zu andere Branchen ein gigantisches Rumgepfusche.
-
Mir ist auch noch nicht bekannt dass es auch nur einen Menschen gibt der weiß wie man wirtschaftlich sichere Software schreibt. Wenn es den mal gibt bekommt der bestimmt den Nobelpreis
Wir fassen zusammen: Es gibt keinen der weiß wie man richtig Software entwickelt, aber die meisten lassen sich als Softwareentwickler einstellen. Ist schon geil, zum Glück gibt es das nicht in der Form in anderen Branchen.
-
Nobelpreiser schrieb:
Mir ist auch noch nicht bekannt dass es auch nur einen Menschen gibt der weiß wie man wirtschaftlich sichere Software schreibt. Wenn es den mal gibt bekommt der bestimmt den Nobelpreis
Das ist ja auch ein Widerspruch.
Wie mit den Autos. Wenn man X Monat braucht, um ein fehlerfreies Auto zu basteln, so kann man doch ein paar Tage früher abgeben und dafür kassiert man eine gewisse Fehlerwahrscheinlichkeit ein. Früher im Markt zu sein gibt mehr Kohle. Weniger Fehler zu haben, gibt mehr Kohle. Das Optimum ist nicht am Rand. Nicht bei 0 Zeit und 100% Fehler und nicht bei X Zeit und 0% Fehler. Irgendwo dazwischen. Warte nicht auf fehlerfreie Software aus dem Kaufhaus. Und auf keine fehlerfreien Autos.
-
Das ist Unsinn, da Software keine Hardware ist und daher mit keiner Mechanik verglichen werden kann. Diese kann alleine durch die Fertigung nicht immer 100% gleich sein.
-
Softwareentwicklung ist doch im Vergleich zu andere Branchen ein gigantisches Rumgepfusche.
Warum funktioniert denn die Welt dann ueberhaupt, so wie jetzt. Auf Basis von Software. Alles ein riesiger Pfusch.
-
nichtschluessig schrieb:
Das Thema Sicherheit ist in jeder Sprache wichtig und für jede Sprache gibt es auch genug Exploits wenn bestimmte Standardfunktionen einfach genutzt werden ohne deren Parameter zu validieren.
Wie willst Du den C-Lernenden beibringen, daß sie auf solche Dinge zu achten haben, wenn faktisch keinerlei Einstiegsliteratur auch nur erwähnt, daß diese Funktionen gefährlich sind? Es fehlt das notwendige Bewußtsein, daß diese Funktionen brandgefährlich sind. Daher sieht auch niemand die Notwendigkeit sich mit Informationen zu korrektem Programmentwurf zu versorgen. Das ist das Grundproblem! Insofern muß man in der Einstiegsliteratur damit anfangen, weil es sonst niemals gelernt wird.
Die Realität zeigt, daß die Selbsteinschätzung von C Programmierern, sie hätten das Problem im Griff, reine Utopie ist.
-
~john schrieb:
Die Realität zeigt, daß die Selbsteinschätzung von C Programmierern, sie hätten das Problem im Griff, reine Utopie ist.
Unsinn. Ich hab das Problem im Griff.