--- title: Kapitel 11. Sicherheit der Ports prev: books/porters-handbook/port-upgrading next: books/porters-handbook/porting-dads showBookMenu: true weight: 11 params: path: "/books/porters-handbook/security/" --- [[security]] = Sicherheit der Ports :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 11 :partnums: :source-highlighter: rouge :experimental: :images-path: books/porters-handbook/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[security-intro]] == Warum Sicherheit so wichtig ist Es finden sich immer wieder Fehler in Software. Die gefährlichsten davon sind wohl jene, die Sicherheitslücken öffnen. Technisch gesehen müssen diese Lücken geschlossen werden, indem die Fehler, die Sie verursacht haben, beseitigt werden. Aber die Vorgehensweisen, wie mit bloßen Fehlern und Sicherheitslücken umgegangen wird, sind sehr unterschiedlich. Ein typischer kleiner Fehler betrifft nur Nutzer, die eine bestimmte Kombination von Optionen aktiviert haben, die den Fehler auslöst. Der Entwickler wird letztendlich einen Patch herausgeben, gefolgt von einer neuen Version des Programms, die den Fehler nicht mehr enthält - jedoch wird die Mehrheit der Nutzer nicht sofort aktualisieren, da sie von diesem Fehler nicht betroffen sind. Ein kritischer Fehler, der zu Datenverlust führen kann, stellt ein schwerwiegendes Problem dar. Dennoch sind sich umsichtige Nutzer bewusst, dass Datenverlust verschiedene Ursachen - neben Softwarefehlern - haben kann, und machen deshalb Sicherungskopien wichtiger Daten. Zumal ein kritischer Fehler sehr schnell entdeckt wird. Bei einer Sicherheitslücke ist dies ganz anders. Erstens wird sie vielleicht jahrelang nicht entdeckt, da dies oftmals keine Fehlfunktion im Programm verursacht. Zweitens kann eine böswillige Person unerlaubten Zugriff auf ein unsicheres System erlangen, um empfindliche Daten zu verändern oder zu zerstören; im schlimmsten Fall findet der Nutzer nicht einmal die Ursache des Schadens. Drittens hilft der Zugriff auf ein unsicheres System dem Angreifer oft in ein anderes System einzudringen, welches ansonsten nicht gefährdet wäre. Deshalb reicht es nicht aus eine Sicherheitslücke nur zu schließen: Die Zielgruppe sollte möglichst genau und umfassend darüber informiert werden, damit sie die Gefahr einschätzen und passende Maßnahmen ergreifen können. [[security-fix]] == Sicherheitslücken schliessen Bei Ports und Paketen kann eine Sicherheitslücke im ursprünglichen Programm oder in den Port-Dateien verursacht werden. Im ersten Fall wird der ursprüngliche Entwickler den Fehler wahrscheinlich umgehend korrigieren oder eine neue Version herausgeben und Sie müssen den Port nur aktualisieren und die Korrekturen des Autors beachten. Falls sich die Korrektur aus irgendeinem Grund verzögert, sollten Sie <> oder selbst den Fehler für den Port korrigieren. Falls die Sicherheitslücke im Port verursacht wird, sollten Sie ihn sobald wie möglich berichtigen. In jedem Fall sollte <> beachtet werden - es sei denn, Sie haben das Recht diese direkt in den Ports-Baum zu committen. [IMPORTANT] ==== Ports-Committer zu sein ist nicht genug, um Änderungen an einem beliebigen Port zu committen. Bitte denken Sie daran, dass Ports üblicherweise Maintainer haben, die Sie respektieren sollten. ==== Bitte stellen Sie sicher, dass die Revision des Ports erhöht wird, sobald die Sicherheitslücke geschlossen wurde. Dadurch sehen die Nutzer, die installierte Pakete regelmäßig aktualisieren, dass es an der Zeit ist eine Aktualisierung durchzuführen. Außerdem wird ein neues Paket gebaut, über FTP- und WWW-Spiegel verteilt und die unsichere Version damit verdrängt. `PORTREVISION` sollte erhöht werden - es sei denn, `PORTREVISION` hat sich im Laufe der Korrektur des Fehlers geändert. Das heißt, Sie sollten `PORTREVISION` erhöhen, wenn Sie eine Korrektur hinzugefügt haben. Sie sollten diese aber nicht erhöhen, wenn Sie den Port auf die neueste Version des Programms gebracht haben und `PORTREVISION` somit schon verändert wurde. Bitte beachten Sie den <> für weitere Informationen. [[security-notify]] == Die Community informiert halten [[security-notify-vuxml-db]] === Die VuXML-Datenbank Ein sehr wichtiger und dringender Schritt, den man unternehmen muss, sobald eine Sicherheitslücke entdeckt wurde, ist die Gemeinschaft der Anwender des Ports über die Gefahr zu informieren. Diese Benachrichtigung hat zwei Gründe. Erstens wird es sinnvoll sein, wenn die Gefahr wirklich so groß ist, sofort Abhilfe zu schaffen, indem man z.B. den betreffenden Netzwerkdienst beendet oder den Port komplett deinstalliert, bis die Lücke geschlossen wurde. Und Zweitens pflegen viele Nutzer installierte Pakete nur gelegentlich zu aktualisieren. Sie werden aus der Mitteilung erfahren, dass Sie das Paket, sobald eine Korrektur verfügbar ist, sofort aktualisieren _müssen_. Angesichts der riesigen Zahl an Ports kann nicht für jeden Vorfall ein Sicherheitshinweis erstellt werden, ohne durch die Flut an Nachrichten die Aufmerksamkeit der Empfänger zu verlieren, im Laufe der Zeit kommt es so zu ernsten Problemen. Deshalb werden Sicherheitslücken von Ports in http://vuxml.freebsd.org/[der FreeBSD VuXML-Datenbank] aufgezeichnet. Das Team der Sicherheitsverantwortlichen beobachtet diese wegen Angelegenheiten, die Ihr Eingreifen erfordern. Wenn Sie Committerrechte haben, können Sie die VuXML-Datenbank selbst aktualisieren. Auf diese Weise helfen Sie den Sicherheitsverantwortlichen und liefern die kritischen Informationen frühzeitig an die Community. Aber auch wenn Sie kein Committer sind und glauben, Sie haben eine außergewöhnlich schwerwiegende Lücke gefunden - egal welche - zögern Sie bitte nicht die Sicherheitsverantwortlichen zu kontaktieren, wie es in den http://www.freebsd.org/security/#how[FreeBSD Sicherheitsinformationen] beschrieben wird. Wie vielleicht aus dem Titel hervorgeht, handelt es sich bei der VuXMl-Datenbank um ein XML-Dokument. Die Quelldatei [.filename]#vuln.xml# können Sie im Port package:security/vuxml[] finden. Deshalb wird der komplette Pfadname [.filename]#PORTSDIR/security/vuxml/vuln.xml# lauten. Jedes Mal, wenn Sie eine Sicherheitslücke in einem Port entdecken, fügen Sie bitte einen Eintrag dafür in diese Datei ein. Solange Sie nicht mit VuXML vertraut sind, ist es das Beste, was Sie machen können, einen vorhandenen Eintrag, der zu Ihrem Fall passt, zu kopieren und als Vorlage zu verwenden. [[security-notify-vuxml-intro]] === Eine kurze Einführung in VuXML Das komplette XML ist komplex und würde den Rahmen dieses Buches sprengen. Allerdings benötigen Sie für einen grundlegenden Einblick in die Struktur eines VuXML-Eintrags nur eine Vorstellung der Tags. XML-Tags bestehen aus Namen, die in spitzen Klammern eingeschlossen sind. Zu jedem öffnenden muss ein passendes existieren. Tags können geschachtelt werden. Wenn sie geschachtelt werden müssen die inneren Tags vor den Äußeren geschlossen werden. Es gibt eine Hierarchie von Tags - das heißt komplexere Regeln zur Schachtelung. Klingt so ähnlich wie HTML, oder? Der größte Unterschied ist: XML ist erweiterbar (e__X__tensible) - das heißt es basiert darauf maßgeschneiderte Tags zu definieren. Aufgrund seiner wesentlichen Struktur bringt XML ansonsten formlose Daten in eine bestimmte Form. VuXML ist speziell darauf zugeschnitten Beschreibungen von Sicherheitslücken zu verwalten. Lassen Sie uns nun einen realistischen VuXML-Eintrag betrachten: [.programlisting] .... <.> Several vulnerabilities found in Foo <.> foo <.> foo-devel ja-foo 1.61.9 <.> 2.*2.4_1 3.0b1 openfoo <.> 1.10_7 <.> 1.2,11.3_1,1

