Keeping Your MV App Secure
April 11, 2018
Rocket MV makes it easy for you to keep up with the latest OpenSSL releases
All the important security features in UniVerse and UniData, including SSL, secure sockets, HTTP and SOAP, Automatic Data Encryption (ADE), audit logging, and BASIC Crypto API are based on OpenSSL, the world-wide renowned open source security package. With every UniVerse and UniData release, you get a Rocket-built OpenSSL package.
In this fast-changing IT world, where software vulnerabilities are discovered daily, it is vitally important to keep your OpenSSL package up to date so that your business assets are securely protected.
New versions of OpenSSL are released frequently. As I’m writing this blog post, the latest version is Open SSL 1.0.2o, released on March 27, 2018.
At Rocket we follow and assess all advisories to see if and how new OpenSSL releases impact you, our MultiValue customers and partners. For example, OpenSSL 1.0.2k addressed a moderate threat if your MultiValue application used RC4-MD5 cipher suites for secure communications. We advised our customers and partners to exclude ciphers if this seemed to be a threat to individual applications. These ciphers are not secure by today’s standards and should not be used in practice. OpenSSL 1.0.2l included bug fixes and did not address any new vulnerabilities.
OpenSSL 1.0.2m, released November 2, 2017, addresses two moderate/low risk vulnerabilities and since OpenSSL 1.0.2k is now over a year old (released January 26, 2017), we are catching up and using OpenSSL 1.0.2m in UniVerse 12.1 as the default. You may be asking, why OpenSSL 1.0.2m? For one, it contains the accumulated vulnerability and bug fixes since 1.0.2k, our last official release. Secondly, we had one technical support ticket to enhance the way we handled protocol logging. To elaborate, there was a chance that when you opened the SSL log file when using a Basic extension, especially on Windows, that unless you closed the database session, you couldn’t manipulate the log file. With OpenSSL 1.0.2m, there’s no need to log off or exit your database session before manipulating the log file (by manipulate I mean to move, delete, or change the log file).
Since we upgraded to OpenSSL 1.0.2m there have been two more new OpenSSL releases. We assessed OpenSSL 1.0.2n, and decided not to build a patch for this OpenSSL release. OpenSSL 1.0.2n addresses one moderate risk, but we don’t think it will affect you, our customers and partners. Since our code does not have that error logic, the vulnerability cannot be exploited on UniVerse and UniData, so we can safely ignore OpenSSL 1.0.2n. The same is true for OpenSSL 1.0.2o. Since UniVerse and UniData do not process PKCS7 data, the vulnerability does not affect us.
Starting with UniData 7.3.7/8.2.1 and UniVerse 11.2.5, you can apply a build to get the latest and greatest OpenSSL version. In other words, you don’t have to wait for a new release of the database to be on the latest recommended OpenSSL version. It is a good practice to monitor our new OpenSSL release and upgrade your installation in a timely manner.
The Rocket Community Portal provides a link to the latest OpenSSL build within a .zip file. Once you download the build .zip file, you’ll get installation instructions, by operating system, that include:
- Stopping your UniVerse or UniData services
- Extracting the files from the .zip
- Navigating to the extracted files
- Copying specific files into your UniVerse or UniData bin directory (the instructions also tell you the default location of the bin directory)
- Setting permissions on the OpenSSL file
In summary, when we assess a new release and decide it is important to make it available to you, it typically takes us three days to produce a new version because we add value to OpenSSL thru our database engines. One example of added value is to provide more detailed debugging messages to assist when troubleshooting complicated problems related to OpenSSL. Additionally, since we’re on multiple platforms (Windows, Linux, AIX, ….) it also takes time to build on all platforms and to adequately test the new build.
If we’re notified of a serious vulnerability we immediately call our customers. We have not made calls since the Freak vulnerability.
