Security Issue: Unhandled network exceptions in telemetry submitters kill the GR scheduler thread (F22+F20+F33-F36)

[Marnick39]

Affected: gr-satellites >= 1.0.0, <= 5.9.0
Severity: Medium (CVSS 3.1: 6.5, AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

Summary

Each of the telemetry-submitter blocks wraps a network call
(requests.post, requests.put, urlopen, WebSocket.send) inside
the GNU Radio handle_msg entry point without a try/except clause.
GNU Radio's thread-per-block scheduler catches uncaught exceptions
only at the very top of the thread function; once caught, the thread
exits and is not respawned. The block's input queue keeps accepting
messages — they just stay queued and never get processed.

Any transient network failure (DNS timeout, TCP RST, TLS handshake
failure, slow server, network change) raises, the handler thread
dies, and every subsequent telemetry submission is silently dropped.
The flowgraph keeps running so there's no visible error; the operator
believes they're uploading but the queue is being discarded.

Eight call sites, one fix family

Sub-finding	File:line	Trigger
F22a	funcube_submit.py:58	requests.post() outside try/except
F22b	pwsat2_submitter.py:83,112	requests.put() + .post() outside try/except
F22c	submit.py:130-140	partial wrap; mid-stream errors escape
F20	bme_submitter.py:80-87	putPacket response JSON parse uncaught
F33	bme_submitter.py:50	authenticate response JSON parse uncaught
F34	bme_submitter.py:53	authenticate keyError on missing field
F35	bme_submitter.py:71-73	putPacket keyError on missing field
F36	bme_ws_submitter.py:31,48,49	no timeout= on connect/send/recv — connect is unwrapped, send/recv are wrapped at the handler level but a stalled server still hangs the thread indefinitely

The BME server in particular completes a TLS handshake then closes
the stream on anonymous connections, which raises ConnectionError
on the very first frame after every flowgraph start — operators
running BME submission hit the bug without any attacker present.

Live endpoint status (verified 2026-05-24)

Submitter	Endpoint	Live	Exploit today
FUNcube AMSAT-UK	http://data.amsat-uk.org/api/data/hex/...	yes	yes
BME	https://gnd.bme.hu:8080/api/tokens	yes	yes (self-trigger)
SatNOGS DB	https://db.satnogs.org/api/telemetry/	yes	yes
PW-Sat2	http://radio.pw-sat.pl/api/authenticate	host up, app gone	historical only

Reproduction

disclosure/bundle-2026-05-24/v2/pocs/F22-submitter-robustness/:

• poc_F22c_urllib.py — standalone, no external deps; mock server
  half-closes mid-response, demonstrates the unpatched handler crashes

Fix

Wrap each handle_msg body in try/except Exception with a log line,
and add timeout=10 to every requests.* and websocket call. Eight
sites in five files.

Long-form advisory

https://github.com/Marnick39/gr-satellites/blob/audit-advisories/disclosure/bundle-2026-05-24/v2/ADVISORY-05-F22-submitter-robustness.md

[daniestevez]

Definitely these are bugs if what the summary says is true (and it is most likely true). The intended behaviour is that the application should continue operating even if there are transient network errors. Only the telemetry submission should be affected by these errors.

However, I disagree that this is a security issue, and the issue description does not explain why this is a security issue.

[Marnick39]

Thanks for the response!
I agree that the bug description could make the security framing much more explicit. Let me try again:

A thread dying on a network error reads as reliability on its own. The part I'd call security-relevant is that the failure is persistent and silent: any attacker who can interfere with a station's outbound submission (eg: an on-path RST, a dropped connection, a momentary network-path disruption, WiFi deauth attack, etc) stops that station from submitting with a single action. The submitter thread dies and is never respawned; subsequent frames queue undelivered; nothing recovers until the operator restarts the flowgraph. GNU Radio logs one error line as the thread dies, but nothing after — so an operator who isn't watching the console at that instant has no ongoing sign that submission has stopped. A transient, recoverable network event is converted into an ongoing, silent loss of submission.

That conversion is the part I'd call security-relevant, and it's worth being precise about why it isn't just reliability. A network-adjacent attacker can already block submissions while they're present — but that's self-healing: stop, and it resumes. The bug removes the "while they're present": one momentary disruption and the attacker can walk away, leaving the station silently offline for the rest of the run. A single momentary attack produces a continuing, self-outlasting outage. CVSS treats availability as a security property, and "silent persistent unavailability of an operator's data submission" maps cleanly onto CWE-755 (improper exception handling) and CWE-754 (improper check for unusual conditions).

Also worth stating, though I wouldn't fold it into the CVSS score of this issue: because every station with submit_tlm points at the same few telemetry servers (db.satnogs.org, gnd.bme.hu, data.amsat-uk.org), a short but successful disruption of that shared infrastructure could (through this same vulnerability) strand many stations at once, each staying dead after the infrastructure recovers rather than resuming. That depends on impacting third-party infrastructure the project doesn't own, so it's a conceivable amplifier rather than part of the score; but it's another way that this silent-no-resume behaviour seems worth fixing beyond the single station attack scenario.

That being said, if you would still rather track this as a reliability bug without the security label, that's genuinely fine by me. I care more about the try/except landing than about the wording, and I'm happy to update the issue title/body to whatever fits the project's tracking.

[daniestevez]

Thanks for the additional context. Just something else to point out: typically these decoders are run only for the duration of a LEO contact, and then started again with a different configuration (for a LEO contact of another satellite). Therefore, under the assumption of a momentarily disruption of network communications caused by an attacker, the effect is limited to the affected LEO contact, which lasts only for 8-10 minutes.