Impact

It is possible to make CSRF attacks against the internal API (used by client-side rendered pages) as the session cookie is not protected against usage from other origins. It may allow modifying the applied configuration.

Exploiting this requires making a Rudder user open a crafted page in a browser connected to a Rudder session. Making changes to the Rudder configuration requires a POST request, so the user needs to interact with the page to submit the crafted form.

Note: Server-side rendered forms are protected by a supplementary anti-CSRF token, and hence not vulnerable.

Workaround

Add:

Header always edit Set-Cookie (JSESSIONID=.*) "$1; SameSite=Lax"
Header onsuccess edit Set-Cookie (JSESSIONID=.*) "$1; SameSite=Lax"

at the end of /opt/rudder/etc/rudder-apache-webapp-ssl.conf on your Rudder server, then reload the apache2 or httpd service. You can also restart the rudder-jetty service to force all users to authenticate again (and get a correct cookie). This will be automatically overwritten at next server update (which will contain the fix), there will be nothing to do.

You can control the correct application of this fix by disconnecting and reconnecting to you Rudder interface, and ensuring in you browser debugger that the JSESSIONID cookie has the SameSite=Lax value.

Patches

• #4380

All Rudder versions are affected. This issue was fixed on 2022/07/26 in:

• 6.2.16
• 7.0.5
• 7.1.3

References

#21445 on the bug tracker