Achtung! Diese Übersetzung ist zu alt, benutzen Sie bitte das Original.
Debian Sicherheits-FAQ
- Ich habe eine Sicherheitsankündigung über debian-security-announce erhalten, wie kann ich die verwundbaren Pakete aktualisieren?
- Die Signatur eurer Ankündigungen kann nicht korrekt verifiziert werden!
- Wie wird die Sicherheit in Debian gehandhabt?
- Wieso trödeln Sie mit einer alten Version des Pakets herum?
- Die Versionsnummer für ein Paket zeigt an, dass ich immer noch eine verwundbare Version verwende!
- Ich habe eine Ankündigung erhalten, aber der Build des Pakets für eine Prozessorarchitektur scheint zu fehlen.
- Wie wird die Sicherheit für Unstable gehandhabt?
- Wie wird die Sicherheit für Testing gehandhabt?
- Wie wird die Sicherheit für contrib und non-free gehandhabt?
- Die Ankündigung sagt, dass Unstable in Version 1.2.3-1 korrigiert sei, aber 1.2.5-1 ist in Unstable. Was ist da los?
- Wieso gibt es keine offiziellen Spiegel-Server für security.debian.org?
- Ich habe DSA 100 und DSA 102 gesehen, wo ist aber DSA 101?
- Wie erreiche ich das Sicherheitsteam?
- Ich glaube, ich habe ein Sicherheitsproblem entdeckt, was soll ich tun?
- Was soll ich bei einem Sicherheitsproblem in einem meiner Pakete tun?
- Ich habe versucht, ein Paket herunterzuladen, das in einer der Sicherheitsankündigungen aufgeführt war, aber ich bekomme dabei einen
file not found
-Fehler. - Ich habe eine Fehlerkorrektur, kann ich direkt auf security.debian.org hochladen?
- Ich habe eine Fehlerkorrektur, kann ich diese stattdessen nach proposed-updates hochladen?
- Ich bin ziemlich sicher, dass meine Pakete in Ordnung sind, wie kann ich sie hochladen?
- Wie kann ich bei der Sicherheit helfen?
- Was umfasst proposed-updates?
- Wie setzt sich das Sicherheitsteam zusammen?
- Wie lange sind Sicherheitsaktualisierungen vorgesehen?
- Wie kann ich die Integrität der Pakete prüfen?
- Was soll ich tun, wenn ein zufälliges Paket nach einer Sicherheitsaktualisierung nicht mehr funktioniert?
- Was ist ein CVE-Identifier?
- Gibt Debian für jede CVE-ID eine Sicherheitsankündigung (DSA) heraus?
- Kann Debian CVE-Identifier vergeben?
- Hat Debian eine Richtlinie betreffend die Enthüllung von Sicherheitslücken (Vulnerability Disclosure Policy)?
- Was bedeutet
local (remote)
(lokal (aus der Ferne))?
A: Wie es schon in der E-Mail mit der Sicherheitsankündigung steht, sollten Sie die von der Verwundbarkeit betroffenen Pakete aktualisieren. Sie können dies tun, indem Sie (nach dem Aktualisieren der Liste verfügbarer Pakete mittels apt-get update) einfach jedes Paket in Ihrem System mit apt-get upgrade aktualisieren. Sie können aber auch nur ein bestimmtes Paket aktualisieren, indem Sie apt-get install Paket aufrufen.
Die Ankündigungs-E-Mail erwähnt das Quellpaket, in dem die Verwundbarkeit aufgetreten ist. Daher sollten Sie alle Binärpakete aktualisieren, die aus diesem Quellpaket erstellt werden. Um herauszubekommen, welche Binärpakete aktualisiert werden müssen, rufen Sie https://packages.debian.org/src:Quellpaket-Name auf und klicken auf [Zeige ... Binärpakete] für die Distribution, die Sie aktualisieren wollen.
Es kann auch notwendig sein, einen Service oder laufenden Prozess neu zu starten. Der Befehl checkrestart, der im Paket debian-goodies enthalten ist, kann dabei helfen, herauszufinden, welche Services oder Prozesse dies sind.
F: Die Signatur eurer Ankündigungen kann nicht korrekt verifiziert werden!
A: Das ist höchstwahrscheinlich ein Problem auf Ihrer Seite. Die debian-security-announce-Liste besitzt einen Filter, der sicherstellt, dass nur Nachrichten mit einer korrekten Signatur eines Mitglieds des Sicherheitsteams versendet werden.
Die häufigste Ursache dafür ist zumeist ein E-Mail-Programm auf Ihrer Seite, das die Nachricht leicht verändert und dadurch die Signatur ungültig macht. Versichern Sie sich, dass Ihre Software keine MIME-Entschlüsselung oder -Verschlüsselung durchführt und auch keine Tabulator/Leerzeichen-Konvertierungen vornimmt.
Bekannte Übeltäter sind fetchmail (mit der Option mimedecode), formail (von procmail 3.14) und evolution.
F: Wie wird die Sicherheit in Debian gehandhabt?
A: Wenn das Sicherheitsteam auf einen Vorfall aufmerksam wird, überprüfen ihn ein oder mehrere Mitglieder und bewerten seinen Einfluss auf das Stable-Release von Debian (z.B. ob es verwundbar ist oder nicht). Wenn unser System verwundbar ist, arbeiten wir an einer Problembehebung. Der Paketbetreuer wird ebenfalls kontaktiert, wenn dieser nicht bereits selbst das Sicherheitsteam kontaktiert hat. Schlussendlich wird die Behebung des Problems getestet und neue Pakete vorbereitet, die dann auf allen Stable-Architekturen übersetzt und anschließend hochgeladen werden. Nachdem das alles geschehen ist, wird eine Ankündigung veröffentlicht.
F: Wieso trödeln Sie mit einer alten Version des Pakets herum?
Die wichtigste Regel beim Erstellen eines neuen Pakets, das ein Sicherheitsproblem behebt, ist, so wenig Änderungen wie möglich vorzunehmen. Unsere Benutzer und Entwickler vertrauen auf das fehlerfreie Verhalten eines Releases nach dessen Freigabe, daher kann jede Änderung, die wir durchführen, möglicherweise das System von jemandem zerstören. Dies gilt insbesondere für Bibliotheken: Es muss darauf geachtet werden, dass sich das Anwendungs-Programm-Interface (API) oder Anwendungs-Binär-Interface (ABI) niemals ändert, egal wie klein die Änderung ist.
Dies bedeutet, dass das Umsteigen auf eine neue Upstream-Version keine gute Lösung ist und stattdessen die relevanten Änderungen zurückportiert werden sollten. Üblicherweise sind die Upstream-Betreuer, wenn notwendig, bereit zu helfen, falls das Debian Sicherheitsteam nicht helfen kann.
In einigen Fällen ist es nicht möglich, eine Sicherheitskorrektur zurückzuportieren, zum Beispiel, wenn ein großer Teil des Quellcodes modifiziert oder neu geschrieben werden muss. Wenn dies passiert, kann es notwendig sein, auf eine neue Upstream-Version umzusteigen, aber dies muss zuvor mit dem Sicherheitsteam koordiniert werden.
F: Die Versionsnummer für ein Paket zeigt an, dass ich immer noch eine verwundbare Version verwende!
A: Anstatt auf ein neues Release zu aktualisieren, portieren wir die Sicherheits-Fixes auf die Version zurück, die mit dem Stable-Release ausgeliefert wurde. Wir tun dies, um zu garantieren, dass eine Veröffentlichung sich so wenig wie möglich ändert, damit als Resultat des Sicherheits-Fixes keine unerwünschten Änderungen oder unerwarteten Probleme auftreten. Sie können überprüfen, ob Sie eine sichere Version eines Paketes verwenden, indem Sie in die changelog-Datei des Paketes schauen, oder seine exakte Versionsnummer mit der angezeigten Version in der Debian-Sicherheitsankündigung vergleichen.
A: Im Allgemeinen veröffentlicht das Sicherheitsteam Sicherheitsankündigungen mit Builds der aktualisierten Pakete für alle Architekturen, die Debian unterstützt. Allerdings sind einige Architekturen schneller als andere und es könnte vorkommen, dass die Builds für die meisten Architekturen fertig sind, während einige noch fehlen. Diese seltener verwendeten Architekturen repräsentieren einen kleinen Teil unserer Benutzerbasis. Abhängig von der Dringlichkeit des Problems könnten wir uns dafür entscheiden, die Ankündigung ohne weitere Verzögerung zu veröffentlichen. Die fehlenden Builds werden installiert, sobald sie verfügbar sind, jedoch ohne einen weiteren Hinweis hierzu. Natürlich werden wir niemals eine Ankündigung veröffentlichen, wenn dazu die Builds für i386 oder amd64 noch nicht vorhanden sind.
F: Wie wird die Sicherheit für Unstable gehandhabt?
A: Die Sicherheit für Unstable wird primär durch die Paketbetreuer bewerkstelligt, nicht durch das Debian-Sicherheitsteam. Obwohl das Sicherheitsteam auch Korrekturen mit hoher Dringlichkeit zum Zwecke der Behebung von Sicherheitsproblemen hochladen kann, wenn festgestellt wird, dass der Betreuer nicht aktiv wird, hat die Sicherheitsunterstützung für Stable immer Priorität. Falls Sie einen sicheren (und stabilen) Server benötigen, wird Ihnen nachdrücklich empfohlen, bei Stable zu bleiben.
F: Wie wird die Sicherheit für Testing gehandhabt?
A: Die Sicherheit für Testing profitiert von den Bemühungen des ganzen Projekts, die Sicherheit für Unstable zu gewährleisten. Allerdings gibt es eine minimale zweitägige Verzögerung für die Migration der Korrekturen und manchmal können Sicherheitskorrekturen auch durch Versionsübergänge verzögert/aufgehalten werden. Das Sicherheitsteam hilft bei solchen Übergängen, indem wichtige Sicherheits-Uploads zurückgehalten werden, aber dies ist nicht immer möglich und dabei könnten auch Verzögerungen auftreten. Speziell in den Monaten nach einer neuen Stable-Veröffentlichung, wenn viele neue Versionen nach Unstable hochgeladen werden, könnten Sicherheitskorrekturen für Testing hinterher hinken. Falls Sie einen sicheren (und stabilen) Server benötigen, wird Ihnen nachdrücklich empfohlen, bei Stable zu bleiben.
F: Wie wird die Sicherheit für contrib und non-free gehandhabt?
A: Die kurze Antwort ist: gar nicht. Contrib und non-free sind nicht offizieller Bestandteil der Debian-Distribution und werden nicht freigegeben und daher nicht vom Sicherheitsteam unterstützt. Einige non-free-Pakete werden ohne Quellcode vertrieben oder ohne eine Lizenz, die die Verteilung von geänderten Versionen erlauben würde. In diesen Fällen ist es überhaupt nicht möglich, Sicherheitskorrekturen durchzuführen. Falls es möglich ist, das Problem zu beheben und der Paketbetreuer oder jemand anderes korrekte, aktualisierte Pakete zur Verfügung stellt, wird das Security-Team diese normalerweise bearbeiten und eine Ankündigung veröffentlichen.
A: Wir versuchen, die erste Version in Unstable anzugeben, bei der das Problem behoben wurde. Manchmal hat der Betreuer in der Zwischenzeit noch neuere Versionen hochgeladen. Vergleichen Sie die Version in Unstable mit der angegebenen Version. Falls erstere identisch oder höher ist als die zweite, sollten Sie vor der Verwundbarkeit geschützt sein. Wenn Sie ganz sicher gehen wollen, können Sie das Changelog des Pakets mit apt-get changelog Paketname überprüfen und nach dem Eintrag suchen, der die Fehlerkorrektur erwähnt.
F: Wieso gibt es keine offiziellen Spiegel-Server für security.debian.org?
A: Tatsächlich gibt es diese. Es existieren mehrere offizielle Spiegel, die als DNS-Alias implementiert sind. Der Zweck von security.debian.org besteht darin, Sicherheitsaktualisierungen so schnell und einfach wie möglich zur Verfügung zu stellen.
Die Empfehlung, inoffizielle Spiegel zu verwenden, würde zusätzliche Komplexität hinzufügen, was normalerweise unnötig ist und frustrierend sein kann, falls diese Spiegel nicht aktuell gehalten werden.
F: Ich habe DSA 100 und DSA 102 gesehen, wo ist aber DSA 101?
A: Einige Distributoren (hauptsächlich von GNU/Linux, aber auch von BSD-Derivaten) koordinieren Sicherheitsankündigungen für einige Vorfälle und stimmen miteinander eine gemeinsame Zeitlinie ab, damit alle Distributoren die Möglichkeit haben, eine Ankündigung zur gleichen Zeit zu veröffentlichen. Dadurch soll verhindert werden, dass ein Distributor diskriminiert wird, der mehr Zeit benötigt (z.B. falls der Hersteller längere Qualitätssicherungs-Tests für die Pakete durchführt, oder mehrere Architekturen bzw. Binär-Distributionen unterstützt). Unser eigenes Sicherheitsteam bereitet ebenfalls Ankündigungen im Vornherein vor. Es passiert immer wieder mal, dass andere Sicherheitsankündigungen früher abgearbeitet werden müssen, als vorbereitete Ankündigungen veröffentlicht werden können, und daher wird temporär eine oder mehrere Ankündigungen der Nummer nach ausgelassen.
F: Wie erreiche ich das Sicherheitsteam?
A: Sicherheitsinformationen können an [email protected] oder [email protected] geschickt werden, unter beiden Adressen erreichen Sie die Mitglieder des Sicherheitsteams.
Falls gewünscht, können die E-Mails mit dem Debian-Sicherheitskontakt-Schlüssel (Schlüssel-ID 0x0D59D2B15144766A14D241C66BAF400B05C3E651) verschlüsselt werden. Für die PGP-/GPG-Schlüssel der Mitglieder des Sicherheitsteams schauen Sie bitte auf den Schlüsselserver keyring.debian.org.
F: Ich glaube, ich habe ein Sicherheitsproblem entdeckt, was soll ich tun?
A: Wenn Sie von einem Sicherheitsproblem erfahren, entweder in einem Ihrer eigenen Pakete oder in dem eines anderen Entwicklers, dann kontaktieren Sie bitte auf jeden Fall das Sicherheitsteam. Wenn das Debian-Sicherheitsteam die Verwundbarkeit bestätigt und andere Distributoren höchstwahrscheinlich ebenfalls davon betroffen sind, wird es diese üblicherweise auch kontaktieren. Wenn die Verwundbarkeit noch nicht öffentlich bekannt ist, wird es versuchen, die Sicherheitsankündigungen mit den anderen Distributoren zu koordinieren, damit alle Haupt-Distributionen synchron sind.
Falls die Verwundbarkeit bereits öffentlich bekannt ist, schreiben Sie
bitte unbedingt einen Fehlerbericht für die
Debian-Fehlerdatenbank und markieren Sie ihn mit dem Tag
security
.
Falls Sie ein Debian-Entwickler sind, lesen Sie unten weiter.
F: Was soll ich bei einem Sicherheitsproblem in einem meiner Pakete tun?
A: Wenn Sie von einem Sicherheitsproblem erfahren, sei es in einem Ihrer Pakete oder in dem eines anderen Entwicklers, kontaktieren Sie bitte auf jeden Fall das Sicherheitsteam per E-Mail unter [email protected]. Die Mitglieder des Teams behalten die Übersicht über offene Sicherheitsprobleme, können den Betreuern mit Sicherheitsproblemen helfen oder die Probleme selbst beheben und sind verantwortlich für das Versenden der Sicherheitsankündigungen und die Betreuung von security.debian.org.
Die Entwicklerreferenz enthält vollständige Informationen darüber, was zu tun ist.
Es ist im Speziellen wichtig, dass Sie Pakete in keine andere Distribution außer Unstable ohne vorherige Zustimmung vom Sicherheitsteam hochladen, da das Umgehen davon Verwirrung stiftet und weiteren Aufwand verursacht.
A: Immer, wenn eine neuere Fehlerkorrektur ein älteres Paket auf
security.debian.org ersetzt, stehen die Chancen gut, dass das ältere
Paket gelöscht wird, wenn das neue installiert wird. Daher erhalten Sie
diesen file not found
-Fehler. Wir wollen Pakete mit bekannten
Sicherheitslücken nicht länger als absolut notwendig verbreiten.
Bitte benutzen Sie die Pakete aus den neuesten Sicherheitsankündigungen, die
über die debian-security-announce-Mailingliste verteilt werden. Am besten rufen
Sie einfach apt-get update auf, bevor Sie das Paket
aktualisieren.
F: Ich habe eine Fehlerkorrektur, kann ich direkt auf security.debian.org hochladen?
A: Nein, können Sie nicht. Das Archiv auf security.debian.org wird vom Sicherheitsteam betreut, das alle Pakete genehmigen muss. Sie sollten stattdessen Patches oder passende Quellcode-Pakete via [email protected] an das Sicherheitsteam schicken. Diese werden dann vom Sicherheitsteam überprüft und gegebenenfalls hochgeladen, entweder mit oder ohne weitere Änderungen.
Die Entwicklerreferenz enthält vollständige Informationen darüber, was zu tun ist.
F: Ich habe eine Fehlerkorrektur, kann ich diese stattdessen nach proposed-updates hochladen?
A: Technisch gesehen können Sie es. Jedoch sollten Sie es nicht tun, da
dies böse mit der Arbeit des Sicherheitsteams kollidieren kann. Pakete von
security.debian.org werden automatisch in das proposed-updates-Verzeichnis
kopiert. Falls ein Paket mit der gleichen oder einer höheren Versionsnummer
bereits in das Archiv eingespielt wurde, wird die Sicherheitsaktualisierung
vom Archiv-System zurückgewiesen. Auf diese Art wird die Stable-Distribution
die Sicherheitsaktualisierung für dieses Paket nicht
enthalten, außer wenn das falsche
Paket im
proposed-updates-Verzeichnis zurückgewiesen wurde. Bitte kontaktieren Sie
stattdessen das
Sicherheitsteam: Fügen Sie alle
Details über die Verwundbarkeit bei und hängen Sie die Quelldateien (d.h.
diff.gz- und dsc-Dateien) an die E-Mail an.
Die Entwicklerreferenz enthält vollständige Informationen darüber, was zu tun ist.
F: Ich bin ziemlich sicher, dass meine Pakete in Ordnung sind, wie kann ich sie hochladen?
A: Wenn Sie sich sehr sicher sind, dass ihre Pakete nichts zerstören, dass
die Versionsnummer sauber ist (z.B. größer als die Version in Stable und kleiner
als die Version in Testing/Unstable), dass Sie kein Verhalten des Pakets
geändert haben, trotz des entsprechenden Sicherheitsproblems, dass Sie es
für die richtige Distribution übersetzt haben (also
oldstable-security oder stable-security), dass
das Paket den ursprünglichen Quellcode enthält, falls das Paket neu auf
security.debian.org ist, dass Sie bestätigen können, dass der Patch gegen
die aktuellste Version sauber ist und nur das entsprechende
Sicherheitsproblem betrifft (prüfen Sie mit interdiff -z und
beiden .diff.gz-Dateien), dass Sie den Patch zumindest
dreimal Korrektur gelesen haben, und dass debdiff keine
Änderungen anzeigt, dürfen Sie die Dateien direkt in das incoming-Verzeichnis
ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue
auf security.debian.org hochladen. Bitte senden Sie auch eine
Benachrichtigung mit allen Details und Links an [email protected].
F: Wie kann ich bei der Sicherheit helfen?
A: Bitte prüfen Sie jedes Problem nach, bevor Sie es an [email protected] berichten. Wenn es Ihnen möglich ist, Patches zur Verfügung zu stellen, würde das den Prozess beschleunigen. Leiten Sie nicht einfach bugtraq-E-Mails weiter, da wir diese bereits empfangen – teilen Sie uns stattdessen zusätzliche Informationen zu Dingen mit, die auf bugtraq gemeldet wurden.
Eine gute Art mit der Sicherheitsarbeit zu beginnen ist es, beim Debian Sicherheits-Tracker zu helfen (Anleitung).
F: Was umfasst proposed-updates?
A: Dieses Verzeichnis beinhaltet Pakete, die für die nächste Aktualisierung von Debian Stable vorgeschlagen sind. Wann immer ein Paket von einem Paketbetreuer für die Stable-Distribution hochgeladen wird, werden diese im proposed-updates Verzeichnis abgelegt. Da Stable dafür gedacht ist, stabil zu sein, werden keine automatischen Aktualisierungen durchgeführt. Das Sicherheitsteam wird korrigierte Pakete aus ihren Sicherheitsankündigungen für Stable hochladen, jedoch werden diese zuerst in proposed-updates abgelegt. Alle paar Monate prüft der Stable-Release-Manager die Liste der Pakete in proposed-updates und diskutiert, ob ein Paket für Stable geeignet ist oder nicht. Daraus wird eine neue Zwischenveröffentlichung von Stable zusammengestellt (z.B. 7.4 oder 7.6). Pakete, die nicht passen, werden wahrscheinlich von proposed-updates ebenfalls zurückgewiesen.
Beachten Sie, dass vom Paketbetreuer (nicht vom Sicherheitsteam) hochgeladene Pakete im Verzeichnis proposed-updates/ nicht vom Sicherheitsteam unterstützt werden.
F: Wie setzt sich das Sicherheitsteam zusammen?
A: Das Debian-Sicherheitsteam besteht aus mehreren Beauftragten und Unterstützern. Das Sicherheitsteam selbst bestimmt die Leute, die dem Team beitreten.
F: Wie lange sind Sicherheitsaktualisierungen vorgesehen?
A: Das Sicherheitsteam versucht eine stabile Distribution für in etwa ein Jahr zu unterstützen, nachdem die nächste stabile Distribution freigegeben wurde; außer, eine weitere stabile Distribution wird innerhalb dieser Zeitspanne freigegeben. Es ist nicht möglich, drei Distributionen zu unterstützen; die gleichzeitige Unterstützung für zwei ist bereits schwierig genug.
F: Wie kann ich die Integrität der Pakete prüfen?
A: Dieser Prozess umfasst das Prüfen der Release-Datei-Signatur gegen den öffentlichen Schlüssel, der für die Archive verwendet wird. Die Release-Datei enthält Prüfsummen der Packages- und Sources-Dateien, die wiederum Prüfsummen der Binär- und Quellcodepakete enthalten. Ausführlichere Anweisungen, wie man die Paket-Integrität prüfen kann, können im Securing-Debian-Handbuch nachgelesen werden.
A: Zuerst sollten Sie herausfinden, warum dieses Paket nicht mehr funktioniert und wie es mit der Sicherheitsaktualisierung zusammenhängt. Danach sollten Sie sich an das Sicherheitsteam wenden, wenn es ein schwerwiegendes Problem ist, oder an den Stable-Release-Betreuer, wenn es weniger schwerwiegend ist. Es geht hier um zufällige Pakete, die nach der Aktualisierung eines anderen Paketes nicht mehr funktionieren. Wenn Sie nicht herausfinden können, was schief läuft, aber eine Lösung gefunden haben, wenden Sie sich auch an das Sicherheitsteam. Es könnte jedoch sein, dass man Sie an den Stable-Release-Manager weiterleitet.
F: Was ist ein CVE-Identifier?
A: Das Common Vulnerabilities and Exposures
-Projekt
weisst spezifischen Verwundbarkeiten eindeutige Bezeichner, sogenannte
CVE-Identifier zu, um den Verweis auf spezielle Sicherheitsprobleme
zu vereinfachen. Weitere Informationen finden Sie in der Wikipedia.
F: Gibt Debian für jede CVE-ID eine Sicherheitsankündigung (DSA) heraus?
A: Debians Sicherheitsteam verfolgt jede veröffentlichte CVE-ID, verbindet sie mit dem relevanten Debian-Paket und beurteilt ihren Einfluß in Bezug auf Debian - die Tatsache, dass für irgendetwas eine CVE-ID herausgegeben wurde, impliziert nicht zwingend, dass dies eine ernsthafte Bedrohung für ein Debian-System darstellt. Diese Informationen werden im Debian Sicherheits-Tracker festgehalten und für die Probleme, die für Debian als bedrohlich betrachtet werden, werden Sicherheitsankündigungen veröffentlicht.
Probleme mit geringen Auswirkungen, die keine DSA erforderlich machen, können in der nächsten Debian-Veröffentlichung oder in einer Zwischenveröffentlichung der aktuellen Stable- bzw. Oldstable-Distribution behoben werden oder sie werden in eine DSA integriert, die wegen gravierenderen Verwundbarkeiten herausgebracht wird.
F: Kann Debian CVE-Identifier vergeben?
A: Debian hat den Status einer CVE Numbering Authority und kann CVE-IDs vergeben, aber gemäß CVE-Richtlinie nur für noch geheim gehaltene Sicherheitsprobleme. Falls Sie Kenntnis von einer noch unveröffentlichten Sicherheitslücke bei einer Software in Debian haben und eine CVE-ID dafür bekommen möchten, kontaktieren Sie das Debian Sicherheitsteam. Für Fälle, bei denen das Problem bereits öffentlich ist, empfehlen wir, dem unter CVE OpenSource Request HOWTO beschriebenen Prozedere zu folgen.
A: Debian hat eine solche Richtlinie im Rahmen der Teilnahme am CVE-Programm veröffentlicht.
Veraltete Debian Sicherheits-FAQ
F: Was bedeutet local (remote)
(lokal
(aus der Ferne))?
Das Feld Problem type in DSA-Mails wird seit April 2014 nicht mehr verwendet.
A: Einige Ankündigungen decken Verwundbarkeiten ab, die nicht mit dem klassischen
Schema von lokalen Verwundbarkeiten und Verwundbarkeiten aus der Ferne
identifiziert werden
können. Einige Verwundbarkeiten können nicht aus der Ferne ausgenutzt werden,
d.h. sie beziehen sich nicht auf einen Daemon, der auf einer Netzwerkschnittstelle
horcht. Falls sie durch spezielle Dateien ausgenutzt werden können, die
über das Netz bereit gestellt werden, der verwundbare Dienst aber nicht
permanent mit dem Netz verbunden ist, schreiben wir in diesen Fällen
local (remote)
.
Diese Verwundbarkeiten liegen irgendwo zwischen lokalen und solchen aus der Ferne und decken oft Archive ab, die über das Netz bereitgestellt werden könnten, z.B. E-Mail-Anhänge oder Dateien von einer Download-Seite.