Wie nun bekannt wurde gibt es unter FreeBSD 6.0 bis FreeBSD 6.4 und auch FreeBSD 7.2 einen 0-day-root-exploit welcher bis dato noch nicht behoben wurde. Auch ist eine offizielle Stellungnahme seites des FreeBSD Projects bis jetzt nicht bekannt.

Wie der Entdecker der Schwachstelle, Frasunek, mitteilte, hat er das FreeBSD Project bereits am 29. August 2009 darüber in Kenntnis gesetzt. Robert Watson, einer der FreeBSD Core Team member, teilte mit, dass die E-Mail "lost in a slew" ist und er davon ausgeht, dass es in Kürze ein offizielles advisory geben wird.

Bei der Schwachstelle handelt es sich um einen lokalen zero-day-exploit. Das heisst, ein Anwender muss Zugriff auf das System haben um root-Rechte zu erlangen.

Laut The Register ist Version 7.1 und später nicht betroffen, allerdings zeigt dieses Video, dass auch FreeBSD 7.2 betroffen ist.

Laut dem Entdecker der Schwachstelle ist es sehr einfach die Schwachstelle auszunutzen, welche anscheinend mit kqueue zusammenhängt.

Videos:
FreeBSD 6.x Exploit
FreeBSD 7.2 Exploit

Weitere Informationen:
The Register

UPDATE:
Wie ich eben in der Mailingliste gelesen habe, ist das FreeBSD Security Team dabei einen Patch zu testen.

Xin Li schreibt dazu:

Currently we (secteam@) are testing the correction patch and do
peer-review on the security advisory draft, the bug was found and fixed
on -HEAD and 7-STABLE before 7.1-RELEASE during some stress test but was
not recognized as a security vulnerability at that time. The exploit
code has to be executed locally, i.e. either by an untrusted local user,
or be exploited in conjunction with some remote vulnerability on
applications that allow the attacker to inject their own code.

We can not release further details about the problem at this time,
though, but I think we will likely to publish the advisory and
correction patch this patch Wednesday.

Es wird also in Kürze mit einem Patch gerechnet.

Firewalls, bzw. Paketfilter sind in aller Munde. Zu letzt machte uns die neue Applikations-Firewall von Apple viel Freude. Wer ein reines Firewallsystem möchte, der war bisher mit m0n0wall oder pfSense immer gut beraten. Diese eigenen sich hervorragend um auf embedded hardware wie Soekris und Wrap ihren Dienst zu verrichten.

Nun wurde sich in dem Blog "The Cult of Linux" diese Firewalls einmal genauer angesehen. Dabei waren vor allem die folgenden Punkte wichtig:

Einfaches Setup, Installation, Konfiguration
Eine gute GUI (leicht zu bedienen, funktionell und ansprechend vom Design)
Erweiterbarkeit (add-ons, plugins)
Geschwindigkeit

Dabei wurden unterschieldliche Systeme auf den Prüfstand geschickt. Da man davon ausgehen kann das jede Firewall, bzw. Paketfilter, seinen Dienst anständig verrichtet, sind die oben genannten Punkte sicherlich verständlich und es muss nicht darauf eingegangen werden ob die Firewall ihren Dienst macht oder nicht (davon geht man aus - wenngleich Apple hier etwas überrascht hatte, aber dies steht hier auch nicht zur Diskussion).

Teilgenommen haben dabei folgende Produkte:

ClarkConnect
Endian
Gibraltar
IPCop
m0n0wall
pfSense
SmoothWall

Anhand der Produkte könnte man den Test auch "Linux FW vs. BSD FW" benennen, wenngleich dies sicherlich zu platt wäre. Der Gewinner ist dennoch ein BSD....aber dazu später mehr.

Allein schon die Grösse der einzelnen System ist überraschend. Wenn grösser gleich besser ist, dann müsste Gibraltar mit Abstand gewinnen, und das Schlusslicht wäre m0n0wall.

Um es kurz zu machen, hier das Ergebnis:



Den gesamten Test kann in diesem Blog nachgelesen werden und ich möchte die umfangreichen Zeilen hier nicht wiedergeben.

UPDATE (17.03.2008):
Der eigentlich Link zum Test ist tot.
Hier der neue Link: http://www.fsckin.com/2007/11/14/7-different-linuxbsd-firewalls-reviewed/

