Security Patches pkg (aus aktuellem Anlass bash)

M

m4rkus

Well-Known Member
Hallo,

ich habe einen Server mit FreeBSD 10 Release p9 und befülle diesen mit Paketen über pkg.

Die Bash hat ja eine aktuelle Sicherheitslücke und diese ist unter VuXML auch schon bekannt (
http://www.vuxml.org/freebsd/71ad81da-4414-11e4-a33e-3c970e169bc2.html)

Ein pkg update aktualisierte zwar unter anderem die Bash, jedoch auf eine noch verwundbare Version (4.3.24)

Folgende Fragen:
  1. Warum "erkennt" ein pkg audit keine Schwachstelle, wenn die Lücke bereits unter vuxml bekannt ist?
  2. Wurde die nicht verwundbare Version noch nicht "gebaut" und im Repository hinterlegt?
  3. Bei pkg version steht hinter vielen Paketen ein "<" und nur hinter einigen ein "=". Zeigt das die Versionsdifferenz zu den Ports an?
Danke und Gruß
Markus
 
Es gibt Zyklen in welchen neue Pakete angeboten werden und ich gehe einfach mal davon aus, das eben noch keine neuen Pakete gebaut wurden. Der build-Prozess wird automatisiert alle (ich glaube) Woche angestoßen.

Würde jede Sicherheitslücke in irgendeinem Paket dazu führen, dass alles neu genaut wird hätten wir wohl nie einen gültigen Paketzustand.
 
Guten morgen :) Das ist relativ einfach:
1. Bei mir erkennt er die Bash als löchrig. Eventuell hattest du Pech, dass du die Abfrage kurz bevor die Datenbank aktualisiert wurde gestellt hast:
Code: 
bash-4.3.24 is vulnerable:
bash -- remote code execution vulnerability
CVE: CVE-2014-6271
WWW: http://portaudit.FreeBSD.org/71ad81da-4414-11e4-a33e-3c970e169bc2.html
Einfach mal mit "pkg audit -F" eine neue Datenbank ziehen und es noch mal probieren.

2. Pakete werden jeweils Mittwochs um Mitternacht gestartet und sind dann einige Tage später verfügbar. Solange wird die verwundbare Version im Repo hinterlegt bleiben und wenn man die Lücke als so kritisch einstuft, dass ein sofortiger Patch notwendig ist, muss der Port gebaut werden. Eine andere Strategie wäre wünschenswert, dürfte aber kaum umzusetzen sein. Wenn ein einziger Port wie shells/bash neugebaut werden soll, zieht es eine ganze Reihe Abhängigkeiten nach sich, die auch den sehr großen Buildcluster Stunden beschäftigen.

3. Ja. "pkg version" vergleicht zu dem INDEX der Ports in /usr/ports.
 
Hallo,

1. tatsächlich erscheint nach der Aktualisierung der audit-DB auch die Bash als löchrig :)

2. Wie macht ihr das denn?
Aktualisiert ihr dann immer das ganze System basierend auf den Ports? Arbeitet ihr mit Poudriere?

Ich hatte es schon mal in einem anderen Thread gefragt - aber noch mal zur Verdeutlichung: Seid ihr auf Produktionskisten immer "aktuell"? Ich würde gerne lediglich Sicherheitsaktualisierungen einspielen und die übrigen Pakete nur bei Bedarf aktualisieren. Heißt das ich muss auf die Ports der "Quartals-Liste" schwenken und dann geht das?

Oder wie macht ihr das? Immer wenn ein Paket Schwachstellen hat ALLE hochziehen (bspw. bash wird aktualisiert - vim automatisch mit)?

3. OK

Gruß
Markus
 
Hallo,

Ja ich baue jede Nacht meine benötigten Pakete automatisch für FreeBSD 9.2, 9.3 und 10.0. auf einer VM. Weiter ist die Option mit den Quarta-Branches sicher eine Möglichkeit. Bei den offiziellen Paketen kann es durchaus mal vorkommen, dass ein Paket mal nicht verfügbar ist. Dann dauert wieder eine Woche.

Gruss
 
Die wenigsten Sicherheitslücken sind wirklich kritisch, sprich oft braucht es schon einen User an der Tastatur. In den Fällen gehe ich davon aus, dass ich auch ein paar Tage warten kann bis ich die aktuelle Version einspiele. Anders sieht das natürlich bei Remote-Löchern aus.

Ich versuche immer das Gesamtsystems aktuell zu halten denn kleine Schritte sind oft schmerzfreier als irgendwann ein großer. Zumal ich so immer die aktuelle UPDATING heranziehen kann, anders muss ich immer erst tiefer graben ob es da noch andere Probleme beimUpdate geben könnte.

Da aktuell nur Pakete mit Standardeinstellungen vorhanden sind verwende ich leider immernoch überwiegend Ports (da es viele Pakete nicht, z.B. mit SQLite, gibt). Z.B ist der Host mir Paketen versehen und die Jails laufen über Ports.
 
Also zieht ihr immer alles gleichmäßig hoch - egal ob notwendig oder nicht (bspw. reine Feature-Aktualisierungen).

Sehe ich ja persönlich ähnlich und fahre seit Jahren auch unter Ubuntu damit ganz gut.
Dienstlich wird bei vielen Produktivsystemen halt auf Testsystemen vorher alles getestet - da kann ich nicht mal eben alles "hochziehen".

Wie ist das denn mit Major- / Minor-Upgrades.
Ein pkg upgrade aktualisiert doch in der Regel nur Minor-Upgrades (8.1.2 -> 8.1.3), oder? Hängt das vom Paket ab?

Gruß
Markus
 
m4rkus schrieb:
Wie ist das denn mit Major- / Minor-Upgrades.
Ein pkg upgrade aktualisiert doch in der Regel nur Minor-Upgrades (8.1.2 -> 8.1.3), oder? Hängt das vom Paket ab?
Zum Vergrößern anklicken....

Kommt auf den Port an. Wenn er eine Versionsnummer in der Origin trägt, dann bleibt es bei der Hauptversion. Kommt dann später eine neue Hauptversion raus, so wird ein neuer Port erstellt, der die neue Version im Namen hat.
Beispiel: databases/postgresql84-server bleibt immer auf version 8.4.x, während databases/postgresql93 immer version 9.3.x folgt.
Andere Ports, solche ohne Version im Namen, können auch schonmal eine Aktualisierung der Hauptversion bekommen.
 
Wie ist da eure Erfahrung? Haben die meisten (gängigen) Ports (Datenbanken, Webserver, Serversoftware...) eher Versionsnummern, oder einen einzigen Port?
Bei Datenbanken wäre ich skeptisch auf einmal Major-Sprünge zu machen, ohne einen vollständigen Abnahmetest durchzuführen. Bei Minor-Patches, die lediglich Bugfixes / Security Patches einbringen fänd ich das Ok.
Auch ein Editor zerreißt mir nicht das System (vim...)

Gruß
Markus
 
m4rkus: Die üblichen Verdächtigen (z.B. PostgreSQL, MySQL, ...) haben einen Port pro Minorversion z.B. databases/postgresql93-server.
 
m4rkus schrieb:
Oder wie macht ihr das? Immer wenn ein Paket Schwachstellen hat ALLE hochziehen (bspw. bash wird aktualisiert - vim automatisch mit)?
Zum Vergrößern anklicken....
Für kritische Produktivsysteme (Server mit dickem Internet-Kabel hinten dran) konfiguriere und baue ich meine Pakete selbst (dank Poudriere mittlerweile auch sehr komfortabel). Das ist in der Regel auch überschaubar, und ein Update der Pakete dauert nur wenige Minuten (außer für die beiden Kisten mit Tomcat, da sind's dann ein paar mehr Pakete, aber für die gibt's dann ein eigenes Repo...). Um nicht zu häufig mit Feature-Änderungen konfrontiert zu werden, nutze ich die Quartals-Ports. Dann muss ich mir nur alle drei Monate mal etwas intensiver den Kopf über kompatibilitätsbrechende Änderungen zerbrechen...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben