"certifi"-Sicherheitslücke bei iobroker Raspberry Pi

sticks

Hallo zusammen, seit einigen Tagen meldet meine "Nessus Tenable"-Instanz bei meinem iobroker Raspberry Pi eine Sicherheitslücke im Zertifikatsstore von "certifi". - Ich habe natürlich als erstes beim Raspberry PiOs Bookworm mit apt-get update / upgrade auf die neueste Version hochgezogen. - Das blieb erfolglos, die Sciherheitslücke besteht weiterhin.

link text

Dann habe ich versucht "pip" nachzuinstallieren, um mit "pip install certifi" die neueste, bereinigte Version zu installieren. Da sagte mir pip aber, in meinem Fall kann es das nicht tun, weil es ein "externally-managed-environment" vorgefunden hat, also ein Python einer anderen Instanz (von iobroker nehme ich an). - In iobroker sind aber auch alle Updates drin.

iobroker v7.0.23
Node.js: v20.17.0
NPM: 10.8.2
JS-Controller: 6.0.11

Falls das betroffene "certifi"-Paket in einem meiner installierten Adapter steckt, kriege ich raus in welchem ?

Thomas Braun · iobroker v7.0.23 Node.js: v20.17.0 NPM: 10.8.2 JS-Controller: 6.0.11

@sticks

apt policy python3-certifi

anschauen. Kiste generell immer auf einem aktuellen Stand halten. Keine 'Hals-über-Kopf'-Aktionen.
Warum installiert man pip nach, wenn es ja zuvor gar nicht auf dem System war?
Das "externally-managed-environment" bezieht sich ja gerade darauf, dass man da keine python-Pakete 'von irgendwoher' einfach in das System bügelt.

sticks

@thomas-braun

Die Ausgabe des Befehls bestätigt, dass noch die gefährdete Version von 2022 installiert ist, nicht die gepatchte Variante von Juli 2024.

iobrokerpi:~ $ apt policy python3-certifi
python3-certifi:
  Installed: 2022.9.24-1
  Candidate: 2022.9.24-1
  Version table:
 *** 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

Thomas Braun

@sticks

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-certifi

Security status:
https://security-tracker.debian.org/tracker/source-package/python-certifi

Debian'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'.

sticks

@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.crt

Naja, 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.

Thomas Braun

@sticks

Schon mal per

cd /opt/iobroker/ && npm audit

geschaut...

Und NEIN, du sollst da nicht per audit fix irgendwas korrigieren...

sticks

@thomas-braun

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.

Thomas Braun

@sticks

~~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.

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

Community Forum

NEWS

"certifi"-Sicherheitslücke bei iobroker Raspberry Pi

Support us

886

32.4k

81.5k

1.3m