Unter MacOSX ist man nicht bei Windows und daher braucht man (noch) keinen Virenscanner und die Firewall, nun, ein nettes Schmuckstück IPFW von FreeBSD im System zu haben, mehr allerdings auch nicht. Denn, diese Firewall macht nicht wirklich das was sie machen sollte. Heise Security berichtete schon darüber.

Nun denn, wollen wir auch mal schnell mit nmap die Firewall testen.

1. MacOSX 10.5 Firewall - Zugriff auf bestimmte Dienste und Programme festlegen -> SSH

#ipfw list

65535 allow ip from any to any

#nmap -sU 10.10.11.230

Interesting ports on cojote.suedfac.com (10.10.11.230):

Not shown: 1484 closed ports

PORT     STATE         SERVICE

123/udp  open|filtered ntp

631/udp  open|filtered unknown

1900/udp open|filtered UPnP

5353/udp open|filtered zeroconf

#nmap -sT 10.10.11.230

Interesting ports on cojote.suedfac.com (10.10.11.230):

Not shown: 1695 closed ports

PORT     STATE SERVICE

22/tcp   open  ssh

9090/tcp open  zeus-admin

Sollte da nicht nur der Port 22 frei sein? Auch lässt sich der NTPD abfragen. MacOSX scheint dabei die Ports einfach freizuschalten die ein laufendes Programm nutzen möchte. Eine schöne Variante für Trojaner. Man fühlt sich sicher, und der Trojaner kann einfach die Firewall nach belieben öffnen...

2. MacOSX 10.5 Firewall - Alle eingehenden Verbindungen blockieren

#ipfw list

65535 allow ip from any to any

#nmap -sU 10.10.11.230

Interesting ports on cojote.suedfac.com (10.10.11.230):

Not shown: 1484 closed ports

PORT     STATE         SERVICE

123/udp  open|filtered ntp

631/udp  open|filtered unknown

1900/udp open|filtered UPnP

5353/udp open|filtered zeroconf

#nmap -sT 10.10.11.230

Interesting ports on cojote.suedfac.com (10.10.11.230):

Not shown: 1695 closed ports

PORT     STATE    SERVICE

22/tcp   filtered ssh

9090/tcp filtered zeus-admin

Ok, nun scheinen alle Verbindungen blockiert zu werden. Wirklich? NTPD lässt sich immer noch abfragen:

ntpdate[1864]: adjust time server 10.10.11.230 offset 0.249411 sec

3. MacOSX 10.5 Firewall - ipfw selbst gesetzt

#ipfw add 1 deny log tcp from any to any
#ipfw add 2 deny log udp from any to any
#ipfw list

00001 deny log tcp from any to any

00002 deny log udp from any to any

65535 allow ip from any to any

#nmap -sU 10.10.11.230

All 1488 scanned ports on cojote.suedfac.com (10.10.11.230) are open|filtered

#nmap -sT 10.10.11.230

All 1697 scanned ports on cojote.suedfac.com (10.10.11.230) are filtered

Ahh, ok, so will ich es haben. Nun geht auch der Zugriff auf den NTPD nicht mehr.

Die Frage ist nun, wo ist die Konfigurationsdatei von IPFW? Warum wird mir, egal was ich in der Firewall einstelle, immer nur eine Regel mit "ipfw list" angezeigt? Die Ausnahme ist wenn man in der MacOSX FW ICMP verbietet, dann wird eine weitere Regel hinzugefügt.

Kann es sein das IPFW von MacOSX irgendwie umgangen wird? Oder haben da die Entwickler einfach IPFW (fast) vergessen?

Wer also eine sichere FW unter MacOSX 10.5 will, der muss zum Terminal greifen und seine Regeln selbst schreiben. Mit einem entsprechenden Automator Script können diese bei jeder Anmeldung geladen werden, oder je nach Umgebung entladen und dafür andere geladen. Es hat also einen Vorteil, der gemeine Macuser muss sich auch mal mit der Firewall beschäftigen...

Bisher sollte dieses Blog frei von Politik bleiben, naja, es bleibt es auch weiterhin. Trotz der "totalen" Überwachung durch den Staat oder Firmen (man denke da an die ganzen Payback Karten und was es sonst noch so gibt um das Kaufverhalten auszulesen). Hierfür gibt es auf anderen Seiten, wie beispielsweise dem Daten-Chaos, mehr zu lesen. Und das ist auch gut so. Hier geht es vorrangig um *BSD, und dazu gehört sicherlich auch die Sicherheit, und wer kennt sich besser mit der Sicherheit aus als die Damen und Herren des CCC, wobei hier die politische Motivation sicher eine grosse Rolle spielt.