J. Random Hacker reports:

<.>

Several issues in the Foo software may be exploited via carefully crafted QUUX requests. These requests will permit the injection of Bar code, mumble theft, and the readability of the Foo administrator account.

 <.> SA-10:75.foo <.> ports/987654 <.> CAN-2010-0201 <.> CAN-2010-0466 96298 <.> CA-2010-99 <.> 740169 <.> SA10-99A <.> SA10-99A <.> http://marc.theaimsgroup.com/?l=bugtraq&m=203886607825605 <.> http://j.r.hacker.com/advisories/1 <.> 2010-05-25 <.> 2010-07-13 <.> 2010-09-17 <.> .... Die Namen der Tags sollten selbsterklärend sein - also werfen wir einen genaueren Blick auf die Felder, die Sie selbst ausfüllen müssen: <.> Dies ist die höchste Tag-Ebene eines VuXML-Eintrags. Es ist ein vorgeschriebenes Attribut `vid`, welches eine allgemein einzigartige Kennung (universally unique identifier, UUID) in Anführungszeichen für diesen Eintrag festlegt. Sie sollten eine UUID für jeden neuen VuXML-Eintrag erzeugen (und vergessen Sie nicht die UUID der Vorlage zu ersetzen, es sei denn, Sie schreiben den Eintrag von Grund auf selbst). Sie können man:uuidgen[1] verwenden, um eine VuXML UUID zu erzeugen. <.> Dies ist eine einzeilige Beschreibung des gefundenen Fehlers. <.> Hier werden die Namen betroffener Pakete aufgeführt. Es können mehrere Namen angegeben werden, da mehrere Pakete von einem einzigen Master-Port oder Software-Produkt abhängen können. Das schließt Stable- und Developement-Zweige, lokalisierte Versionen und Slave-Ports ein, die verschiedene Auswahlmöglichkeiten wichtiger Kompilierungszeit-Optionen bieten. <.> Betroffene Versionen der Pakete werden hier als ein Bereich oder mehrere durch eine Kombination aus ````, ````, ````, ````, und ````-Elementen ausgegeben. Die angegebenen Bereiche sollten sich nicht überschneiden.In einer Bereichsangabe steht `\*` (Asterisk) für die kleinste Versionsnummer. Insbesondere ist `2.*` kleiner als `2.a`. Deshalb kann ein Stern benutzt werden, um auf alle möglichen ``Alpha``-, ``Beta``- und `RC`-Versionen zuzutreffen. Zum Beispiel passt `2.*3.* ` auf alle Versionen der Form `2.x`, während ` 2.03.0` das nicht erfüllt, da es nicht auf `2.r3` passt, auf `3.b` aber schon.Das obige Beispiel legt fest, dass Versionen von `1.6` bis `1.9` betroffen sind - außerdem Versionen `2.x` vor `2.4_1` und Version `3.0b1`. <.> Mehrere zusammenhängende Gruppen von Paketen (im wesentlichen Ports) können im Abschnitt `` aufgeführt werden. Das kann man benutzen, wenn sich Programme (sagen wir FooBar, FreeBar und OpenBar) denselben Quelltext als Grundlage haben und sich noch dessen Fehler und Sicherheitslücken teilen. Beachten Sie den Unterschied zum Anführen mehrerer Namen innerhalb eines Abschnittes. <.> Die Versionsbereiche sollten, wenn möglich, sowohl `PORTEPOCH` als auch `PORTREVISION` erlauben. Bitte denken Sie daran, dass gemäß der Vergleichsregeln eine Version mit einer `PORTEPOCH`, die nicht Null ist, größer ist als jede Version ohne `PORTEPOCH`. Das heißt, `3.0,1` ist größer als `3.1` oder sogar `8.9`. <.> Das ist die Zusammenfassung des Problems. In diesem Feld wird XHTML verwendet. Zumindest umschließende `

