UNSOLVED "certifi"-Sicherheitslücke bei iobroker Raspberry Pi
-
Ich würde da gar keine komischen Klimmzüge mit pip usw. machen sondern mich da auf das Debian Security Team verlassen.
Wenn es wirklich ein kritischer Bug wäre, dann würde das über das security-Repo ausgespielt werden. Ist aber nur 'low'.Status kannste auch hier anschauen:
https://tracker.debian.org/pkg/python-certifiSecurity status:
https://security-tracker.debian.org/tracker/source-package/python-certifiDebian's python-certifi is patched to return the location of Debian-provided CA certificates
Du musst also die Debian-provided CA certificates prüfen, nicht die Versionsnummer von 'python3-certifi'.
-
@thomas-braun said in "certifi"-Sicherheitslücke bei iobroker Raspberry Pi:
Debian-provided CA certificates
Mhhh, Debian gibt dort ja an die Mozilla Zertifikate zu nutzen, Mozilla wiederum hat eigentlich das GLOBALTRUST Zertifikat mittlerweile zurückgezogen, insofern erstaunlich das ich auf meinem aktuellen Raspberry Pi noch das fragwürdige/zurückgezogene Root-CA von GLOBALTRUST finde:
iobrokerpi:/usr/share/ca-certificates/mozilla $ ls GLOBAL* GLOBALTRUST_2020.crtNaja, ursprünglich wurde die Sicherheitslücke von Github selbst (scheinbar automatisiert) als hochkritische 7.5er CVE Lücke eingestuft, so auch von Tenable Nessus als hochkritisch eingestuft. - Je mehr man sich einliest scheint es aber tatsächlich alles halb so wild zu sein, trotz der 7.5er Einstufung mancher Dienste.
-
Schon mal per
cd /opt/iobroker/ && npm auditgeschaut...
Und NEIN, du sollst da nicht per audit fix irgendwas korrigieren...
-
Hi, nein, das habe ich noch nicht gemacht.
Hier die Ergebnisse:# npm audit report @75lb/deep-merge <=1.1.1 Severity: high @75lb/deep-merge Prototype Pollution vulnerability - https://github.com/advisori es/GHSA-28mc-g557-92m7 fix available via `npm audit fix` node_modules/@75lb/deep-merge axios 0.8.1 - 0.27.2 || 1.0.0 - 1.7.3 Severity: high Axios Cross-Site Request Forgery Vulnerability - https://github.com/advisories/G HSA-wf5p-g6vw-rhxx Axios Cross-Site Request Forgery Vulnerability - https://github.com/advisories/G HSA-wf5p-g6vw-rhxx Server-Side Request Forgery in axios - https://github.com/advisories/GHSA-8hc4-v h64-cxmj fix available via `npm audit fix --force` Will install iobroker.unifi@0.6.3, which is a breaking change node_modules/@alcalzone/pak/node_modules/axios node_modules/axios node_modules/iobroker.daswetter/node_modules/axios node_modules/iobroker.javascript/node_modules/axios node_modules/iobroker.parser/node_modules/axios node_modules/iobroker.socketio/node_modules/axios node_modules/iobroker.switchbot-hub/node_modules/axios node_modules/iobroker.ws/node_modules/axios node_modules/node-hue-api/node_modules/axios node_modules/node-ical/node_modules/axios node_modules/node-unifi/node_modules/axios @alcalzone/pak 0.3.0 - 0.10.0 Depends on vulnerable versions of axios node_modules/@alcalzone/pak @iobroker/js-controller-adapter * Depends on vulnerable versions of @alcalzone/pak Depends on vulnerable versions of @iobroker/db-objects-file Depends on vulnerable versions of @iobroker/db-objects-jsonl Depends on vulnerable versions of @iobroker/db-objects-redis Depends on vulnerable versions of @iobroker/db-states-file Depends on vulnerable versions of @iobroker/db-states-jsonl Depends on vulnerable versions of @iobroker/db-states-redis Depends on vulnerable versions of @iobroker/js-controller-common Depends on vulnerable versions of @iobroker/js-controller-common-db node_modules/@iobroker/js-controller-adapter iobroker.js-controller >=4.0.0-alpha.1-20210830-d9828cd3 Depends on vulnerable versions of @iobroker/db-objects-file Depends on vulnerable versions of @iobroker/db-objects-jsonl Depends on vulnerable versions of @iobroker/db-objects-redis Depends on vulnerable versions of @iobroker/db-states-file Depends on vulnerable versions of @iobroker/db-states-jsonl Depends on vulnerable versions of @iobroker/db-states-redis Depends on vulnerable versions of @iobroker/js-controller-adapter Depends on vulnerable versions of @iobroker/js-controller-cli Depends on vulnerable versions of @iobroker/js-controller-common Depends on vulnerable versions of @iobroker/js-controller-common-db node_modules/iobroker.js-controller @iobroker/js-controller-common-db >=6.0.1-alpha.0-20240522-6037ce8ae Depends on vulnerable versions of @alcalzone/pak node_modules/@iobroker/js-controller-common-db @iobroker/db-base >=6.0.1-alpha.0-20240522-6037ce8ae Depends on vulnerable versions of @iobroker/js-controller-common-db node_modules/@iobroker/db-base @iobroker/db-objects-file >=6.0.1-alpha.0-20240522-6037ce8ae Depends on vulnerable versions of @iobroker/db-base Depends on vulnerable versions of @iobroker/db-objects-redis node_modules/@iobroker/db-objects-file @iobroker/db-objects-jsonl >=6.0.1-alpha.0-20240522-6037ce8ae Depends on vulnerable versions of @iobroker/db-base Depends on vulnerable versions of @iobroker/db-objects-file Depends on vulnerable versions of @iobroker/db-objects-redis node_modules/@iobroker/db-objects-jsonl @iobroker/db-objects-redis >=6.0.1-alpha.0-20240522-6037ce8ae Depends on vulnerable versions of @iobroker/db-base node_modules/@iobroker/db-objects-redis @iobroker/db-states-file >=6.0.1-alpha.0-20240522-6037ce8ae Depends on vulnerable versions of @iobroker/db-base Depends on vulnerable versions of @iobroker/db-states-redis node_modules/@iobroker/db-states-file @iobroker/db-states-jsonl >=6.0.1-alpha.0-20240522-6037ce8ae Depends on vulnerable versions of @iobroker/db-base Depends on vulnerable versions of @iobroker/db-states-file Depends on vulnerable versions of @iobroker/db-states-redis node_modules/@iobroker/db-states-jsonl @iobroker/db-states-redis >=6.0.1-alpha.0-20240522-6037ce8ae Depends on vulnerable versions of @iobroker/db-base node_modules/@iobroker/db-states-redis @iobroker/js-controller-cli >=6.0.1-alpha.0-20240522-6037ce8ae Depends on vulnerable versions of @iobroker/js-controller-common Depends on vulnerable versions of @iobroker/js-controller-common-db node_modules/@iobroker/js-controller-cli @iobroker/js-controller-common >=6.0.1-alpha.0-20240522-6037ce8ae Depends on vulnerable versions of @iobroker/db-objects-file Depends on vulnerable versions of @iobroker/db-objects-jsonl Depends on vulnerable versions of @iobroker/db-objects-redis Depends on vulnerable versions of @iobroker/db-states-file Depends on vulnerable versions of @iobroker/db-states-jsonl Depends on vulnerable versions of @iobroker/db-states-redis Depends on vulnerable versions of @iobroker/js-controller-common-db node_modules/@iobroker/js-controller-common iobroker.switchbot-hub * Depends on vulnerable versions of axios node_modules/iobroker.switchbot-hub iobroker.unifi >=0.6.4 Depends on vulnerable versions of axios Depends on vulnerable versions of node-unifi node_modules/iobroker.unifi node-hue-api 2.0.0-RC1 - 5.0.0-alpha.2 Depends on vulnerable versions of axios node_modules/node-hue-api iobroker.hue >=0.6.2 Depends on vulnerable versions of node-hue-api node_modules/iobroker.hue node-ical 0.15.3 - 0.16.1 Depends on vulnerable versions of axios node_modules/node-ical iobroker.jarvis >=3.0.0 Depends on vulnerable versions of ip Depends on vulnerable versions of node-ical Depends on vulnerable versions of semver node_modules/iobroker.jarvis node-unifi >=2.3.0 Depends on vulnerable versions of axios node_modules/node-unifi braces <3.0.3 Severity: high Uncontrolled resource consumption in braces - https://github.com/advisories/GHSA -grv7-fg5c-xmjg fix available via `npm audit fix` node_modules/braces debug <=2.6.8 || 4.0.0 - 4.3.0 Severity: high debug Inefficient Regular Expression Complexity vulnerability - https://github.c om/advisories/GHSA-9vvw-cc9w-f27h Regular Expression Denial of Service in debug - https://github.com/advisories/GH SA-gxpj-cx7g-858c Regular Expression Denial of Service in debug - https://github.com/advisories/GH SA-gxpj-cx7g-858c Depends on vulnerable versions of ms fix available via `npm audit fix --force` Will install iobroker.tr-064@0.0.8, which is a breaking change node_modules/engine.io-client/node_modules/debug node_modules/iobroker.socketio/node_modules/debug node_modules/iobroker.web/node_modules/debug node_modules/mdns-discovery/node_modules/debug node_modules/socket.io-client/node_modules/debug node_modules/socket.io-parser/node_modules/debug engine.io 0.7.8 - 0.7.9 || 3.4.0 - 6.5.4 Depends on vulnerable versions of debug Depends on vulnerable versions of ws Depends on vulnerable versions of ws node_modules/engine.io node_modules/iobroker.socketio/node_modules/engine.io node_modules/iobroker.web/node_modules/engine.io socket.io 2.2.0 - 3.0.4 Depends on vulnerable versions of debug Depends on vulnerable versions of engine.io Depends on vulnerable versions of socket.io-parser node_modules/iobroker.socketio/node_modules/socket.io node_modules/iobroker.web/node_modules/socket.io iobroker.socketio 3.0.0 - 3.0.13 || 3.1.3 - 3.1.5 || 4.1.0 - 5.0.2 || 6.1 .0 - 6.5.7 || >=6.6.0 Depends on vulnerable versions of socket.io node_modules/iobroker.socketio node_modules/iobroker.web/node_modules/iobroker.socketio iobroker.web 4.2.1 - 4.3.0 || >=5.2.3 Depends on vulnerable versions of iobroker.socketio node_modules/iobroker.web engine.io-client <=3.1.1 || 3.5.0 - 3.5.3 || 4.0.0-alpha.0 - 5.2.0 Depends on vulnerable versions of debug Depends on vulnerable versions of parsejson Depends on vulnerable versions of ws node_modules/engine.io-client node_modules/iobroker.web/node_modules/engine.io-client socket.io-client 1.0.0-pre - 2.1.1 Depends on vulnerable versions of debug Depends on vulnerable versions of engine.io-client Depends on vulnerable versions of socket.io-parser node_modules/socket.io-client iobroker.cloud <=2.4.6 || 2.8.0 - 3.0.2 || >=4.0.11 Depends on vulnerable versions of socket.io-client node_modules/iobroker.cloud mdns-discovery >=0.0.4 Depends on vulnerable versions of debug Depends on vulnerable versions of dns-packet node_modules/mdns-discovery iobroker.discovery * Depends on vulnerable versions of mdns-discovery Depends on vulnerable versions of node-ssdp node_modules/iobroker.discovery iobroker.tr-064 >=0.1.1 Depends on vulnerable versions of mdns-discovery Depends on vulnerable versions of tr-O64 Depends on vulnerable versions of xml2js node_modules/iobroker.tr-064 socket.io-parser <=3.3.3 || 3.4.0 - 4.0.2 Depends on vulnerable versions of debug Depends on vulnerable versions of debug node_modules/iobroker.socketio/node_modules/socket.io-parser node_modules/iobroker.web/node_modules/socket.io-client/node_modules/socket.io -parser node_modules/iobroker.web/node_modules/socket.io-parser node_modules/socket.io-parser ip * Severity: high ip SSRF improper categorization in isPublic - https://github.com/advisories/GHSA -2p57-rm9w-gvfp fix available via `npm audit fix --force` Will install iobroker.jarvis@3.1.3, which is a breaking change node_modules/ip dns-packet <=5.2.4 Depends on vulnerable versions of ip node_modules/dns-packet node-ssdp >=1.0.1 Depends on vulnerable versions of ip node_modules/node-ssdp lodash <=4.17.20 Severity: critical Regular Expression Denial of Service (ReDoS) in lodash - https://github.com/advi sories/GHSA-x5rq-j2xg-h7qm Prototype Pollution in lodash - https://github.com/advisories/GHSA-4xc9-xhrj-v57 4 Regular Expression Denial of Service (ReDoS) in lodash - https://github.com/advi sories/GHSA-29mw-wpgm-hmr9 Prototype Pollution in lodash - https://github.com/advisories/GHSA-p6mc-m468-83g w Command Injection in lodash - https://github.com/advisories/GHSA-35jh-r3h4-6jhm Prototype Pollution in lodash - https://github.com/advisories/GHSA-fvqr-27wr-82f m Prototype Pollution in lodash - https://github.com/advisories/GHSA-jf85-cpcp-j69 5 fix available via `npm audit fix --force` Will install iobroker.modbus@0.3.11, which is a breaking change node_modules/stampit/node_modules/lodash stampit 2.0.1 - 2.1.2 Depends on vulnerable versions of lodash node_modules/stampit iobroker.modbus >=0.4.5 Depends on vulnerable versions of put Depends on vulnerable versions of stampit Depends on vulnerable versions of stampit-event-bus Depends on vulnerable versions of stampit-state-machine node_modules/iobroker.modbus stampit-event-bus * Depends on vulnerable versions of stampit node_modules/stampit-event-bus stampit-state-machine * Depends on vulnerable versions of stampit Depends on vulnerable versions of stampit-event-bus node_modules/stampit-state-machine micromatch <4.0.8 Severity: moderate Regular Expression Denial of Service (ReDoS) in micromatch - https://github.com/ advisories/GHSA-952p-6rrq-rcjv fix available via `npm audit fix` node_modules/micromatch ms <2.0.0 Severity: moderate Vercel ms Inefficient Regular Expression Complexity vulnerability - https://gith ub.com/advisories/GHSA-w9mr-4mfr-499f fix available via `npm audit fix --force` Will install iobroker.tr-064@0.0.8, which is a breaking change node_modules/engine.io-client/node_modules/ms node_modules/mdns-discovery/node_modules/ms node_modules/socket.io-client/node_modules/ms node_modules/socket.io-parser/node_modules/ms parsejson * Severity: high Regular Expression Denial of Service in parsejson - https://github.com/advisorie s/GHSA-q75g-2496-mxpp fix available via `npm audit fix --force` Will install iobroker.cloud@4.0.10, which is a breaking change node_modules/parsejson path-to-regexp <=0.1.9 || 0.2.0 - 7.2.0 Severity: high path-to-regexp outputs backtracking regular expressions - https://github.com/adv isories/GHSA-9wv6-86v2-598j path-to-regexp outputs backtracking regular expressions - https://github.com/adv isories/GHSA-9wv6-86v2-598j fix available via `npm audit fix --force` Will install iobroker.simple-api@2.7.2, which is a breaking change node_modules/nise/node_modules/path-to-regexp node_modules/path-to-regexp express 4.0.0-rc1 - 4.19.2 || 5.0.0-alpha.1 - 5.0.0-beta.3 Depends on vulnerable versions of path-to-regexp node_modules/express nise * Depends on vulnerable versions of path-to-regexp node_modules/nise sinon >=3.0.0 Depends on vulnerable versions of nise node_modules/sinon @iobroker/testing * Depends on vulnerable versions of sinon Depends on vulnerable versions of sinon-chai node_modules/@iobroker/testing iobroker.simple-api >=2.8.0 Depends on vulnerable versions of @iobroker/testing node_modules/iobroker.simple-api sinon-chai >=3.0.0 Depends on vulnerable versions of sinon node_modules/sinon-chai put * Sensitive Data Exposure in put - https://github.com/advisories/GHSA-v6gv-fg46-h8 9j fix available via `npm audit fix --force` Will install iobroker.modbus@0.3.11, which is a breaking change node_modules/put request * Severity: moderate Server-Side Request Forgery in Request - https://github.com/advisories/GHSA-p8p7 -x288-28g6 Depends on vulnerable versions of tough-cookie fix available via `npm audit fix --force` Will install iobroker.backitup@0.2.7, which is a breaking change node_modules/request dropbox-v2-api * Depends on vulnerable versions of request node_modules/dropbox-v2-api iobroker.backitup >=0.3.0 Depends on vulnerable versions of dropbox-v2-api node_modules/iobroker.backitup iobroker.javascript * Depends on vulnerable versions of request node_modules/iobroker.javascript iobroker.vw-connect * Depends on vulnerable versions of request node_modules/iobroker.vw-connect tr-O64 * Depends on vulnerable versions of request node_modules/tr-O64 semver 7.0.0 - 7.5.1 Severity: high semver vulnerable to Regular Expression Denial of Service - https://github.com/a dvisories/GHSA-c2qf-rxjj-qqgw fix available via `npm audit fix --force` Will install iobroker.jarvis@3.1.3, which is a breaking change node_modules/iobroker.jarvis/node_modules/semver tough-cookie <4.1.3 Severity: moderate tough-cookie Prototype Pollution vulnerability - https://github.com/advisories/G HSA-72xf-g2v4-qvf3 fix available via `npm audit fix --force` Will install iobroker.backitup@0.2.7, which is a breaking change node_modules/tough-cookie ws 2.1.0 - 5.2.3 || 7.0.0 - 7.5.9 || 8.0.0 - 8.17.0 Severity: high ws affected by a DoS when handling a request with many HTTP headers - https://gi thub.com/advisories/GHSA-3h5v-q93c-6h6q ws affected by a DoS when handling a request with many HTTP headers - https://gi thub.com/advisories/GHSA-3h5v-q93c-6h6q ws affected by a DoS when handling a request with many HTTP headers - https://gi thub.com/advisories/GHSA-3h5v-q93c-6h6q fix available via `npm audit fix --force` Will install iobroker.cloud@4.0.10, which is a breaking change node_modules/engine.io/node_modules/ws node_modules/iobroker.web/node_modules/ws node_modules/socket.io-adapter/node_modules/ws node_modules/websocket-stream/node_modules/ws socket.io-adapter 2.5.2 - 2.5.4 Depends on vulnerable versions of ws node_modules/socket.io-adapter websocket-stream 4.0.0 - 5.1.2 || >=5.4.0 Depends on vulnerable versions of ws node_modules/websocket-stream iobroker.mqtt >=2.1.0 Depends on vulnerable versions of websocket-stream node_modules/iobroker.mqtt xml2js <0.5.0 Severity: moderate xml2js is vulnerable to prototype pollution - https://github.com/advisories/GHSA -776f-qx25-q3cc fix available via `npm audit fix --force` Will install iobroker.tr-064@0.0.8, which is a breaking change node_modules/xml2js iobroker.onkyo >=2.0.0 Depends on vulnerable versions of xml2js node_modules/iobroker.onkyo 68 vulnerabilities (4 low, 28 moderate, 34 high, 2 critical) To address issues that do not require attention, run: npm audit fix To address all issues possible (including breaking changes), run: npm audit fix --force Some issues need review, and may require choosing a different dependency. -
Deine Herumgehampel als root halte ich im Übrigen für das größere Sicherheitsproblem...Sorry, der Report fängt mit einer Raute an...
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'.
Die können hoffentlich die konkrete Schwere des Problems für die einzelnen Releases bewerten. -
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.
-
@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. -
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.
-
@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.
-
@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?
-
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 -
@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 codeauch EDIT:
Das ergibt auch Sinn, weil meines Wissens Python mit dem OS mitkommt. -
@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. -
@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? -
Ja genau. Der Bezug zu iobroker ließ sich insofern klären, dass es keinen gibt
-
@sticks sagte in "certifi"-Sicherheitslücke bei iobroker Raspberry Pi:
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
-
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)