Beim diesjährigen Chaos Communcation Camp in der Nähe von Berlin, gibt es neben den politisch motivierten hacks, auch eine Reihe weiterer die sich meist auf Cross-Side-Scripting und dem auslesen der /etc/passwd beschränken.

So wurde bei Mastercard das Problem des Cross-Side-Scriptings festgestellt. Steht dort noch "SecureCode" auf der Seite, sieht man auf diesem Bild aber auch gleich, das es hier nicht sonderlich "secure" ist. Aber auch das US-Cert, welches 2003 gegründet wurde um die Internetstruktur in den USA zu wahren und zu sichern, bekommt sein fett weg, in diesem Fall ein SQL-Injection.

Die politschen Hacks beziehen sich auf rechte Seiten im Internet. Dabei wurden auch schon eine Seite gehackt, wie man auf diesem Bild sehen kann.

Zu guter letzt sind Hacker aber auch neben den eigentlichen Hacken kreativ. Dies vernaschaulicht das Video bei YouTube, "All your base belong to us".

Die Seite mit den Hacks gibt es hier zu sehen und sie wächst ständig.

Könnte man unter FreeBSD die Jails als "chroot auf Steroiden" bezeichnen (welche beim Dopingtest nicht aufgefallen wären), so sind die jails unter OpenBSD bei der A und B Probe durchgefallen. Die vermeintlich gewonnene Sicherheit ist leider keine. 

sysjail unter OpenBSD basiert auf systrace. Prinzpiell könnte sysjail daher auch jedem System aktiviert werden welches systrace unterstützt. Dies wären beispielsweise noch NetBSD und MirOS.

Bei systrace handelt es sich im weiteres Sicherheitsfeature welches weit über die Benutzerrechte oder Securelevel heinausgeht. Mit systrace ist es möglich Systamaufrufe von Programmen explizit zu kontrollieren und diese zuzulassen oder unter Umständen auch zu verbieten. Dies machen sich die sysjails unter OpenBSD auch zu eigen.

Nun hat Robert N. M. Watson aber herausgefunden, das diese Implemtierung Schwächen aufweist. Neben systrace werden dabei auch exploit Techniken gegen GSWTK und CerbNG aufgezeigt.

In seinem Workshop Paper auf der USENIX 07 kann dies nachgelesen werden. Bei der Präsentation geht er dabei noch auf die Exploits im speziellen ein.

Robert N.M. Watson sagt auch dazu:

The moral, for those unwilling to read the paper, is that system call
wrappers are a bad idea, unless of course, you’re willing to rewrite
the OS to be message-passing. Systems like the TrustedBSD MAC Framework on FreeBSD and Mac OS X Leopard, Linux Security Modules (LSM), Apple’s (and now also NetBSD’s) kauth(9),
and other tightly integrated kernel security frameworks offer specific
solutions to these concurrency problems. There’s plenty more to be done
in that area.

Paketfilter gibt es wie Sand am Meer. Umso problematischer wird es für den Einsteiger den richtigen Paketfilter zu finden und diesen entsprechend aufzusetzen. Besteht seit einiger Zeit ein gewisser "hype" was den Paketfilter PF betrifft, so wird IPFW, der Standard unter FreeBSD, fast vergessen. PF ist unter FreeBSD Current nun auch bei Version 4.1 angelangt, dennoch sollte IPFW nicht gänzlich aus dem Fundus des Wissens gestrichen werden.

Bei cyberciti gibt es einen kurzen Artikel über IPFW unter FreeBSD, der sich an Einsteiger richtet die einen Paketfilter unter FreeBSD nutzen möchten.

Neben IPFW und PF gibt es noch einen dritten Paketfilter unter FreeBSD, IPFilter. Allerdings dürften die meisten IPFW oder PF unter FreeBSD betreiben, oder was nutzt der Leser dieses Artikels an Paketfiltern? Die Umfrage ist eröffnet.

Immer wieder kam von Usern, gerade in der heutigen Zeit wo die totale Überwachung für viele schon begonnen hat, die Anregung, das Forum und alle weiteren subdomains auch via SSL Verschlüsselung zugänglich zu machen.

