Diskussion:Sicherheitslücke

message: Hallo, Sicherheitslücken resultieren NICHT aus dem Einsatz von "technisch überholten Programmiersprachen"!!!
Sicherheitslücken lassen sich auch in Java oder Haskell erzeugen. Jede Turingmächtige Programmiersprache ermöglicht es Programme zu schreiben die Sicherheitslücken enthalten. Um die Korrektheit eines Programms festzustellen benutzt man z.B. das Hoarekalkül. Desweiteren kann man bei C nicht von einer überholten Programmiersprache sprechen, da dies die Sprache der Wahl ist wenn es um Low-level Programmierung geht z.B. Betriebsysteme und Treiber.
:Lieber Anonymus, niemand hat behauptet, dass Sicherheitslücken nur oder zwangsläufig durch technisch überholte Werkzeuge resultieren. In der Praxis treten diese Probleme in den allermeisten Fällen aber im Zusammenhang damit auf. Diesem sollte im Artikel daher unbedingt Rechnung getragen werden und ist auch leicht nachvollziehbar, da C ja schon vor 36 Jahren entwickelt worden ist, als es noch lange kein Internet gab.
:Dass Betriebssysteme und Treiber sehr effizient (und zusätzlich noch stabiler) auch mit moderneren Programmiersprachen geschrieben werden können, ist spätestens seit Anfang der achtziger Jahre mit der Einführung von Modula-2 nachgewiesen worden. Auch mit Eiffel, Oberon oder Component Pascal sind hocheffiziente und gleichzeitig sichere Programme (auch Betriebssysteme) geschrieben worden. Es mag sein, dass C gerne von Programmierern (oder von deren Vorgesetzten ?) gewählt wird - aus welchen Gründen auch immer. Dass dies geschieht, um effizientere Software zu programmieren, ist jedoch nicht zutreffend. Darüberhinaus stellen diese Programme wegen fehlender Funktionalität der Entwicklungswerkzeuge halt sehr häufig ein Sicherheitsproblem dar.
:Quellen, die das alles belegen finden sich zum Teil seit über zehn (!) Jahren zur Fülle im Internet, wie zum Beispiel:
:*A Comparison of C++, FORTRAN 90 and Oberon-2 for Scientific Programming
:*Why Microsoft is to Blame
:*Criticism of the C programming language
::Zitat: "C permits many operations that are generally not desirable, and thus many simple programming errors are not detected by the compiler and may not even be readily apparent at runtime. This potentially leads to programs with unpredictable behavior and security holes, if sufficient care and discipline are not used in programming and maintenance."
:*Jbed
:Der Passus sollte aus meiner Sicht auf keinen Fall entfernt werden.
:Bautsch 13:00, 12. Dez. 2006 (CET)
replies: text: Ich weiß, meine Antwort ist etwas spät, aber der Passus steht ja noch immer so ähnlich wie hier diskutiert drinnen (es steht nichts mehr von "technisch überholten Programmiersprachen" drin, aber diese Beschreibung wäre ohnehin kaum mit WP:NPOV vereinbart gewesen). Es kann sein, dass er korrekt ist, aber es sind eben keine Quellen angegeben, auch deine Links ändern daran nichts: der erste und der dritte sind mittlerweile offline, der zweite ist wohl eher ein Essay als eine Wissensquelle und teilweise stark übertreiben (z.B. zum Zeitaufwand: es wird die gesamte Downloadzeit für Updates zur Arbeitszeit dazugerechnet, obwohl ein Download ja autoamtisiert abläuft und man in der Zwischenzeit den PC normal weiterbenutzen kann, das einzige, was vom Zeitaufwand noch übrig bleibt, wenn man autmatisierte Prozesse abzieht, ist die Arbeitszeit für die Konfiguration + eventuell die Zeit, während der der PC die Windows-Updates installiert, während der man aber wenn das möglich ist andere Arbeiten erledigen kann, Antivirus-Updates laufen hingegen im Hintergrund und man kann abgesehen davon, dass man bei einem kleinen Teil der Updates rebooten muss normal weiterarbeiten), also auch als Quelle nicht brauchbar. Der vierte Link geht garnicht auf die Sicherheit ein, sondern es geht nur darum, dass es ein in Java geschreibenes Betriebssystem gibt (die behauptung, dass es komplett in Java geschrieben ist, ist natürlich falsch, denn man braucht noch den "Target Byte Code Compiler", der ist also auch zu diesem OS zu zählen und natürlich nicht in Java geschrieben, ich würde ihn als den eigentlichen Kernel des Betriebssystems sehen). Da die Frage, inwiefern die Programmiersprachen an der Sicherheitsproblematik mitschuld sind, wohl nicht unstrittig ist, sollte dieser Punkt ordentlich mit Quellen belegt oder rausgenommen werden. --MrBurns (Diskussion) 03:31, 26. Jul. 2012 (CEST)
replies: text:   "Modula-2,..., Oberon oder Component Pascal": Dies ist ein Wikipedia-Artikel und keine Niklas-Wirth-Gedächtnis-Veranstaltung... (nicht signierter Beitrag von 93.159.251.82 (Diskussion) 12:05, 21. Dez. 2015 (CET)
thread_title:  Sicherheitslücken 

message: Kritische Sicherheitslücke im Internet Explorer : BSI empfiehlt die vorübergehende Nutzung alternativer Browser
https://www.bsi.bund.de/cln_183/ContentBSI/presse/Pressemitteilungen/Sicherheitsluecke_IE_150110.html
http://www.heise.de/newsticker/meldung/BSI-warnt-vor-Nutzung-des-Internet-Explorer-906050.html
Hat die entsprechende Lücke schon einen Namen oder eigenen Artikel?-- pistazienfresser 07:37, 16. Jan. 2010 (CET)
thread_title:  IE-Sicherheitslücke und Angriff auf Google (Januar 2010) 

message: Hat niemand ein Problem mit der Darstellung des Begriffs Risiko ("... Sicherheitslücke birgt Risiken bezüglich der Sicherheit betroffener Computersysteme ...")?
Das ist schon sehr umgangssprachlich und stellt den Sachverhalt nicht ganz im Sinne der Thematik dar.
Wenn niemand etwas dagegen hat würde ich das anpassen. --Armin Pollak 16:32, 21. Nov. 2010 (CET)
thread_title:  Begriffsprägung 

message: Also die Warscheinlichkeit eines fehlers pro Zeile anzugeben erscheint ziemlich willkürlich, da das Stark von der Programmiersprache abhängt.
Eine Zeile in C zum Beispiel kann verdammt lang werden, und komplizierte Ausdrücke wie while(a)a+=(++b+c--)*(b==c?b:b+c++); oder A=b=c==d; enthalten und ist sehr fehleranfällig.
Eine Assemblerzeile hingegen enthällt einen einzigen einfach zu verstehenden Maschinenbefehl, zb. INC AX, und ist somit kaum fehleranfällig, weil jedem sofort offensichtich ist was passiert. In BASIC hingegen gibt es die möglichkeit mehrere Befehle in eine Zeile zu schreiben, die anzahl der Zeilen pro fehler varriiiert also je nach Programmierstil, z.b. haben 10 SCREEN 7 20 CLS 30 DEFINT A 40 GOTO 100 , fast die gleiche wirkung wie 10 SCREEN 7:CLS:DEFINT A:GOTO 100, obwohl einmal 4 und einmal 1 Zeile verwendet wurden. (nicht signierter Beitrag von 93.243.103.253 (Diskussion) 20:32, 15. Apr. 2011 (CEST)
thread_title:  Programmzeile kein sinnvolles Maß 

message: Ich habe mal die aus meiner Sicht gröbsten Fehler im Artikel bereinigt. Meines Erachtens sind immer noch zuviel Annahmen, nicht belegte Aussagen und Allgemeinplätze enthalten. Vielleicht kann sich dem noch jemand annehmen. --Armin Pollak 23:52, 19. Mai 2011 (CEST)
thread_title:  Korrektur des Artikels 

message: Wird der Einsatz von Zapper (Software) auch als Sicherheitslücke bezeichnet? Wie kann dieser Einsatz elektronisch  entdeckt werden?--89.204.135.109 08:51, 22. Feb. 2013 (CET)
thread_title:  Verständnisfrage 

message: Ist ein zu leicht zugängliches Passwort nicht auch eine Sicherheitslücke? Also zum Beispiel so wie hier auf dem Bild. Wobei es sicher auf die Situation ankommt und z. B. bei einer Tagung eine solche Handhabung natürlich auch kaum zu vermeiden sein kann; hier kann die Sicherheit z. B. in der Zugangskontrolle zum Raum bestehen. -- 2003:E5:571E:D400:A17F:3F8F:C7E1:FF9E 17:58, 7. Jan. 2022 (CET)
replies: text: Kennwörter sind grundsätzlich leicht auszuspionieren, auch wenn sie nicht über der Tastatur geschrieben stehen. Die Eingaben können zum Beispiel gefilmt werden oder mit einem Keylogger registriert werden. Das betrifft selbstverständlich auch Masterkennwörter. Experten empfehlen daher dringend die Multi-Faktor-Authentisierung. --Bautsch 10:32, 8. Jan. 2022 (CET)
thread_title:  Sicherheitslücke leicht zugängliches Passwort