Diskussion:Sicherheitslücke

Sicherheitslücken

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:
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."
Der Passus sollte aus meiner Sicht auf keinen Fall entfernt werden.
Bautsch 13:00, 12. Dez. 2006 (CET)
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)
"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))

Die genannten Quellen (Links) gehen entweder nicht auf die Effizienz ein oder nicht auf Betriebssysteme oder sind von schlechter Qualität (s.o.). Ich halte den derzeitigen Text "nachweislich können Betriebssysteme und Treiber damit ebenfalls sehr effizient geschrieben werden." im Artikel daher für irreführend, zumindest aber unbelegt. Vlt. könnte man über etwas aktuellere Entwicklungen, z.B. Rust, schreiben, anstatt die Modula-2-basierte Entwicklung von Betriebssystemen zu propagieren. In jedem Fall sollte dieser Satz aus dem Artikel entfernt werden. --132.195.80.75 15:03, 15. Apr. 2021 (CEST)

es werden keine sicherheitsluecken auf www.computec.ch veroefentlicht

moin,

ich war eine lange zeit lang im www.computec.ch forum aktiv und kenne die seite beinahe auswendigwie auch immer:dort werden keine sicherheitsluecken veroefentlicht!

wieleicht sollte man den link loeschen?


danke


IE-Sicherheitslücke und Angriff auf Google (Januar 2010)

Kritische Sicherheitslücke im Internet Explorer : BSI empfiehlt die vorübergehende Nutzung alternativer Browserhttps://www.bsi.bund.de/cln_183/ContentBSI/presse/Pressemitteilungen/Sicherheitsluecke_IE_150110.htmlhttp://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)

Begriffsprägung

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)

Programmzeile kein sinnvolles Maß

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))

Korrektur des Artikels

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)

Verständnisfrage

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)

Begriff der Sicherheitslücke - Nur auf Software beschränkt?

Hallo, der Artikel definiert die Sicherheitslücke als eine Schwachstelle allein der Software. Andere Artikel (z.B. der Artikel "Spectre (Sicherheitslücke)" erfasst aber auch Hardware-Fehler als Sicherheitslücken. Denkbar sind auch menschliche Sicherheitslücken (Stichwort "social engineering" und "praktische Umsetzung von IT-Sicherheit").Sollte der Artikel dahingehend erweitert werden? (nicht signierter Beitrag von JurWerk (Diskussion | Beiträge) 10:48, 25. Aug. 2021 (CEST))

Stimmt. Habe den Hardwarefehler in die Einleitung mit aufgenommen. ‣Andreas 13:04, 25. Aug. 2021 (CEST)
Habe den Artikel umbenannt in Sicherheitslücke (Computer), weil es auch im allgemeinen Sprachgebrauch die "Sicherheitslücke" im ganz allgemeinen Sinn gibt. Das kann einfach alles sein, so wie die Sicherheit selbst, siehe z.B. Sicherheit (Begriffsklärung). Damit ist der Artikel nun eine WL von Sicherheitslücke mit WP:BKL II, und ich gehe davon aus, dass das so passt, da es sicher die häufigste Nutzung des Begriffs ist. Dennoch darf man mMn die allgemeine Bedeutung nicht totschweigen, weshalb ich auch Sicherheitslücke (Begriffsklärung) erstellt habe.
Andreas 13:58, 17. Sep. 2022 (CEST)
Jetzt fehlt nur noch der Artikel Sicherheitslücke --Vfb1893 (Diskussion) 14:16, 17. Sep. 2022 (CEST)
Eigentlich nicht. Vgl. Sicherheit. ‣Andreas 14:19, 17. Sep. 2022 (CEST)
Das ist aktuell nicht vergleichbar. Bei Sicherheit ist ein Artikel und keine Weiterleitung vorhanden. Die BKL II soll ermöglichen, dass der Leser den Artikel zur Hauptbedeutung direkt erreichen kann. Hier landet er aber auf einer Weiterleitung, die zu einem Teilaspekt führt. --Vfb1893 (Diskussion) 15:17, 17. Sep. 2022 (CEST)
Stimmt. Dann wäre die Umbenennung doch rückgängig zu machen. Wichtig wäre nur, dass die Verlinkung darauf in anderen Artikeln spezifisch passieren sollte, denn irgendwann es ist ja nicht auszuschließen, dass doch mal ein allgemeiner Artikel entsteht. Ich wüsste zwar nicht, mit welchen Quellen, aber es gibt Indizien-Quellen, die die "Sicherheitslücke" eben eindeutig nicht Computer-bezogen verwenden, was dann eben einer Allgemein-Bedeutung des Begriffs gleichkommt. Aber für einen Artikel reicht das natürlich nicht.
Also: wieder zurück? Soll ich das erledigen? ‣Andreas 17:37, 17. Sep. 2022 (CEST)
Das wäre die eine Alternative. Aus meiner Sicht auch die bessere. Man kann auch Sicherheitslücke (Begriffsklärung) nach Sicherheitslücke verschieben. Dann müsste aber die software-bezogenen Links auf Sicherheitslücke auf Sicherheitslücke (Computer) angepasst werden. Es wäre nett wenn du den ungünstigen Zustand beseitigst. --Vfb1893 (Diskussion) 17:55, 17. Sep. 2022 (CEST)
Was ist denn bevorzugt/besser? ‣Andreas 19:22, 17. Sep. 2022 (CEST)

Ich bezog mich dabei auf dein wieder zurück, also die Wiederherstellung des ursprünglichen Zustandes. Vfb1893 (Diskussion) 19:44, 17. Sep. 2022 (CEST)

Erledigt. Nur nochmal zum Nachlesen, dass es die Sicherheitslücke auch im ganz allgemeinen Sinn gibt (Unterstreichung von mir):
Andreas 20:14, 17. Sep. 2022 (CEST)

Sicherheitslücke leicht zugängliches Passwort

mögliche klassische Sicherheitslücke: ablesbare Logindaten

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)

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)