Ein selbstzertifiziertes Zertifikat würde dabei sicherlich ausreichen, eines wo ein autorisierter Aussteller das Zertifikat anbietet wäre allerdings besser. In den weiten des Internets gibt es zahlreiche Anbieter für Zertifikate, sei es Thawte, Trustecenter oder eine der vielen anderen, so haben alle eines gemeinsam, Zertifikate kosten Geld. Dabei sind nicht ein paar Euro gemeint, vielmehr wird der Interessierte dabei richtig zur Kasse gebeten. Und das für jede subdomain. Bei der Vielzahl die die bsdgroup aufzuweisen hat, ein finanzielles Fiasko. Bleibt also ein sogenannten wildcard Zertifikat. In diesem Falle also eines welches auf *.bsdgroup.de ausgestellt ist. Aber bei Preisen die in etwa bei 200 Euro pro Jahr anfangen, braucht man dabei nicht weiterzudenken.

Es hatten sich schon Spender gefunden, aber dieses Geld sollte lieber den BSD Projekten zur Verfügung gestellt werden als es für ein Zertifikat auszugeben.

Die bsdgroup.de ist zu letzt nun bei StartCom.org gelandet. Einen in Israel ansässigen Anbieter, der SSL Zertifikate kostenfrei anbietet. Bei den kostenfreien Zertifikaten handelt es sich um Free Class 1 Zertifikate. Problem dabei, man müsste für jede subdomain ein Zertifikat erstellen.

Um es kurz zu machen, die bsdgroup hat von StartCom SSL ein "Verified Class 2" Zertifikat gesponsert bekommen. Normalerweise würde dies 19.99 Dollar kosten, was ein Klacks gegenüber den Preisen anderer Anbieter ist.

Wie diese Verified Class 2 Zertifikate arbeiten kann im FAQ nachgelesen werden.

Um Certification Authority zu installieren:

Im übrigen entfällt bei Class 1 eine Authentifizierung des Antragstellers, dahingegen muss bei einem Class 2 Zertifikat eine Kopie des Reisepasses und des Personalausweises an Startcom gesendet werden. Danach wird man von diesen auf der angegeben Telefonnummer zurückgerufen. Erst danach wird das Zertifikat unterschrieben und ist Einsatzbereit.

Wir bedanken uns an dieser Stelle nochmals herzlich bei Startcom.org für das gespendete wildcard Zertifikat.

An dieser Stelle möchte ich mich, zumindest was die Freundlichkeit und Schnelligkeit angeht, nochmals persönlich bei den Jungs bedanken. Wenn wir uns mal treffen, gehen wir ein Bierchen trinken.

Bei Firewalls spalten sich die Meinungen, setzen die einen nur auf sogenannte Hardware-Firewalls, so ist anderen eine Software Firewall lieb und recht. Eine kleine Randerscheinung mit einem weitverbreiteten OS hat den Kampf schon aufgegeben und nutzt per default keine.

Sind aber Hardware-Firewalls ihren Preis wirklich wert, oder für was bezahlt man hier mehrere tausende von Euro. Und, kann eine Software-Firewall, wenn diese dazu auch noch Open Source ist, nicht das halten was eine Hardware-Firewall verspricht?

Nimmt die Meinungen gewichtiger Stimmen in einem Unternehmen, so fällt die Entscheidung leicht. Nur eine Hardware-Firewall kann, auch dank markiger Sprüch der Salesdroiden und entsprechender Werbung der Unternehmen, das eigene Unternehmen schützen. Kommen dann noch die Herren in grau, auch Revision genannt, ist man mit einer Hardware Firewall, so diese einen bekannten Namen trägt, fein raus und braucht keine weiteren Rückfragen zu fürchten, auch wenn sich keiner mit diesem Gerät wirklich auskennt. Problematisch wird es bei einer OpenSource Firewall eines Systems welches auch OpenSource ist und in den genannten Kreisen kaum bekannt ist. Automatisch ist eine solche Firewall schlechter als eine gekaufte (you get what you pay for?). Und, die Herren in grau riechen Lunte und wollen umgehend die Firewallregeln sehen und die Firewall testen. Ist dabei nichts problematisches zu finden, bleibt dennoch ein "minus" vermerkt und, anstatt sich zu belesen, kommt die Frage "Warum nutzen Sie nicht das Produkt der Firma XYZ?".

Der geneigte Leser, der wohl meist selbst eines der BSDs einsetzt, wird sicherlich eine der integrierten Firewalls nutzen. Vorrangig wird dies sicherlich IPFW und, darum geht es hier, PF sein.

Ist PF von OpenBSD nun schlechter als eine PIX von Cisco?

Mitnichten meine Damen und Herren Entscheider und die Herren in grau von der Revision. Mitnichten.

