Warum schließt OpenBSD einige Sicherheitslücken nicht?

Securelevels sind wirklich Quatsch. Die gehören meiner Meinung nach abgeschafft. Was den Randomizer angeht. Keine ahnung wie stark der geschwächt ist, aber ich bezweifele, dass das eine Echtzeitschwachstelle ist
 
Ich versteh nicht wo das Problem ist dieses kleinen Problemchen zu fixen
zumal OpenBSD sehr auf Sicherheit ausgelegt "sein soll"

Wenn ich schon ein sicheres System benutzen möchte, dann möchte ich auch schon das bekannte sicherheitsrelevante Dinge behoben wurden sind
gerade bei einem OS das Sicherheit in den Vordergrund stellt

Sonst bekommt man das Gefühl ein unsicheres System zu benutzen

Meiner Auffassung nach ist FreeBSD, NetBSD, DragonFlyBSD zur Zeit sicherer als OpenBSD
 
FreeBSDuser schrieb:
Geh doch hin und fix dir den Kram...
Zum Vergrößern anklicken....
Ich kann die tragweite der Lücken (sofern es welche sind) nicht einschätzen, finde die Anfrage jedoch berechtigt.

http://cvs.openbsd.org/de/security.html schrieb:
Um sicherzustellen, dass neue Benutzer von OpenBSD nicht über Nacht Sicherheitsexperten werden müssen (ein Standpunkt, den andere Systeme anscheinend haben), liefern wir unser Betriebssystem standardmäßig sicher aus.
Zum Vergrößern anklicken....
 
Ararat++ schrieb:
Hallo,

Warum schließt OpenBSD einige Sicherheitslücken nicht?

Mittlerweile hat OpenBSD hat OBSD schon 2 Sicherheitslücken, vllt nur um den tollen Spruch nicht zu gefährden oder was weiß ich

1. http://www.securityfocus.com/columnists/380
2. http://www.heise.de/security/Zu-wen...engenerator-von-OpenBSD--/news/meldung/103278

Solange scheue ich mich OpenBSD produktiv einzusetzen, da fühle ich mich bei den anderen BSDs sicherer
Zum Vergrößern anklicken....

"FreeBSD is still discussing the issue and no further response from the Linux maintainer has been received yet."

Solange FreeBSD nicht inzwiischen was getan hat fühlst Du Dich wohl nur bei NetBSD sicher. :D

Aber mal zum Artikel: Ich finde dass er recht hat, dass man es Dokumentieren sollte. Und vielleicht noch wie in NetBSD das Einbinden in Securlevel 2 zu unterbinden. Aber das rausschmeißen könnte den ein oder anderen ärgern, da es vielleicht von einigen auch mit dem Wissen dass es nicht "sicher" ist genutzt wird.


Und zu Thema PRNG:
Ich glaube dass jeder der auf eine gute Zufallsquelle angewiesen ist einen Hardware RNG nutzen sollte. Es wäre sicher nicht schlecht den PRNG von OpenBSD noch zu verfeinern, aber auf Dauer wird das auch keine Lösung sein. PRNG ist und bleibt "Pseudo". Aber haben die anderen BSDs oder Apple hier eigenltich gehandelt?
 
CMW schrieb:
Aber haben die anderen BSDs oder Apple hier eigenltich gehandelt?
Zum Vergrößern anklicken....
Ja, die sind vorbildlich im Gegensatz zu OpenBSD ;)
heise.de schrieb:
Die Entwickler von FreeBSD (4.4 bis 7.0 verwundbar), NetBSD (1.6.2 bis 4.0) und DragonFlyBSD (1.0 bis 1.10.1) haben bereits Patches in die jeweiligen Versionskontrollsysteme eingepflegt, die betroffene Administratoren in ihr System einspielen sollten.
Zum Vergrößern anklicken....
 
Das Vorgehen vom OpenBSD-Team finde ich schon befremdlich

Moin,

ich muss Ararat++ zustimmen. Ob die Securelevel nun sinnvoll sind oder nicht, ist eine andere Diskussion. Aber wenn eine Sicherheitslücke vorhanden ist, dann sollte sie gestopft werden. Genau so beim PRNG, bei BIND9 hat das Team noch einen Eigenen integriert, nun ist der vom System betroffen und die Jungs haben scheinbar kein Interesse am Fixen. Das ist schon eine etwas eigenartige Sicht auf Sicherheitslücken und läßt mich zweifeln, ob ich weiter OpenBSD einsetzen sollte.

Wie in anderen Threads geschrieben, haben wir zwei OpenBSD-FWs bei denen eigentlich ein Update ansteht. Ich bin stark um Überlegen, mir dieses und zuküntige Updates zu sparen, und stattdessen beide nacheinander auf FreeBSD umzustellen.

Gruß c.
 
Ararat++ schrieb:
Hallo,

Warum schließt OpenBSD einige Sicherheitslücken nicht?

