UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[sticks]

@thomas-braun

Da mir Tenable im "normalen" SSH-Context die ganze Linux-Befehlshistorie mit tausenden Prüfbefehlen auf Schwachstellen voll haut,arbeite ich gerne im Root Context da ich dort dann meine eigene Befehlshistorie sehe. Das das von manchen Linux-Profis nicht gern gesehen wird, ist mir klar.

(PS: Stimmt, in dem Fall oben habe ich sogar im normalen User-Context gearbeitet. ;-) )

Zitat:
Ich wollte auch eigentlich nur deutlich machen, das jedes System offene 'Issues' hat. Die kannst du eh nicht alle angehen. Regelmäßige Systempflege sollte reichen. Um die konkrete Klassifizierung der Dinger kümmert sich im Fall von Debian halt das 'Debian Security Team'.

Ich selbst habe alle meine Serversysteme (viele Raspberrys, 2x ESXi Server, paar Windows-Server, NAS-Systeme) in der kostenlosen Lösung von Tenable Nessus. Ich patche die meisten Linux-Systeme daher mindestens einmal die Woche, da immer einige Schwachstellen vorhanden sind, wie du schon sagst. Pro System sind oft 50-80 Schwachstellen völlig normal. - Wenn eine Schwachstelle aber als "hochkritisch" eingestuft wird, wie in diesem Fall geschehen, stecke ich meist einige Energie rein das abzustellen. - Manchmal ist dies nicht möglich, im Fall jetzt hätte es ja sein können das dies mit einem bestimmten Befehl oder Deinstallation eines bestimmten iobroker Adapters gelöst gewesen wäre. - Dies ist aber nicht der Fall, von daher muss ich das einfach so hinnehmen. Was beruhigt, das die Schwachstellenbewertung "kritisch" hier ja eher unzutreffend zu sein scheint.

Demnach hat mein Raspberry mit iobroker derzeoit 92x harmlose Schwachstelllen, 5x medium Schwachstellen und eben diese 1x certifi die als kritisch eingestuft wird.

[Thomas Braun]

@sticks sagte in "certifi"-Sicherheitslücke bei iobroker Raspberry Pi:

arbeite ich gerne im Root Context da ich dort dann meine eigene Befehlshistorie sehe.

??? Die Historie ist doch als user viel besser zu sehen. Inkl. eines Wechsels in die root-Rolle.

Lass den Quark mit der root shell einfach bleiben.
Das Verhalten ist gefährlicher als deine ganzen 'Issues', die du da panisch versuchst zu stopfen.

[sticks]

@thomas-braun

Panisch ist hier keiner. Ich gehe besonnen an die Sache heran:
Nach Bekanntwerden der vermeintlich kritischen Lücke versucht man sich bestmöglich in die unbekannte Materie einzulesen. Habe mich eingearbeitet, durch das Github gelesen und dort stand ja mehr oder weniger: Wenn du genau dieses Problem/Sicherheitslücke hast dann mach mit pip ein Update und die Sache ist gelöst, denn der Maintainer con certifi hat sich schon drum gekümmert. - Ja, in diesem Fall war die Installation von pip unnötig, aber das konnte ich der Github Dokumentation zu certifi erstmal nicht entnehmen, stand da doch man kann die Lücke durch ein pip install certifi stopfen. - Als ich danach aber den Hinweis bekam, dass das ganze "externally-managed-environment" ist, war natürlich auch für mich klar, dass ich hiermit keinen Erfolg werden habe. Insofern, wenn das ganze "externally-managed-environment" ist, dann frage ich doch mal die Jungs im iobroker Forum, vielleicht ist das Problem dort ja schon bekannt. Hier habe ich nun die Hinweise auf Debian bekommen, damit ist die Sache für mich auch OK, habe ich doch jetzt die Gewissheit das ich hier nichts übersehen / fremdverursacht habe.

Kommentare zu Herumgebastel, Quark und Panik halte ich hingegen für unangebracht für einen professionellen Austausch.

[Thomas Braun]

@sticks sagte in "certifi"-Sicherheitslücke bei iobroker Raspberry Pi:

Kommentare zu Herumgebastel, Quark und Panik halte ich hingegen für unangebracht für einen professionellen Austausch.

