1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › C-Programmierung: Schutz…

Ich dachte C waere sicher..?

  1. Thema

Neues Thema Ansicht wechseln


  1. Ich dachte C waere sicher..?

    Autor: carsti 28.12.14 - 13:19

    Schon komisch. Ich habe bis auf Spezialfaelle C/C++ seit Jahren hinter mir gelassen. Vor allem auch wegen der ranzigen Toolchains.
    Oft kann man es natuerlich nicht vermeiden. Aber ich gehoere nicht zu denen die behaupteten, dass die vielen Sicherheitsluecken nur was mit den miesen Programmierern zu tun haben. Einmal mehr beweist es sich, dass die Sprache und Toolchain so sein sollten, dass selbst bei schlechten Programmieren ausser logischen Fehlern alles abgefangen wird.
    Mit logischen Fehlern meine ich vermurkste Login-Checks (man kann sich z.B. ohne Passwort oder falschem Passwort einloggen) oder offene Ports ueber die Daten abgerufen werden koennen, usw.
    Sowas kann eine Toolchain natuerlich nie abfangen. Woher soll sie wissen ob es nicht gewollt ist. Oft passieren solche Fehler weil man fuer Testzwecke was mit Absicht auskommentiert hat und dann in Produktion nicht mehr aktiviert. Auch sowas koennte man verhindern - aber das ist ein anderes Thema.

  2. Re: Ich dachte C waere sicher..?

    Autor: Wirtschaftsmacht 28.12.14 - 14:22

    Wer 'schlecht' programmiert sollte erst gar kein Programmierer sein! Ist echt zum kotzen, was da teilweise von den Universitäten in die Jobs fällt und Null,Nix Logikverstand aufweist, einfach weil IT grade hip ist! Ich hab schon zig Personen interviewt und 9 von 10 sind 'ausschuss'! Man kann nicht erwarten, dass eine IDE einem die Arbeit abnimmt, da geht es einzig um Komfort-Funktionen die Sinn machen. Logik, Struktur und Ablauf muss einem Fähigen Geist entspringen und sowas ist teilweise genetische Veranlagung.

  3. Re: Ich dachte C waere sicher..?

    Autor: non_sense 28.12.14 - 15:06

    Wirtschaftsmacht schrieb:
    --------------------------------------------------------------------------------
    > Wer 'schlecht' programmiert sollte erst gar kein Programmierer sein! Ist
    > echt zum kotzen, was da teilweise von den Universitäten in die Jobs fällt
    > und Null,Nix Logikverstand aufweist, einfach weil IT grade hip ist! Ich hab
    > schon zig Personen interviewt und 9 von 10 sind 'ausschuss'! Man kann nicht
    > erwarten, dass eine IDE einem die Arbeit abnimmt, da geht es einzig um
    > Komfort-Funktionen die Sinn machen. Logik, Struktur und Ablauf muss einem
    > Fähigen Geist entspringen und sowas ist teilweise genetische Veranlagung.

    Ja, da muss ich recht geben.
    Ich hatte das Vergnügen in diversen Firmen reinzuschauen, und jedes Mal entdecke ich da Code, wo ich mich frage, welcher Geisteskranke sich diesen Müll ausgedacht hat?
    In einer Software habe ich sogar ein Masterpasswort in Klartext im Code entdecken können. Der Klassiker ist auch: "Keine Kommunikation". Da sitzen drei Leute am selben Thema dran und man findet drei unterschiedliche Lösungen im Code ... Sehr witzig, wenn man da was erweitern muss ... Auch Internationalisierung scheint bei vielen Firmen ein mächtiges Problem zu sein, oder trotz Objektorientierung auf Objekte scheißen und alles in Methoden lösen, und per if-then-else entscheiden, welche Methode aufgerufen werden soll.

  4. Re: Ich dachte C waere sicher..?

    Autor: schap23 28.12.14 - 17:23

    Solange Erfahrung in Jahren gemessen wird, wird sich nichts daran ändern. Jemand, der an ein halbes Jahr lang an einem Problem bastelt, weil er schon zu kompliziert angefangen hat und dann weitergebastelt hat, wird halt den nächsten Job kriegen und nicht der, der eine elegante Lösung innerhalb von drei Tagen gefunden hat. Ersterer hat nämlich ein halbes Jahr mehr "Erfahrung" in Java, C oder sonst so einem Kram.

  5. Re: Ich dachte C waere sicher..?

    Autor: Eiertoller 28.12.14 - 18:49

    schap23 schrieb:
    --------------------------------------------------------------------------------
    > Solange Erfahrung in Jahren gemessen wird, wird sich nichts daran ändern.

    Nach meiner Erfahrung gibt es kein einfaches/klares Muster wonach jemand eingestellt und ein anderer abgewiesen wird. Manchmal ist es einfach die Chemie im Bewerbungsgespräch, manchmal die persönlichen Vorlieben des Personalers der die Kandidaten für ein Gespräch auswählt. Mein Favorit für ein Muster ist das: derjenige, der sich im Gespräch besser verkauft, bekommt den Job, egal ob er fachlich eine Niete ist oder nicht. Und ich habe den Eindruck, fachliche Nieten haben eine Stärke: sich gut zu verkaufen :-P

  6. Re: Ich dachte C waere sicher..?

    Autor: Cerdo 28.12.14 - 19:30

    Wirtschaftsmacht schrieb:
    --------------------------------------------------------------------------------
    > Wer 'schlecht' programmiert sollte erst gar kein Programmierer sein! Ist
    > echt zum kotzen, was da teilweise von den Universitäten in die Jobs fällt
    Das sagst du so einfach. Man muss schon echt viel können, um ein guter Programmierer zu sein.

    Ich hab schon Programme gesehen, die vom Aufbau her eine absolute Katastrophe, aber in sich stimmig und sicher waren. Andere Programme sind gut strukturiert, aber dann findet man so etwas wie printf(variable);

    Ein guter Informatiker muss zudem nicht zwingend ein guter Programmierer sein. Nur leider versteht das keiner.

  7. Re: Ich dachte C waere sicher..?

    Autor: George99 28.12.14 - 22:16

    Cerdo schrieb:
    --------------------------------------------------------------------------------
    > Wirtschaftsmacht schrieb:
    > ---------------------------------------------------------------------------

    > gut strukturiert, aber dann findet man so etwas wie printf(variable);

    Was ja durchaus sinnvoll sein kann, wenn die variable vom Typ char * ist. Ansonsten hätte der Programmierer auch eine entsp. Fehlermeldung bekommen.

  8. Re: Ich dachte C waere sicher..?

    Autor: Cerdo 29.12.14 - 00:25

    George99 schrieb:
    --------------------------------------------------------------------------------
    > > gut strukturiert, aber dann findet man so etwas wie printf(variable);
    >
    > Was ja durchaus sinnvoll sein kann, wenn die variable vom Typ char * ist.

    Nicht bei sicherheitskritischen Anwendungen. Wenn in der Variable ein Formatstring steht (%s, %x) kann man sich damit fast den kompletten Stack anzeigen lassen. Darum sollte man IMMER printf("%s", variable); schreiben.
    Auch wenn man in den meisten Fällen damit nicht viel falsch macht, ist alles andere doch eine blöde Angewohnheit, die man dann eben auch macht, wenn es wichtig wäre.

  9. Re: Ich dachte C waere sicher..?

    Autor: George99 29.12.14 - 11:31

    Du hast natürlich recht, dass das auch in die Hose gehen kann. Ich muss zugeben, dass ich printf() bisher auch immer nur klassisch mit einem String benutzt habe. zumal es ja auch noch puts() gibt, wenn man damit leben kann, dass automatisch ein \n mit ausgegeben wird.

  10. Re: Ich dachte C waere sicher..?

    Autor: Cerdo 29.12.14 - 14:13

    Um reine Strings auszugeben ist puts() natürlich super. Da wird der String auch (glaub ich) nicht als Formatstring interpretiert.
    Ich frag mich sowieso, warum die gcc nicht meckert, wenn man printf() "falsch", also unsicher verwendet. Zumindest ein Hinweis wäre schön. Bei gets() kommt ja auch einer.

  11. Re: Ich dachte C waere sicher..?

    Autor: BRDiger 29.12.14 - 14:27

    Cerdo schrieb:
    --------------------------------------------------------------------------------
    > Um reine Strings auszugeben ist puts() natürlich super. Da wird der String
    > auch (glaub ich) nicht als Formatstring interpretiert.
    > Ich frag mich sowieso, warum die gcc nicht meckert, wenn man printf()
    > "falsch", also unsicher verwendet. Zumindest ein Hinweis wäre schön. Bei
    > gets() kommt ja auch einer.

    https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Warning-Options.html

    Suche dort nach "-Wformat" - suchtest du das?

    Funktioniert bei mir zwar nicht aber naja^^

    Bei mir wird partout keine Warnung ausgegeben trotz -Wformat.

    Habe kompiliert mit: gcc -g -Werror -Wall -Wformat -o test test.c

  12. Re: Ich dachte C waere sicher..?

    Autor: Cerdo 29.12.14 - 14:52

    Ich kompiliere prinzipiell mit -Wall, also ist -Wformat da schon drin. Das überprüft leider nur auf Fehler wie printf("%s %s", v);
    Dann schreit er nach dem zweiten Argument.

  13. Re: Ich dachte C waere sicher..?

    Autor: George99 29.12.14 - 15:37

    Wenn wir schon bei printf() sind: Lustig ist z.B. die Frage, wie ich eine Variable vom Typ clock_t ausgebe. Klar kann ich die Variable umcasten z.B. zu double oder zu long long, aber schöner wäre schon eine direkte Ausgabe.
    Für meine kleinen Home-Projekte nehme ich einfach "%l", was von Windows 32 bit (4 Bytes long) bis Linux 64 bit (8Bytes long) funktioniert, aber letztendlich ist das natürlich nicht sauber so.

  14. Re: Ich dachte C waere sicher..?

    Autor: Cerdo 29.12.14 - 15:58

    In C99 kannst du
    > printf("%ju", (uintmax_t) x);
    verwenden. Damit castest du automatisch zum längsten verfügbaren Ganzzahl-Wert auf der Maschine.

    Guckst du hier:
    > https://www.securecoding.cert.org/confluence/display/cplusplus/INT15-CPP.+Use+intmax_t+or+uintmax_t+for+formatted+IO+on+programmer-defined+integer+types

  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Städtisches Klinikum Braunschweig gGmbH, Braunschweig
  2. Vorwerk Services GmbH, Wuppertal
  3. Dataport, verschiedene Einsatzorte (Home-Office möglich)
  4. W3L AG, Dortmund

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. 860 Evo 500 GB SSD für 74,99€, Portable T5 500 GB SSD 94,99€, Evo Select microSDXC 128...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Nitropad im Test: Ein sicherer Laptop, der im Alltag kaum nervt
Nitropad im Test
Ein sicherer Laptop, der im Alltag kaum nervt