Mittlerweile hat OpenBSD hat OBSD schon 2 Sicherheitslücken, vllt nur um den tollen Spruch nicht zu gefährden oder was weiß ich

1. http://www.securityfocus.com/columnists/380
2. http://www.heise.de/security/Zu-wen...engenerator-von-OpenBSD--/news/meldung/103278

Solange scheue ich mich OpenBSD produktiv einzusetzen, da fühle ich mich bei den anderen BSDs sicherer
Zum Vergrößern anklicken....

HI,

Zum Thema: Beitrag von Redteam-Pentesting :

Ich hab mir mal die Seite und den Adv. von denen Durchgelesen.
Dort nutzen sie einen NFS Mount aus, um den Securelevel 1 mit chgflags auszunutzen.

Dazu muss man aber auch sagen das, wer id 0 hat, hat ID 0 und die Macht.
Ich finde diese Geschichte etwas beschränkt.

Securelevels haben ihre Berechtigung.
Wer sein Netzwerk so offen hat, das ein Attacker NFS mounten kann von wo auch immer, naja, da hilft auch kein Securelevel > 2.

Und zum Thema PRNG, Die Opbsdler sind die einzigen (hab ich das gefühl) die sich den Quellcode auch mal anschauen, und anpassen.
Denn der Exploite für den BIND 9 funktioniert nur bis zu einem Cache-Poising (Ich meine das reicht ja auch schon), aber unter den anderen Systemen kann Code eingeschleusst werden. Was noch viel Schlimmer ist.
 
Paldium schrieb:
Wie ich schon schrieb, wurde der Generator in OpenBSD 4.3 ausgetauscht. Aber was hilft hier noch schreiben, denn



bei so einer Aussage ist wohl wirklich jedes weitere Wort zu viel ... :huth:
Zum Vergrößern anklicken....

Moin Paldium,

ich könnte Dir zustimmen, wenn die aktuelle Release nicht 4.2 wäre (jetzt am 22.04.2008, ca. 13:00 Uhr). Ich erwarte nicht, das steinalte Versionen noch gepflegt werden, aber die gerade aktuelle kann man schon erwarten. Andere BSDs können und machen das auch.

Denke über meine Meinung wie Du willst, so wie ich das auch über Deine tue. Aber es ist schon eine eigenwillige Ansicht, die das OpenBSD-Team hat. Es wird immer die hohe Sicherheit und Stabilität genannt, aber o.g. Lücke wird aus Desinteresse nicht gefixt, bei der anderen wird hintenrum erwartet, auf eine noch nicht releaste Version zu gehen.
Ich habe kein Problem damit, das Fehler in OpenBSD auftauchen, keiner ist unfehlbar, aber wie mit Fehlern umgegangen wird gefällt mir nicht. Da OpenBSD mit markigen Wörtern rumwirft nenne ich auch mal eins: man nennt das auch Fehlerkultur.

Und: Entschuldigung, das ich Kritik am großen und unfehlbaren Meister geübt habe.
Bei Heise würde ich jetzt schreiben: Jetzt mach(t) mich rot.

Gruß c.
 
Halten wir einmal fest, dass alle BSDs so ihre Schwächen haben. FreeBSD ist auch mal monatelang mit einer nicht gefixten local privilege escalation rumgerannt ("we'll fix it when we've got the time...") - das ist aber im Prinzip das Risiko bei jeder community-getriebenen Software. Und aus diesem einen Vorfall zu schließen, ein BSD sei sicherer als das andere, ist mit Verlaub ziemlicher Blödsinn.

Wirklich gut in puncto Sicherheit kann ein OS wohl nur werden, wenn das Security Response Team groß genug ist, fällige Patches für den gesamten Source Tree selbst zu entwickeln und zu committen und nicht immer auf den jeweiligen Maintainer angewiesen zu sein. Ergo: Mehr spenden, oder selbst zu den jeweiligen Projekten beitragen.

Ein Nachsatz noch zu OpenBSD: Auch systrace ist auf MP-Systemen anfällig gegen Race Conditions. Bekannt ist diese Tatsache schon lange, aber gefixt wurde das IMHO (noch) nicht. Von daher - OpenBSD hat schon etwas nachgelassen bzw. stößt jetzt auf dieselben Probleme wie andere Betriebssysteme, die bestimmte Features schon früher implementiert haben.
 
named (bind) ist standardmäßig nicht aktiviert

Sollte also im Server eine echte Sicherheitslücke bestehen, würde das nichts dran ändern, dass OpenBSD 2 Sicherheitslücken in der Standardinstallation hat. Das ist übrigens auch damit gemeint, dass neue Anwender nicht über Nacht zu Sicherheitsexperten werden müssen.

Wenn sie aber einen Dienst aktivieren, dann haben sie sich auch über ihn zu informieren - haben als Grundlage aber erstmal ein System, das ihnen nicht gleich zerschossen wird.