Man lese bitte diese Artikeln von Chris Swartz und Randy Rosel auf oreillynet.com oder reiche diesen an die Entscheider/ Revision weiter.

Denn, die Administratoren die OpenBSD und PF als Firewall einsetzen, wissen warum sie das machen. Es geht hier nicht in erster Linie um die Einsparungen von unnötigen Geldausgaben, vielmehr geht es darum überzeugt zu sein, das eine OpenSource Firewall wie PF mindestens genauso gut ist wie eine PIX, mit den Vorzügen von OpenSource.

Das nächste mal also, wenn es wieder darum geht eine Firewall für tausende von Euro anzuschaffen, sollte man darüber nachdenken und den Fragen der diese später einrichten und überwachen muss. Das eingesparte Geld kann man dann in andere Dinge investieren, einem der BSD Projekte spenden, oder seinem Admin eine Überraschung bereiten indem man seine Arbeit mit dem eingesparten Geld honoriert. Er freut sich darüber. Sicher.

Ach ja, wer den Artikel nicht lesen möchte. Das Resultat: PIX und OpenBSD PF nehmen sich nichts. Ok, die PIX bietet eine grafische Oberfläche und Auswertung, aber muss das für mehrere tausend Euro sein? Wer etwas sparen möchte und dennoch auf der sicheren Seiten des Lebens stehen will, sollte zu OpenBSD und PF greifen.

Seit gestern ist ein "sicherheitskritischer" Fehler unter OpenBSD bekannt. So soll es mit einem ICMP6-Paket möglich sein, ein System unter seine Kontrolle zu bringen oder mindestens einen Kernel-Panic auszulösen.

Betroffene Systeme sind:

OpenBSD 4.1 vor dem 26.02.2007
OpenBSD 4.0 Current
OpenBSD 4.0 Stable
OpenBSD 3.9
OpenBSD 3.8
OpenBSD 3.6
OpenBSD 3.1

Wird PF als Firewall eingesetzt, davon kann man bei der Nutzung von OpenBSD ausgehen, so soll ein

block in quick inet6 all

als Workaround dienen.

Bei Heise wird nun heute getitelt: "Bericht: OpenBSD-Entwickler wollen kritische Lücke kleinreden". Man könnte meinen das dort die Schadenfreude mitschwingt, das OpenBSD mit nur 2 Remote Löchern in 10 Jahren "wirbt".

Core Security, Entdecker der Lücke, hat schon einen Exploit entwickelt, mit dem es möglich ist OpenBSD Systeme "abzuschiessen". Wirklich sicher, ob man über diesen Fehler aber Code einschleusen und ausführen kann, war man sich nicht, bis Core Security einen Exploit entwickelte mit dem genau dies möglich war und ist.

Das OpenBSD Project hat einen Patch zur Verfügung gestellt der zwar den Exploit verhindert, ob damit aber der eigentliche Fehler beseitigt ist, bleibt fraglich.

Schon 2003 stellte Pawel Jakub Dawidek (der sich in letzter Zeit vor allem durch seine Arbeit an ZFS für FreeBSD ausgezeichnet hat) einen Patch für die FreeBSD Jails vor, mit welchem man diesen mehrere IPs zuordnen kann. Bisher ist dieser Patch (für FreeBSD 4.7) aber noch nicht offiziell übernommen worden.

Nun hat DragonFlyBSD jail so modifiziert, das Jails dort mit mehreren IPs umgehen können. Basierend auf dem alten mijail Patch von 2003 von Pawel. Da muss die Frage erlaubt sein, wann kommt dieses Feature endlich auch unter FreeBSD zum Einsatz. Viele User und ISPs würden sich dies wünschen.

Aber auch bei FreeBSD ist man nicht untätig was Jails angeht. So kann man im wiki nachlesen, dass es nun mit einem Patch möglich ist, die Ressourcen die eine Jail in Ansprich nehmen kann je nach Jail einzustellen. Bleibt zu hoffen das nicht wieder knapp 4 Jahre vergehen müssen bis ein anderes BSD dieses Feature übernimmt.

Mit RIP, Recovery is possible, gibt es eine neue, spezialisierte Linux Distribution die sich Rescue/Recovery auf die Flagge schreibt. Da es hier aber nicht um Linux geht, sondern *BSD, fragt sich der geneigte Leser was dies nun mit *BSD zu tun hat. Ganz einfach, es gibt dieses System auch mit einem FreeBSD 6.2 Rescue System. Daneben gibt es RIP, welches hoffentlich nie zu einem "Rest in Peace" wird, auch als bootbare CD/DVD, USB-key, Compact Flash und PXE Boot.
Mehr Informationen und downloads gibt es auf der homepage zu RIP.