Das Nitropad schützt vor Bios-Rootkits oder Evil-Maid-Angriffen. Dazu setzt es auf die freie Firmware Coreboot, die mit einem Nitrokey überprüft wird. Das ist im Alltag erstaunlich einfach, nur Updates werden etwas aufwendiger.
Ein Praxistest von Moritz Tremmel und Sebastian Grüner

  1. Nitropad X230 Nitrokey veröffentlicht abgesicherten Laptop
  2. LVFS Coreboot-Updates sollen nutzerfreundlich werden
  3. Linux-Laptop System 76 verkauft zwei Laptops mit Coreboot

Alphakanal: Gimp verrät Geheimnisse in Bildern
Alphakanal
Gimp verrät Geheimnisse in Bildern

Wer in Gimp in einem Bild mit Transparenz Bildbereiche löscht, der macht sie nur durchsichtig. Dieses wenig intuitive Verhalten kann dazu führen, dass Nutzer ungewollt Geheimnisse preisgeben.


    Mythic Quest: Spielentwickler im Schniedelstress
    Mythic Quest
    Spielentwickler im Schniedelstress

    Zweideutige Zweckentfremdung von Ingame-Extras, dazu Ärger mit Hackern und Onlinenazis: Die Apple-TV-Serie Mythic Quest bietet einen interessanten, allerdings nur stellenweise humorvollen Einblick in die Spielebrache.
    Eine Rezension von Peter Steinlechner

    1. Apple TV TVOS 13 mit Mehrbenutzer-Option erschienen

    1. Made in USA: Glasexperte Corning und Qualcomm bieten 5G Small Cells
      Made in USA
      Glasexperte Corning und Qualcomm bieten 5G Small Cells

      Mit Corning und Qualcomm sind zwei US-Unternehmen im Bereich RAN aktiv, wie Trump es sich wünscht. Doch die 5G Small Cells arbeiten nur im Millimeterwellenbereich.

    2. 5G SA: Ausbau auf echte 5G-Leistung erfolgt mit Softwareupdate
      5G SA
      Ausbau auf echte 5G-Leistung erfolgt mit Softwareupdate

      Das bisherige 5G-Netz hängt noch stark von LTE ab. Wie sich das ändern lässt, wollten wir von den Ausrüstern genau wissen, weil 5G SA bereits eingesetzt wird.

    3. Youtube: Influencer mögen "Clickbait" nicht
      Youtube
      Influencer mögen "Clickbait" nicht

      Bekannte Influencer wie Unge, Dagi und Bibi nutzen laut einem Medienbericht die Filterfunktion von Youtube, um problematische Kommentare zu blockieren. Besonders unbeliebt sind Wörter wie "Clickbait" und "Fake".


    1. 19:41

    2. 17:39

    3. 16:32

    4. 15:57

    5. 14:35

    6. 14:11

    7. 13:46

    8. 13:23