Da keiner von uns beiden offenbar Profi ist passt das wieder.

[Homoran]

@sticks sagte in "certifi"-Sicherheitslücke bei iobroker Raspberry Pi:

Hier habe ich nun die Hinweise auf Debian bekommen,

wo soll's denn sonst herkommen?

[sticks]

@homoran

Woanders her. - Gibt ja viele Wege wie Dateien/Pakete in einem Linux-System landen können, evtl. eben auch durch iobroker selbst.

In meinem Fall habe ich z.B. zwei unterschiedliche Raspberry Pis, beide haben ein topaktuelles Debian Bookworm als Betriebssystem. Der Raspberry mit iobroker-Installation meldet mir die certifi-Sicherheitslücke, der Raspberry auf dem nur FHEM läuft hat die Lücke (noch) nicht gemeldet. - Von daher habe ich natürlich im iobroker-Bereich mit Problematiken gerechnet.

Edit: Der FHEM-PI hat die Lücke aber scheinbar auch, macht ja auch Sinn, das ist nur noch nicht über Tenable Nessus gemeldet:

fhempi:~ $ apt policy python3-certifi
python3-certifi:
  Installiert:           2022.9.24-1
  Installationskandidat: 2022.9.24-1
  Versionstabelle:
 *** 2022.9.24-1 500
        500 http://deb.debian.org/debian bookworm/main arm64 Packages
        500 http://deb.debian.org/debian bookworm/main armhf Packages
        100 /var/lib/dpkg/status

[Homoran]

@sticks sagte in "certifi"-Sicherheitslücke bei iobroker Raspberry Pi:

wie Dateien/Pakete in einem Linux-System landen können, evtl. eben auch durch iobroker selbst.

aber dann würde iobroker python ja auch über apt aus debian Quellen installieren.
iobroker selbst ist javascript/nodejs code

auch EDIT:
Das ergibt auch Sinn, weil meines Wissens Python mit dem OS mitkommt.

[Thomas Braun]

@homoran sagte in "certifi"-Sicherheitslücke bei iobroker Raspberry Pi:

Das ergibt auch Sinn, weil meines Wissens Python mit dem OS mitkommt.

Python selber schon. Die meisten (bzw. sehr viele) python-Pakete kann man direkt aus den Debian-Repos angeln. Pakete heißen dann immer 'python3-$PYTHONMODUL'. Dann sind die Versionen auch von Debian Security getrackt.
Nebenher kann man Pakete aber auch per python pip installieren. Dann läuft es natürlich an apt/dpkg ungesehen vorbei.
Und da dieses 'wilde installieren von irgendwas von irgendwoher' bei den Distributionen für Kopfschmerzen gesorgt hat, weil dann andere Dinge dadurch kaputt gingen hat man das ganze per 'externally managed system' ausgebremst. So einfach kann man nun nicht mehr per pip global python-Pakete nachinstallieren.

[Homoran]

@sticks sagte in "certifi"-Sicherheitslücke bei iobroker Raspberry Pi:

Edit: Der FHEM-PI hat die Lücke aber scheinbar auch, macht ja auch Sinn, das ist nur noch nicht über Tenable Nessus gemeldet:

und wo ist dann noch der Bezug zu ioBroker?
Hat sich das jetzt in Luft aufgelöst, und der Thread kann nach offTopic?

[sticks]

@homoran

Ja genau. Der Bezug zu iobroker ließ sich insofern klären, dass es keinen gibt :-)

[Homoran]

@sticks sagte in "certifi"-Sicherheitslücke bei iobroker Raspberry Pi:

@homoran

Ja genau. Der Bezug zu iobroker ließ sich insofern klären, dass es keinen gibt :-)

ich würde sogar doweit gehen zu behaupten, dass diese Lücke nur User betreffen könnte, die dieses Modul in Verbindung mit eigenen python Programmen verwenden.

Allerdi gs fehlt mir für eine gesicherte Aussage die notwendige Expertise

[Thomas Braun]

Weil es mir gerade beim Update meines siduction-Systems aufgefallen ist:

[2024-09-11] Accepted python-certifi 2024.8.30-1 (source) into unstable (Sebastien Delafond)

https://tracker.debian.org/pkg/python-certifi