4 Commits
Author SHA1 Message Date
nicolargo f3f50323d8 SQL Injection leading to Data Exfiltration via OOB (Out-of-Band) in Glances ClickHouse Export Module - GHSA-2hvx-g9v6-w29h 2026-09-12 15:30:08 +02:00
Nguyen Thanh Dat 6b9982efec fix(ports): scope the TCP scan timeout to the scanning socket
socket.setdefaulttimeout() is process-wide and was never restored, so
once a port had been scanned every socket created afterwards anywhere in
Glances that does not set its own timeout inherited the last scanned
port's timeout -- the hddtemp grabber among them.

_socket.settimeout() sets the same value on the socket the scan actually
uses and leaves the rest of the process alone. Scan results are
unchanged.

Also return when the socket cannot be created: the code fell through
with _socket unbound, so connect_ex raised UnboundLocalError into the
'Error while scanning port' handler and the finally clause raised it
again with nothing left to catch it.
2026-08-29 07:49:32 +07:00
Nguyen Thanh Dat 57f12247be fix(ports): send the ICMP timeout in the unit each ping expects
Two problems on the same argument.

Windows 'ping -w' is a per-reply timeout in **milliseconds**, not
seconds, so a configured 'timeout = 3' became a 3 ms deadline. Measured
against two hosts that answer well within 3 seconds:

    200.160.2.3 (350 ms)  ping -n 1 -w 3    -> exit 1
    200.160.2.3 (350 ms)  ping -n 1 -w 3000 -> exit 0
    139.130.4.5 (168 ms)  ping -n 1 -w 3    -> exit 1
    139.130.4.5 (168 ms)  ping -n 1 -w 3000 -> exit 0

Windows clamps the wait to about 50 ms, so a host on the LAN still
answers in time and the bug hides; anything further away is reported
offline. Multiply by 1000 on Windows and leave -W/-t in seconds.

The timeout was also passed through _resolv_name(), which runs
socket.gethostbyname() on it. It is a number of seconds, not a host: the
lookup can only fail, and it logs a misleading 'Cannot convert 3 to IP
address' on every ICMP check.
2026-08-24 17:48:48 +07:00
Sanjay Santhanam 2bc099d820 fix(ports): resolve alert level by severity instead of dict ordering
get_default_ret_value() collapsed every matching condition into a single
'ret' key, so the level that won was whichever condition was evaluated
last rather than the most severe one. A URL that was both failing and
slow was reported as WARNING instead of CRITICAL, and a URL whose first
scan had not completed matched both CAREFUL and CRITICAL and was shown
as CRITICAL (which could also fire ports_critical_action).

Resolve by severity (CRITICAL > WARNING > CAREFUL > OK) and stop a None
status from matching the CRITICAL condition for web checks.

Adds tests/test_plugin_ports.py covering the severity ordering and the
four web scan outcomes.

Closes #3632
2026-07-30 11:16:23 -07:00