Und mein Vermerk, dass OpenBSD 4.3 einen anderen Generator hat, sollte bei dem einen oder anderen mal den Gedanken aufkommen lassen, dass diese Korrektur wirklich so unwichtig ist, dass sie nicht in -stable aufgenommen werden muss - und nicht bedeutet, dass keine Korrektur vorhanden ist oder man sie nicht aufnehmen will.

Der PRNG (von bind/OpenBSD) ist nicht zufällig, daher eine Sicherheitslücke

Wer sich das Researchpaper mal durchgelesen hat, sollte schnell erkannt haben, welche Vorausetzungen geschaffen sein müssen, damit das zum Problem wird: Der eigene DNS-Server hat nur wenig zu tun und der Angreifer verfügt über einen (oder mehrere) schnelle Systeme. Sicherheitslücke, ja. Heutzutage kann man davon ausgehen, dass es viele schnelle Systeme gibt (im Paper wird von einem Quad-Core gesprochen, der 90 Sekunden benötigt hat. Sehr viel mehr Zeit hat man auch nicht, weil der PRNG sich dann neu initialisiert).

Aber das funktioniert auch nur, wenn der DNS-Server sowohl Anfragen als auch Rekursionen gleichzeitig verarbeitet. Es gibt /usr/src/etc/bind/named-dual.conf, dort sind beide Funktionen getrennt. Dann kann mir auch der PRNG egal sein. Es ist also wieder eine Frage der Konfiguration.

Wer sich also einen BIND-Server aufsetzen will, sollte sich einlesen. RTFM. Nun gut, vielleicht nicht nur das Manual, Researchpaper sind auch nicht zu verachten. ;)

Securelevels wurden nicht behoben

Die Securelevel schützen nicht vor Root. Sicherheitslücke. Standardmäßig ein Dienst aktiv, mit dem man das hinbekommt? Nein. Wird eine unsichere Konfiguration (Root-Zugriff per NFS) benötigt? Ja.

systrace ist nicht sicher

Wer systrace(1) mal liest und ganz nach unten scrollt, weiß auch in welchen Situationen. Das macht aber nicht das gesamte Programm unnütz.



Alle Klarheiten beseitigt? ;)
 
Ogion schrieb:
Halten wir einmal fest, dass alle BSDs so ihre Schwächen haben. FreeBSD ist auch mal monatelang mit einer nicht gefixten local privilege escalation rumgerannt ("we'll fix it when we've got the time...") - das ist aber im Prinzip das Risiko bei jeder community-getriebenen Software. Und aus diesem einen Vorfall zu schließen, ein BSD sei sicherer als das andere, ist mit Verlaub ziemlicher Blödsinn.
Zum Vergrößern anklicken....
Das sehe ich genauso. Ich will nochmal klarstellen, das ich OpenBSD nicht ankreide, das es Fehler enthalten hat o. noch enthält, oder das ich FreeBSD als sicherer betrachte.
Das kann ich auch nicht beurteilen, da fehlt mir das Wissen für. Mir geht es um die Art und Weise wie mit Fehlern umgegangen wird. Eine 'Fehlerbehandlung' wie durch das FreeBSD-Team mit dem Verweis auf 'keine Ressourcen z.Zt.' ist mir lieber, als ein Satz wie 'Sorry, we are going to change nothing. Securelevels are useless.'

Gruß c.
 
Paldium schrieb:
systrace ist nicht sicher

Wer systrace(1) mal liest und ganz nach unten scrollt, weiß auch in welchen Situationen. Das macht aber nicht das gesamte Programm unnütz.
Zum Vergrößern anklicken....

Sagt ja auch keiner ;). Ich wollte bloß darauf hinweisen, dass es den OpenBSD-Entwicklern mit der wachsenden Code-Basis (bis vor nicht allzu langer Zeit gab es eben keinen SMP-Code im Kernel) immer schwerer fällt, ihre eigene Messlatte in puncto Code-Qualität und Sicherheitsanspruch noch zu meistern. Andererseits kann ich auch den Druck verstehen, denn was nützt einem ein qualitativ hochwertiges OS, das auf keiner aktuellen Hardware mehr läuft? Ich weiß, jetzt wird's philosophisch... Nichts desto trotz ist die Code-und Doku-Qualität (manpages) bei OpenBSD nach wie vor extrem hoch.

crotchmaster schrieb:
Eine 'Fehlerbehandlung' wie durch das FreeBSD-Team mit dem Verweis auf 'keine Ressourcen z.Zt.' ist mir lieber, als ein Satz wie 'Sorry, we are going to change nothing. Securelevels are useless.'
Zum Vergrößern anklicken....
Halten wir des weiteren fest, dass OpenBSD noch nie eine gute "PR-Abteilung" besessen hat :) Immerhin wurden die Lücken nicht dementiert; auch das ist in der Vergangenheit schon bei einigen Open Source Projekten vorgekommen...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben