Sehr geehrte opsi-Anwenderinnen- und Anwender,
wir möchten Sie informieren, dass wir am 17.01.2017 gegen 15:00 Uhr MEZ eine sicherheitsbezogene Aktualisierung veröffentlichen werden.
Weitere Informationen werden zu diesem Zeitpunkt bekannt gegeben.
Mit freundlichen Grüßen
Niko Wenselowski
Security Release: 17.01.2017, 15:00 MEZ
- n.wenselowski
- Ex-uib-Team
- Beiträge: 3194
- Registriert: 04 Apr 2013, 12:15
Security Release: 17.01.2017, 15:00 MEZ
Code: Alles auswählen
import OPSI
- n.wenselowski
- Ex-uib-Team
- Beiträge: 3194
- Registriert: 04 Apr 2013, 12:15
Re: Security Release: 17.01.2017, 15:00 MEZ
Sehr geehrte opsi-Anwenderinnen und -Anwender,
wir wurden durch Simon Bieber, Penetration Tester bei secuvera GmbH (Deutschland), auf eine Privilege Escalation in opsi aufmerksam gemacht.
Problem
Falls ein Angreifer administrative Rechte auf einem opsi-Client erlangt, ist es möglich an die Zugangsdaten des Clients zu gelangen.
Diese Zugangsdaten erlaubten Zugriff auf das Webinterface des zugehörigen opsi-Servers.
Durch die Verwendung von hostControl- oder hostControlSafe-Methoden ist es möglich Zugriff auf andere opsi Clients zu erlangen und beliebige Befehle auf diesen Maschinen auszuführen.
Unsere internen Untersuchungen haben zusätzliche Missbrauchsmöglichkeiten aufgezeigt.
Betroffen sind alle Server-Instanzen, welche eine Version von python-opsi kleiner als 4.0.7.28-4 mit der Standard ACL-Konfiguration einsetzen.
Wir sind außerdem einem möglichen Problem mit IP-Verifizierung in opsiconfd nachgegangen und konnten ein Problem in der Verifizierung entdecken, durch welches ein Zugriff möglich war, obwohl er nicht möglich sein sollte.
Betroffen sind Server-Instanzen, welche eine Version von opsiconfd kleiner als 4.0.7.4.1-1 mit aktivem "verify ip" einsetzen.
Lösung
Das Problem einer zu freizgügig gefassten ACL-Konfiguration kann durch restriktiveren Zugriff für opsi-Clients über die ACL-Konfiguration verhindert werden.
Machen Sie ein Backup ihrer Konfiguration, bevor irgendeine Änderung an der Datei /etc/opsi/backendManager/acl.conf vorgenommen wird!
Um das Problem zu beheben empfehlen wir stark die folgenden Zeilen in Ihre /etc/opsi/backendManager/acl.conf über der Zeile beginnend mit backend_.* einzufügen:
Im Falle einer umgebungsspezifischen acl.conf empfehlen wir diese Zeilen über alle anderen Statements zu stellen.
In einer Multi-Depot-Umgebung sollte diese Anpassung an jedem Depot vorgenommen werden.
Wir veröffentlichten python-opsi 4.0.7.28-5, welches eine aktualisierte acl.conf.default mit den vorgeschlagenen Änderungen beinhaltet.
Dieses Paket wird in Kürze in den opsi-Repositories bereitstehen.
Wir haben zusätzliche, noch enger gefasste ACL-Konfigurationen vorbereitet.
Bitte beachten Sie, dass diese möglicherweise Probleme mit kundenspezifischen Werkzeugen bereiten, welche auf die Webservice-API zugreifen.
Falls der Zugriff auf eine Methode verhindert wird, wird ein String im Stile von Access to method 'methodname' denied for user geloggt - wobei methodname der Name der aufgerufenen Methode ist.
Die komplette Datei kann unter http://download.uib.de/opsi4.0/misc/acl/acl.conf-strict gefunden werden.
Für den Fall, dass die Erweiterungen local-image oder WAN verwendet werden, empfehlen wir die Verwendung der folgenden Konfiguration, welche einige benötigte Ausnahmen hinzufügt: http://download.uib.de/opsi4.0/misc/acl ... ocal-image
Falls aus irgendeinem Grund auf die alte acl.conf.default zurück gewechselt werden soll, so ist diese unter https://github.com/opsi-org/python-opsi ... nf.default zu finden.
Das wird nicht empfohlen!
Um das Problem mit der IP-Verifikation zu beheben, haben wir opsiconfd 4.0.7.4.1-1 veröffentlicht. Darin enthalten sind aktualisierte Module.
Dieses Paket wird in Kürze in den opsi-Repositories bereitstehen.
Erwartete Downtime
Die Änderung der ACL-Konfigurationsdatei wird sofort für neue Sessions umgesetzt. Ein Neustart von opsiconfd ist nicht zwingend nötig, aber wird dringend empfohlen, um den Missbrauch bestehender Sessions zu verhindern.
Wenn gleichzeitig auch der opsiconfd mit aktualisiert wird sollte der Dienst bei der Aktualisierung automatisch neustarten. Um sicher zu gehen kann man den opsiconfd Dienst auch mit folgendem Befehl manuell neu starten:
In einer Multi-Depot-Umgebung empfehlen wir den Neustart des Dienstes auf allen Depots sobald möglich.
Referenzen
wir wurden durch Simon Bieber, Penetration Tester bei secuvera GmbH (Deutschland), auf eine Privilege Escalation in opsi aufmerksam gemacht.
Problem
Falls ein Angreifer administrative Rechte auf einem opsi-Client erlangt, ist es möglich an die Zugangsdaten des Clients zu gelangen.
Diese Zugangsdaten erlaubten Zugriff auf das Webinterface des zugehörigen opsi-Servers.
Durch die Verwendung von hostControl- oder hostControlSafe-Methoden ist es möglich Zugriff auf andere opsi Clients zu erlangen und beliebige Befehle auf diesen Maschinen auszuführen.
Unsere internen Untersuchungen haben zusätzliche Missbrauchsmöglichkeiten aufgezeigt.
Betroffen sind alle Server-Instanzen, welche eine Version von python-opsi kleiner als 4.0.7.28-4 mit der Standard ACL-Konfiguration einsetzen.
Wir sind außerdem einem möglichen Problem mit IP-Verifizierung in opsiconfd nachgegangen und konnten ein Problem in der Verifizierung entdecken, durch welches ein Zugriff möglich war, obwohl er nicht möglich sein sollte.
Betroffen sind Server-Instanzen, welche eine Version von opsiconfd kleiner als 4.0.7.4.1-1 mit aktivem "verify ip" einsetzen.
Lösung
Das Problem einer zu freizgügig gefassten ACL-Konfiguration kann durch restriktiveren Zugriff für opsi-Clients über die ACL-Konfiguration verhindert werden.
Machen Sie ein Backup ihrer Konfiguration, bevor irgendeine Änderung an der Datei /etc/opsi/backendManager/acl.conf vorgenommen wird!
Um das Problem zu beheben empfehlen wir stark die folgenden Zeilen in Ihre /etc/opsi/backendManager/acl.conf über der Zeile beginnend mit backend_.* einzufügen:
Code: Alles auswählen
backend_deleteBase : sys_group(opsiadmin)
hostControl.* : sys_group(opsiadmin); opsi_depotserver
In einer Multi-Depot-Umgebung sollte diese Anpassung an jedem Depot vorgenommen werden.
Wir veröffentlichten python-opsi 4.0.7.28-5, welches eine aktualisierte acl.conf.default mit den vorgeschlagenen Änderungen beinhaltet.
Dieses Paket wird in Kürze in den opsi-Repositories bereitstehen.
Wir haben zusätzliche, noch enger gefasste ACL-Konfigurationen vorbereitet.
Bitte beachten Sie, dass diese möglicherweise Probleme mit kundenspezifischen Werkzeugen bereiten, welche auf die Webservice-API zugreifen.
Falls der Zugriff auf eine Methode verhindert wird, wird ein String im Stile von Access to method 'methodname' denied for user geloggt - wobei methodname der Name der aufgerufenen Methode ist.
Die komplette Datei kann unter http://download.uib.de/opsi4.0/misc/acl/acl.conf-strict gefunden werden.
Für den Fall, dass die Erweiterungen local-image oder WAN verwendet werden, empfehlen wir die Verwendung der folgenden Konfiguration, welche einige benötigte Ausnahmen hinzufügt: http://download.uib.de/opsi4.0/misc/acl ... ocal-image
Falls aus irgendeinem Grund auf die alte acl.conf.default zurück gewechselt werden soll, so ist diese unter https://github.com/opsi-org/python-opsi ... nf.default zu finden.
Das wird nicht empfohlen!
Um das Problem mit der IP-Verifikation zu beheben, haben wir opsiconfd 4.0.7.4.1-1 veröffentlicht. Darin enthalten sind aktualisierte Module.
Dieses Paket wird in Kürze in den opsi-Repositories bereitstehen.
Erwartete Downtime
Die Änderung der ACL-Konfigurationsdatei wird sofort für neue Sessions umgesetzt. Ein Neustart von opsiconfd ist nicht zwingend nötig, aber wird dringend empfohlen, um den Missbrauch bestehender Sessions zu verhindern.
Wenn gleichzeitig auch der opsiconfd mit aktualisiert wird sollte der Dienst bei der Aktualisierung automatisch neustarten. Um sicher zu gehen kann man den opsiconfd Dienst auch mit folgendem Befehl manuell neu starten:
Code: Alles auswählen
service opsiconfd restart
Referenzen
- secuvera security advisory 2017-01 - https://www.secuvera.de/advisories/secu ... 017-01.txt (wird nach ausreichender Zeit zum Installieren der aktualisierten Version veröffentlicht, frühestens ab 2017-01-30)
Code: Alles auswählen
import OPSI
Re: Security Release: 17.01.2017, 15:00 MEZ
Mit dieser funktion das Netbook-Produkt win7-x64 nicht mehr:n.wenselowski hat geschrieben: Wir haben zusätzliche, noch enger gefasste ACL-Konfigurationen vorbereitet.
Bitte beachten Sie, dass diese möglicherweise Probleme mit kundenspezifischen Werkzeugen bereiten, welche auf die Webservice-API zugreifen.
Falls der Zugriff auf eine Methode verhindert wird, wird ein String im Stile von Access to method 'methodname' denied for user geloggt - wobei methodname der Name der aufgerufenen Methode ist.
Die komplette Datei kann unter http://download.uib.de/opsi4.0/misc/acl/acl.conf-strict gefunden werden.
Code: Alles auswählen
Access to method 'productOnClient_deleteObjects' denied for user fqdn.des.clients
- n.wenselowski
- Ex-uib-Team
- Beiträge: 3194
- Registriert: 04 Apr 2013, 12:15
Re: Security Release: 17.01.2017, 15:00 MEZ
Hi SirTux,
danke für das Feedback!
Leider an der Stelle kein unbekanntes Problem, welches soweit ich mich entsinne nur Neu-Installationen betrifft.
Für einen solchen Fall müsste temporär der Zugriff auf die entsprechende Methode erlaubt werden.
Da wir keine wirklichen Contexte für den Aufruf der Methoden haben und verhindern wollen, dass bspw. ein Client allen anderen die Installationsstände löscht, fällt mir gerade keine schnelle Lösung hierfür ein.
Ich habe mir das Thema noch mal notiert.
Viele Grüße
Niko
danke für das Feedback!
Leider an der Stelle kein unbekanntes Problem, welches soweit ich mich entsinne nur Neu-Installationen betrifft.
Für einen solchen Fall müsste temporär der Zugriff auf die entsprechende Methode erlaubt werden.
Da wir keine wirklichen Contexte für den Aufruf der Methoden haben und verhindern wollen, dass bspw. ein Client allen anderen die Installationsstände löscht, fällt mir gerade keine schnelle Lösung hierfür ein.
Ich habe mir das Thema noch mal notiert.
Viele Grüße
Niko
Code: Alles auswählen
import OPSI
Re: Security Release: 17.01.2017, 15:00 MEZ
Hi,
kleiner Zusatz: das ist ein bekanntes Phänomen und das tritt nur auf, wenn das netboot-Paket wechselt. Also wenn man zum Beispiel memtest installiert und danach win7 auf setup setzt. Dann versucht das win7 das andere Produkt zu löschen und dann knallts. Wir kennen das Problem und dazu gibt es auch ein internes Ticket meine ich
kleiner Zusatz: das ist ein bekanntes Phänomen und das tritt nur auf, wenn das netboot-Paket wechselt. Also wenn man zum Beispiel memtest installiert und danach win7 auf setup setzt. Dann versucht das win7 das andere Produkt zu löschen und dann knallts. Wir kennen das Problem und dazu gibt es auch ein internes Ticket meine ich
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
For productive opsi installations we recommend support contracts.
http://www.uib.de