Kapitel 11. Sicherheit der Ports

This translation may be out of date. To help with the translations please access the FreeBSD translations instance.

11.1. 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.

11.2. 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 den Port als FORBIDDEN markieren 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 die Standardvorgehensweise zum Einreichen von Änderungen beachtet werden - es sei denn, Sie haben das Recht diese direkt in den Ports-Baum zu committen.

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 betreffenden Abschnitt für weitere Informationen.

11.3. Die Community informiert halten

11.3.1. 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 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 FreeBSD Sicherheitsinformationen beschrieben wird.

Wie vielleicht aus dem Titel hervorgeht, handelt es sich bei der VuXMl-Datenbank um ein XML-Dokument. Die Quelldatei vuln.xml können Sie im Port security/vuxml finden. Deshalb wird der komplette Pfadname 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.

11.3.2. 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 <Tag> muss ein passendes </Tag> 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 (eXtensible) - 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:

<vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> (1)
  <topic>Several vulnerabilities found in Foo</topic> (2)
  <affects>
    <package>
      <name>foo</name> (3)
      <name>foo-devel</name>
      <name>ja-foo</name>
      <range><ge>1.6</ge><lt>1.9</lt></range> (4)
      <range><ge>2.*</ge><lt>2.4_1</lt></range>
      <range><eq>3.0b1</eq></range>
    </package>
    <package>
      <name>openfoo</name> (5)
      <range><lt>1.10_7</lt></range> (6)
      <range><ge>1.2,1</ge><lt>1.3_1,1</lt></range>
    </package>
  </affects>
  <description>
    <body xmlns="http://www.w3.org/1999/xhtml">
      <p>J. Random Hacker reports:</p> (7)
      <blockquote
        cite="http://j.r.hacker.com/advisories/1">
        <p>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.</p>
      </blockquote>
    </body>
  </description>
  <references> (8)
    <freebsdsa>SA-10:75.foo</freebsdsa> (9)
    <freebsdpr>ports/987654</freebsdpr> (10)
    <cvename>CAN-2010-0201</cvename> (11)
    <cvename>CAN-2010-0466</cvename>
    <bid>96298</bid> (12)
    <certsa>CA-2010-99</certsa> (13)
    <certvu>740169</certvu> (14)
    <uscertsa>SA10-99A</uscertsa> (15)
    <uscertta>SA10-99A</uscertta> (16)
    <mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> (17)
    <url>http://j.r.hacker.com/advisories/1</url> (18)
  </references>
  <dates>
    <discovery>2010-05-25</discovery> (19)
    <entry>2010-07-13</entry> (20)
    <modified>2010-09-17</modified> (21)
  </dates>
</vuln>

Die Namen der Tags sollten selbsterklärend sein - also werfen wir einen genaueren Blick auf die Felder, die Sie selbst ausfüllen müssen:

1	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 uuidgen(1) verwenden, um eine VuXML UUID zu erzeugen.
2	Dies ist eine einzeilige Beschreibung des gefundenen Fehlers.
3	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.
4	Betroffene Versionen der Pakete werden hier als ein Bereich oder mehrere durch eine Kombination aus `<lt>`, `<le>`, `<eq>`, `<ge>`, und `<gt>`-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 `<ge>2.</ge><lt>3. </lt>` auf alle Versionen der Form `2.x`, während `<ge> 2.0</ge><lt>3.0</lt>` 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`.
5	Mehrere zusammenhängende Gruppen von Paketen (im wesentlichen Ports) können im Abschnitt `<affected>` 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 <package> Abschnittes.
6	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`.
7	Das ist die Zusammenfassung des Problems. In diesem Feld wird XHTML verwendet. Zumindest umschließende `<p>` und `</p>` 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.
8	Dieser Abschnitt enthält Verweise auf relevante Dokumente. Es wird empfohlen so viele Referenzen wie nötig aufzuführen.
9	Das ist ein FreeBSD Sicherheitshinweis.
10	Das ist ein FreeBSD Problembericht.
11	Das ist eine Mitre CVE Kennung.
12	Das ist eine SecurityFocus Fehler-Kennung.
13	Das ist ein Sicherheitshinweis von US-CERT.
14	Das ist eine Mitteilung über eine Schwachstelle von US-CERT.
15	Das ist ein Cyber-Sicherheitsalarm von US-CERT.
16	Das ist ein technischer Cyber-Sicherheitsalarm von US-CERT.
17	Das ist eine URL zu einem archivierten Posting auf einer Mailingliste. Das Attribut `msgid` ist optional und gibt die Nachrichtenkennung des Postings an.
18	Das ist eine gewöhnliche URL. Sie sollte nur verwendet werden, wenn keine der anderen Referenzkategorien verfügbar ist.
19	Das ist das Datum, an dem die Sicherheitslücke bekannt wurde (JJJJ-MM-TT).
20	Das ist das Datum, an dem der Eintrag hinzugefügt wurde (JJJJ-MM-TT).
21	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.

11.3.3. 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 ports-mgmt/portaudit, ports-mgmt/portaudit-db sowie security/vuxmlinstallieren.

Um packaudit auszuführen, müssen Sie die Berechtigung haben DATABASEDIR zu schreiben - üblicherweise ist das /var/db/portaudit.

Durch Setzen der Umgebungsvariable DATABASEDIR können Sie hier auch ein anderes Verzeichnis angeben.

Arbeiten Sie nicht aus dem Verzeichnis ${PORTSDIR}/security/vuxml heraus, müssen Sie zusätzlich die Umgebungsvariable VUXMLDIR setzen, um anzugeben, in welchem Verzeichnis sich die Datei 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:

% 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:

% cd ${PORTSDIR}/security/vuxml && make validate

Sie werden zumindest eines der folgenden Pakete benötigen: textproc/libxml2, textproc/jade.

Jetzt bauen Sie bitte die portaudit-Datenbank aus der VuXML-Datei neu:

% packaudit

Um sicherzustellen, dass der Abschnitt <affected> Ihres Eintrags die richtigen Pakete betrifft, verwenden Sie bitte den folgenden Befehl:

% portaudit -f /usr/ports/INDEX -r 74a9541d-5d6c-11d8-80e3-0020ed76ef5a

Bitte lesen Sie in 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:

% 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: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html>

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:

% mkdir -p ~/public_html/portaudit
% packaudit
% lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html

Last modified on: 9. März 2024 by Danilo G. Baio

Home