Dies ist die Liste der Errata und Korrekturroutinen für das OpenBSD-Release 3.6:

Die Korrekturroutinen weiter unten sind mit CVS im OPENBSD_3_6-patch-branch erhältlich.

Detailliertere Informationen darüber, wie man Korrekturroutinen 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 dieser Korrektur ein anderer Pufferüberlauf behoben wird als mit der vorherigen Korrektur für zlib.
  Es existiert eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die das Problem behebt.
  

• 015: RELIABILITY FIX: 4. April 2005   alle Architekturen
  Handhabe eine Randbedingung in tcp(4)-,timestamps'.
  Es existiert eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die 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 eine Korrekturroutine, die das Problem behebt.