` und `

` sollten auftauchen. Komplexere Tags sind zwar möglich, aber sollten nur um der Genauigkeit und Klarheit willen verwendet werden: Bitte verwenden Sie hier kein Eye-Candy. <.> Dieser Abschnitt enthält Verweise auf relevante Dokumente. Es wird empfohlen so viele Referenzen wie nötig aufzuführen. <.> Das ist ein http://www.freebsd.org/security/#adv[FreeBSD Sicherheitshinweis]. <.> Das ist ein http://www.freebsd.org/support/#gnats[ FreeBSD Problembericht]. <.> Das ist eine http://www.cve.mitre.org/[Mitre CVE] Kennung. <.> Das ist eine http://www.securityfocus.com/bid[SecurityFocus Fehler-Kennung]. <.> Das ist ein Sicherheitshinweis von http://www.cert.org/[US-CERT]. <.> Das ist eine Mitteilung über eine Schwachstelle von http://www.cert.org/[US-CERT]. <.> Das ist ein Cyber-Sicherheitsalarm von http://www.cert.org/[US-CERT]. <.> Das ist ein technischer Cyber-Sicherheitsalarm von http://www.cert.org/[US-CERT]. <.> Das ist eine URL zu einem archivierten Posting auf einer Mailingliste. Das Attribut `msgid` ist optional und gibt die Nachrichtenkennung des Postings an. <.> Das ist eine gewöhnliche URL. Sie sollte nur verwendet werden, wenn keine der anderen Referenzkategorien verfügbar ist. <.> Das ist das Datum, an dem die Sicherheitslücke bekannt wurde (_JJJJ-MM-TT_). <.> Das ist das Datum, an dem der Eintrag hinzugefügt wurde (_JJJJ-MM-TT_). <.> Das ist das Datum, an dem zuletzt irgendeine Information des Eintrags verändert wurde (_JJJJ-MM-TT_). Neue Einträge dürfen dieses Feld nicht enthalten. Es sollte beim Editieren eines existierenden Eintrags eingefügt werden. [[security-notify-vuxml-testing]] === Ihre Änderungen an der VuXML-Datenbank testen Nehmen wir an, Sie haben gerade einen Eintrag für eine Sicherheitslücke in dem Paket `clamav` geschrieben oder ausgefüllt, die in der Version `0.65_7` korrigiert wurde. Als Voraussetzung müssen Sie die aktuellen Versionen der Ports package:ports-mgmt/portaudit[], package:ports-mgmt/portaudit-db[] sowie package:security/vuxml[]_installieren_. [NOTE] ==== Um `packaudit` auszuführen, müssen Sie die Berechtigung haben [.filename]#DATABASEDIR# zu schreiben - üblicherweise ist das [.filename]#/var/db/portaudit#. Durch Setzen der Umgebungsvariable [.filename]#DATABASEDIR# können Sie hier auch ein anderes Verzeichnis angeben. Arbeiten Sie nicht aus dem Verzeichnis [.filename]#${PORTSDIR}/security/vuxml# heraus, müssen Sie zusätzlich die Umgebungsvariable [.filename]#VUXMLDIR# setzen, um anzugeben, in welchem Verzeichnis sich die Datei [.filename]#vuln.xml# befindet. ==== Zuerst überprüfen Sie bitte, ob bereits ein Eintrag für diese Schwachstelle existiert. Wenn es einen solchen Eintrag gibt, sollte er auf die vorige Version `0.65_6` zutreffen: [source,shell] .... % packaudit % portaudit clamav-0.65_6 .... Wenn keine vorhandenen Einträge gefunden werden haben Sie grünes Licht, einen neuen Eintrag für diese Sicherheitslücke anzulegen. Sie können nun eine neue UUID erzeugen (wir nehmen an, diese lautet `74a9541d-5d6c-11d8-80e3-0020ed76ef5a`) und einen neuen Eintrag in der VuXML-Datenbank anlegen. Bitte überprüfen Sie danach die Syntax mit folgendem Befehl: [source,shell] .... % cd ${PORTSDIR}/security/vuxml && make validate .... [NOTE] ==== Sie werden zumindest eines der folgenden Pakete benötigen: package:textproc/libxml2[], package:textproc/jade[]. ==== Jetzt bauen Sie bitte die `portaudit`-Datenbank aus der VuXML-Datei neu: [source,shell] .... % packaudit .... Um sicherzustellen, dass der Abschnitt `` Ihres Eintrags die richtigen Pakete betrifft, verwenden Sie bitte den folgenden Befehl: [source,shell] .... % portaudit -f /usr/ports/INDEX -r 74a9541d-5d6c-11d8-80e3-0020ed76ef5a .... [NOTE] ==== Bitte lesen Sie in man:portaudit[1] nach, um ein besseres Verständnis der Befehlssyntax zu entwickeln. ==== Bitte stellen Sie sicher, dass Ihr Eintrag keine falschen Treffer in der Ausgabe erzeugt. Jetzt überprüfen Sie bitte, dass Ihr Eintrag die richtigen Versionen des Pakets angibt: [source,shell] .... % portaudit clamav-0.65_6 clamav-0.65_7 Affected package: clamav-0.65_6 (matched by clamav<0.65_7) Type of problem: clamav remote denial-of-service. Reference: 1 problem(s) found. .... Offensichtlich sollte die erste Version ausgegeben werden - die zweite jedoch nicht. Abschließend überprüfen Sie bitte, ob die Webseite, die aus der VuXML-Datenbank erzeugt wird, wie erwartet aussieht: [source,shell] .... % mkdir -p ~/public_html/portaudit % packaudit % lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html ....