Repository navigation
TOCTOU race in max-instances check allows unauthenticated container spawn beyond configured limits #591
Description
Activity
Hi, first of all, thanks for opening this issue.
When implementing this feature we were aware there could be an overshoot in the number of allowed instances. The reason is that implementing a lock also comes with some risks, e.g. around deadlocks and implementing it in a fast way when using multiple replicas.
Nevertheless, it seems the overshoot is higher compared to what we originally expected and tested. This could be because of some refactors we did.
We'll therefore fix this in the next release.On the app_direct path, the 10-minute blocking wait simultaneously exhausts the Undertow thread pool, causing full denial of service.
This is correct and this is also the reason we no longer use the
app_directendpoint in the UI itself. But the endpoint still works, so it could be used to lock the server. For the next release I'll disable theapp_directendpoint by default, and add an option to enable it.We use
app_directfor showcasing apps on our website using direct links. We also noticed that themax-total-instancesdoes not work reliably and have therefore enforced a limit on the Kubernetes side instead.It would be a shame if the
app_directoption would slowly be phased out as embedding apps on websites is a great feature of shinyproxy!
Summary
Concurrent requests bypass the max-instances limit and spawn containers beyond the configured cap. Any internet visitor triggers this with parallel requests.
Vulnerability Details
validateMaxInstances() at BaseController.java:262-281 reads the current proxy count, then the caller starts a proxy — two separate operations with no lock between them:
long currentAmountOfInstances = proxyService.getUserProxiesBySpecId(spec.getId()).count();
return currentAmountOfInstances < maxInstances;
POST /app_i/{specId}/{appInstanceName} at AppController.java:283 starts proxies via asyncProxyService.startProxy() — asynchronous, returns immediately. The new proxy does not
appear in the active list until async initialization completes. Every concurrent request that hits the count query before the first proxy registers sees the stale count and
passes.
Each request uses a different instance name (inst_1, inst_2, etc.), so the instance name uniqueness check at AppController.java:264-266 does not block them.
GET /app_direct_i/** at AppDirectController.java:96-106 has the same race, with the added cost that each request blocks a server thread for up to 10 minutes
(AppDirectController.java:116-132).
max-total-instances is only a config setter passed to ContainerProxy (ShinyProxySpecProvider.java:572-577). It is never enforced in ShinyProxy code.
Steps to Reproduce
for i in $(seq 1 20); do
curl -s -X POST "https://target/app_i/myapp/inst_$i" &
done
Impact
An attacker exhausts Docker or Kubernetes compute by spawning containers past the configured limit. On the app_direct path, the 10-minute blocking wait simultaneously
exhausts the Undertow thread pool, causing full denial of service.