Okiok is releasing version 4.8.3 of S-Filer/Portal™.
Security Fixes
This release includes several security fixes following penetration tests on the application, please upgrade as soon as possible:
- Removed a test servlet which was listening on port 5001 for RMI connections. Because of flaws in the RMI protocol, this servlet introduced a “Remote Code Execution” vulnerability. This port was not used by S-Filer, so it was not opened in firewalls in most installations. However, if there were no firewalls, this port was accessible and vulnerable.
- Added “Cross Site Request Forgery”(CSRF) tokens to all parts of the application to prevent CSRF attacks.
- Fixed a cross site scripting (XSS) vulnerability in the transfer status reporting functionality. This XSS was exclusively linked to the user session so it was hard to exploit in practice, however, in conjunction with the CSRF vulnerability, an attacker could forge a request to trigger the XSS.
- The configuration console allowed entering an IP address to connect to various S-Filer/Portal servers. If an administrator or malicious user entered an IP of an external site and there were no firewalls preventing the external connection, the server would attempt a connection to the external site. To mitigate this, the console can now only connect to the server on which it is installed, so the IP Address field was removed from the login page.
- S-Filer/Portal includes some deep linking functionality, specifically for mail notifications, the URL includes the UUID of the file mentioned in the notification. When the user is not authenticated, S-Filer intercepts this request and redirects to the authentication page while remembering the original URL. This redirection mechanism could be abused by crafting a specific URL which would trigger the S-Filer login page and then redirect to a malicious site. The mechanism has been fixed by only allowing redirection to URLs relative to S-Filer/Portal.
- An option was added so that the session cookie includes the secure flag indicating that it will only be sent on secure (HTTPS) connections. This option defaults to true, however, some test or development environment might be in HTTP and therefore need to disable this otherwise these environments will not work.
- An option was added to add “clickjacking” HTTP headers to the responses in order to protect against this type of attack. This effectively prevents S-Filer from being embedded in a Frame or iFrame. If clients embed the solution in a Frame or IFrame, they will need to disable this option as it defaults to true.
- An option was added to add HTTP Strict Transport Security (HSTS) headers to the responses. These indicate to web browsers that the site (any page in the same domain) should only be accessed in HTTPS. This prevents SSL strip type of attacks where a malicious user intercepts the first HTTP request and then rewrites all URLs to stay in HTTP instead of HTTPS. With this protection, browsers issue the first request directly in HTTPS. There is a second configuration indicating the time that browsers should remember this setting. In S-Filer, this default to 1 day since when deploying this initially, if it is found that there are websites that need to be accessed in HTTP in the same domain, the configuration can be reversed and after 1 day, the clients browsers will be access them again (those website will be inaccessible for 1 day). After this configuration has been deployed without problems for some time, this value can be increased to a year or more such that users are better protected.
- In all places where the application listens on a port, previously the application listened on IP “0.0.0.0” which means that the application listened on all network interfaces (all IP addresses). Now, in all these places, an additional field is added which allows specifying the IP address on which the server should listen. Sometimes, the server should listen only locally, for example, if a reverse proxy is installed on the same server, the S-Filer web port can listen on 127.0.0.1 so that direct connection to the web port are not possible when not from the localhost.
- Updated the versions of several libraries which had CVE published against them.
Features and bug fixes
This release also includes minor features and bug fixes:
- Users adopted from Active Directory accounts where an expiration date was set had their S-Filer expiration date set at the time of initial adoption. However, this date was not updated when the account was updated in subsequent adoption runs. This has been fixed and the expiration date is now correctly updated.
- An option was added which allows system administrators to exceed the system global “Time to live” (TTL) values for files when specifying the TTL of a community. This allows for scenarios where the global TTL is set to a short value while some communities used for storage have a longer TTL. WARNING: The TTL of a file uploaded in a community uses the community TTL that was specified when the file was uploaded, changing the community TTL afterwards has no effect on already uploaded files.
- An option was added which allows system administrators to exceed the system global “Time to live” (TTL) values for files when specifying the TTL of a community. This allows for scenarios where the global TTL is set to a short value while some communities used for storage have a longer TTL. WARNING: The TTL of a file uploaded in a community uses the community TTL that was specified when the file was uploaded, changing the community TTL afterwards has no effect on already uploaded files.
- The system global TTL value is now displayed when setting the community TTL in order to easily know if the community TTL is valid.
Known Issues
These minor issues will be fixed in upcoming releases:
- The update of the Java VM to Java 8 forced the customization of Kerberos settings to be done in a krb5.ini file in the conf directory of the server. Unfortunately, the Krb5.ini file is not added when updating an existing installation and the current realm settings defined in the configurator must be added manually to this file. Please contact Okiok to assist in creating the right krb5.ini file for your installation.
- The updated JVM also does not migrate the cacerts file, so if certificates were added to the JVM trust store (cacerts), they need to be added in the new VM. Further, the “Unlimited Strength Jurisdiction Policy Files” required in the JVM to use strong cryptography are not present in the installed JRE. These need to be downloaded from Oracle download site.
- The new CSRF token security measure involved a lot of changes to javascript code in the application. Unfortunately, javascript files are heavily cached by web browsers and the old javascript files often result in CSRF token validation errors. Forcing a refresh of the cached files (using CTRL-F5) should resolve this error, but must be performed by the clients accessing the site.
Updating
This section describes an update from 4.8.2
- This update does not involve any database schema changes
- This update does not change the UI themes
- This update does not change the email templates
Previous Releases