Wie Peter N. M. Hansteen auf der Mailingliste freebsd-pf@ mitgeteilt hat, ist sein PF Tutorial seit heute online.

Er hat auf der diesjährigen EuroBSDCon in Mailand einen halbtägiges Tutorial dazu gehalten.

Das Tutorial gibt es als HTML Datei, PDF, Docbook und als Folien (HTML).

Wird Windows nun endlich sicher? Nun, zumindest wurde bei Windows CE ein Schritt in die richtige Richtung unternommen und der OpenSSH Server portiert.

Das derzeitige Release 0.0.1, welches unter einer BSD Lizenz steht und keinerlei GPL cde enthält, gibt es ab sofort in der binary Form und als Quellcode zu download.

Dabei basiert die Portierung auf dem OpenSSH Server 4.3 und wurde gewählt, das OpenSSH portabel ist und der weitverbreiteste SSH Server im Internet ist.

Zur Zeit werden dabei unter Windows CE die folgenden Features angeboten:

• Remote shell


• Remote program execution


• Secure FTP (SFTP)


• Port Forwarding

Weitere Informationen über die Portierung bietet Codeplex an. Bei Codeplex handelt es sich um eine Seite, die ähnliche der von sourceforge ist, und Software bereitstellt die unter der shared source Lizenz erschienen ist.

Neben allerlei Sicherheitsvorkehrungen die getroffen werden können (Jails, Firewall, security flags und security jails) hat FreeBSD mit dem TrustedBSD Projekt ein Projekt im Rücken welches sich um die Sicherheit von FreeBSD kümmert in dem es Erweiterung für dieses entwickelt.

Dies geschieht unter der Leitung von Robert Watson, der Anfang des Jahres einen Talk in Dänemark zum TrustedBSD Project gehalten hat. Das entsprechende Video hierzu gibt es zum download als WMV Datei.

Beim kommenden FreeBSD 6.2-RELEASE wird auch erstmals das neue Security Auditing System in FreeBSD integriert sein.

"permits the selective and fine-grained logging of security-relevant system events for the purposes of post-mortem analysis, intrusion detection, and run-time monitoring analysis."

Federico Biancuzzi hat Robert Watson interviewt und Fragen zu den Vor- und Nachteilen dieses Verfahrens gestellt.

Weitere Informatrionen zum TrustedBSD Project findet man deren Webseite. Interessante Punkte des Projects dürften auch SEBSD und SEDarwin sein.

Vor nicht allzu langer Zeit erschien OpenSSH 4.4, nun folgt schon die neue Version 4.5. Zwar sind dies nur kleiner fixes, dennoch wurde ein vollwertiges Release daraus gemacht.
Die neue Version von OpenSSH ist am 08.  November 2006 erschienen und steht ab sofort zum download für OpenBSD und OpenSSH portable Systeme bereit.

Bei OpenSSH handelt es sich um eine freie SSH Verbindungssuite die nicht nur SSH anbiete sonder darüberhinaus noch scp und ftp mit sftp. Beim sshd Server sind dabei noch tools wie ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, ssh-keygen und sftp-server enthalten. Die Features von OpenSSH können hier eingesehen werden.
OpenSSH wird vom OpenBSD Projekt entwickelt, ebenso wie auch OpenNTPD und OpenBGPD. Dabei wird die Software in Ländern entwickelt die den Export von Kryptographie erlauben (dies ist beispielsweise in den USA nicht der Fall). Die Software selbst steht unter der BSD Lizenz. Wobei ein Teil davon immer noch auf Tatu Ylönen Lizenz basieren. Dies kommt daher, dass OpenSSH auf der der freien SSH Implementierung 1.2.12 von Tatu basiert. Mehr Informationen hierzu gibt es hier.
OpenSSH wird dabei von zwei Teams entwickelt. Das erste Team erstellt die Versionen direkt für OpenBSD, das zweite Team erstellt portable Versionen für Systeme unter denen OpenSSH ebenfalls läuft. Den portablen Versionen wird dabei ein “p” an die Versionsnummer anghängt.

Die Änderungen seit OpenSSH 4.4 sind relativ gering und so kann man bei OpenSSH sicher von einem BugFix Release sprechen.

Genauere Auskunft darüber geben die Release Notes von OpenSSH 4.5.