Table of Contents
...
- For your flower release configure the new mod-data-export-spring and mod-remote-storage versions, you MUST set the
SYSTEM_USER_PASSWORD
environment variable. Avoid using values which are easy to guess, such as the module name or the system username. - Deploy the new module versions.
- For each tenant
$TENANT
migrate to the new module version:- For Orchid:
curl -d '[{"id":"mod-data-export-spring-2.0.2","action":"enable"},{"id":"mod-remote-storage-2.0.3","action":"enable"}]'
http://$OKAPI:9130/_/proxy/tenants/$TENANT/install?reinstall=true
- For Nolana:
curl -d '[{"id":"mod-data-export-spring-1.5.4","action":"enable"},{"id":"mod-remote-storage-1.7.2","action":"enable"}]'
http://$OKAPI:9130/_/proxy/tenants/$TENANT/install?reinstall=true
- For Orchid:
- For each tenant verify that the patch has been successfully applied: Go to the UI and try to login. Use the default username
data-export-system-user
andsystem-user
(for remote-storage) and the new password. NOTE: These system users do not have UI permissions, so once you log in, you won't be able to do anything in the UI/stripes. It's sufficient to check that you're able to authenticate. - You may also want to check the logs for these two modules for any entries which might indicate a problem.
...
N.B. After changing SYSTEM_USER_PASSWORD
or SYSTEM_USER_NAME
it is NOT sufficient to only redeploy the module; you also MUST reinstall the module as show above.
N.B. Disabling an affected module is NOT sufficient to fix the vulnerability.
Am I a victim?
Unfortunately the Folio Security Team is unaware of a way to conclusively determine if these vulnerabilities have been exploited. OKAPI does log the user ID for all proxied requests, so you may look for unusual activity associated with either of these users. Depending on your hosting infrastructure, it may also be possible to look at load balancer and/or reverse proxy logs, but there may not be enough information logged there if request payloads/certain headers aren't captured. Another challenge is the volume of logs which need to be inspected. These vulnerabilities have been around for a long time (~2 years). Looking for something subjective like "unusual behavior" isn't something which can be easily scripted/automated, and looking at 2 years of logs manually isn't realistic either.