Dies ist die Errata- u. Patchliste für das OpenBSD-Release 3.6:

Die Patches weiter unten sind mit CVS im OPENBSD_3_6-Patchbranch erhältlich.

Detailliertere Informationen darüber, wie man Patches installiert, findest du in der OpenBSD-FAQ.

• 020: SECURITY FIX: 21. Juli 2005   alle Architekturen
  Ein Pufferüberlauf wurde in compress(3) gefunden, der ausgenutzt werden könnte.
  Beachte bitte, dass mit diesem Patch ein anderer Pufferüberlauf behoben wird als mit dem vorherigen zlib-Patch.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 019: SECURITY FIX: 6. Juli 2005   alle Architekturen
  Ein Pufferüberlauf wurde in compress(3) gefunden, der ausgenutzt werden könnte.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 018: SECURITY FIX: 20. Juni 2005   alle Architekturen
  Wegen einer Wettlaufsituation in der Verarbeitung der Kommando-Pfadnamen kann ein Benutzer mit sudo(8)-Privilegien beliebige Programme ausführen, wenn auf den Eintrag des Benutzers ein Eintrag folgt, der sudo ALL-Privilegien für einen weiteren Benutzer vergibt.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 017: RELIABILITY FIX: 15. Juni 2005   alle Architekturen
  Wie von Stefan Miltchev entdeckt, kann das Aufrufen von getsockopt(2), um ipsec(4)-,credentials' für ein Socket zu erhalten, in einem ,kernel panic' enden.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 016: SECURITY FIX: 28. April 2005   alle Architekturen
  Behebt einen Pufferüberlauf, ,memory leaks' und ,NULL pointer dereference' in cvs(1) . Von keinem dieser Probleme ist bekannt, dass sie ausgenutzt werden könnten. CAN-2005-0753 .
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 015: RELIABILITY FIX: 4. April 2005   alle Architekturen
  Handhabe eine Randbedingung in tcp(4)-,timestamps'.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 014: SECURITY FIX: 30. März 2005   alle Architekturen
  Wegen einem Pufferüberlauf in telnet(1) kann ein bösartiger Server oder ein ,man-in-the-middle'-Angriff beliebigen Code mit den Privilegien des Benutzers ausführen, der telnet(1) aufgerufen hat. Niemand sollte mehr telnet einsetzen. Bitte verwende ssh(1).
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 013: RELIABILITY FIX: 30. März 2005   alle Architekturen
  Fehler im tcp(4)-,stack' können zum völligen Verbrauch des Speichers oder zum Verarbeiten von TCP-Segmenten mit ungültigen SACK-Optionen führen und somit einen Systemabsturz verursachen.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 012: SECURITY FIX: 16. März 2005   nur amd64
  Genauere Überprüfung sollte in den copy(9)-Funktionen durchgeführt werden, um deren Missbrauch zu verhindern.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 011: SECURITY FIX: 28. Februar 2005   nur i386
  Genauere Überprüfung sollte in den copy(9)-Funktionen durchgeführt werden, um deren Missbrauch zu verhindern.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 010: RELIABILITY FIX: 11. Januar 2005   alle Architekturen
  Ein Fehler im tcp(4)-,stack' erlaubt es, dass ein ungültiges Argument in der Berechnung des TCP-,retransmit'-Timeouts verwendet werden kann. Durch das Senden von Paketen mit bestimmten Werten in der TCP-Timestamp-Option kann ein Angreifer ein ,system panic' auslösen.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 009: SECURITY FIX: 12. Januar 2005   alle Architekturen
  httpd(8)s mod_include-Modul kann die Länge des vom Benutzer angegebenen Tag-Strings nicht richtig validieren, bevor sie in einen lokalen Puffer gespeichert werden, was zu einem Bufferoverflow führt.
  Dies würde das aktivieren der XBitHack-Direktive oder das serverseitige einfügen und verwenden eines böswilligen Dokumentes voraussetzen.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 008: RELIABILITY FIX: 6. Januar 2005   alle Architekturen
  Die getcwd(3)-Bibliotheksfunktion beinhaltet einen Speicherverwaltungsfehler, welcher Fehler in der Abfrage des aktuellen Arbeitsverzeichnisses verursacht, wenn der Pfad sehr lang ist.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 007: SECURITY FIX: 14. Dezember 2004   alle Architekturen
  Auf Systemen, auf denen isakmpd(8) läuft, ist es für einen lokalen Anwender möglich, eine Kernelspeicherverletzung und einen Systemfehler zu verursachen, indem ipsec(4)-Optionen auf einem Socket gesetzt werden.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 006: RELIABILITY FIX: 21. November 2004   alle Architekturen
  Korrektur für übertragungsseitiges Abbrechen auf macppc und mbuf Lücken mit xl(4).
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 005: RELIABILITY FIX: 21. November 2004   alle Architekturen
  Falsche Berechnung des NAT-D-,payloads' kann zu Problemen in der Zusammenarbeit zwischen isakmpd(8) und anderen ISAKMP/IKE-Implementationen führen.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 004: RELIABILITY FIX: 10. November 2004   alle Architekturen
  Wegen einem Fehler in lynx(1) ist es für Seiten wie dieser möglich dafür zu sorgen, dass lynx(1) den Speicher verbraucht und dann abstürzt, wenn solche Seiten verarbeitet werden.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 003: RELIABILITY FIX: 10. November 2004   alle Architekturen
  pppd(8) beinhaltet einen Fehler, der es einem Angreifer ermöglicht, seine eigene Verbindung abstürzen zu lassen, aber der Fehler kann nicht ausgenutzt werden, um die Dienste, die anderen Benutzern zur Verfügung gestellt werden, zu unterbinden.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 002: RELIABILITY FIX: 10. November 2004   alle Architekturen
  BIND beinhaltet einen Fehler, der darin enden kann, dass BIND versucht, Nameserver über IPv6 zu erreichen, selbst wenn die IPv6 Verbindung nicht existiert. Dies resultiert in unnötigen Timeouts und daher langsamen DNS Anfragen.
  Es existiert ein Quellcodepatch, der das Problem behebt.
  

• 001: RELIABILITY FIX: 10. November 2004   alle Architekturen
  Korrigiert die Erkennung von Band-Blockgrößen während auf das Gerät zugegriffen wird. Korrigiert das Problem mit restore(8).
  Es existiert ein Quellcodepatch, der das Problem behebt.