mac FMS 13 using openssl 0.9.8y after updates

[JohnP]

Hello - I have FMS 13 installed on a Mountain Lion Server, everything works fine except I received a notification from our vulnerability scanner  about openssl - the website banner for my server reads:

 

HTTP/1.1 200 OK

Date: Sat, 23 Aug 2014 13:56:13 GMT

Server: Apache/2.2.26 (Unix) mod_ssl/2.2.26 OpenSSL/0.9.8y

Last-Modified: Sun, 20 Apr 2014 18:02:37 GMT

 

As you can see it is using openssl 0.9.8y.  It was my understanding that the version 3 update included openssl 1.0.1h

Any ideas why it is still using 0.9.8y?  The latest version in that line is 0.9.8zb which would not trigger an alert, and I am able to update the MAC OS installed version but not the FMS version. I even uninstalled/reinstalled FMS 13 to no avail. Thanks for any help.

 

john

[Richard Fincher]

Actually, many of the servers which got hacked by Heartbleed, were hacked because they always installed the latest update. Versions based on the 0.9.8 codebase were not vulnerable to heartbleed.

[cbum]

Regardless of Heartbleed, why is 1.0.1not installed?

 

I have the same issue, running on 10.9.3, with updated FMS (13.0.4.400), and my IT admins are telling me I need to update OpenSSL which they see as 0.9.8 - how?

 

 

John,

how do you update the Apple OpenSSL outside of the normal AppStore updates?

[JohnP]

0.9.8 are not vulnerable to heartbleed but they are vulnerable none-the-less, prior to 0.9.8zb

 

This is how I updated to 0.9.8zb - but it did not fix my problem with FM Server:

 

(from: https://gist.github.com/DomT4/0f9dcc430d601d31ef04)

 

Open up ‘Terminal’ under /Applications/Utilities and execute:

• curl -O https://www.openssl.org/source/openssl-0.9.8zb.tar.gz
• tar zxvf openssl-*
• cd openssl-*
• sudo ./Configure --prefix=/usr/ darwin64-x86_64-cc
• sudo make
• sudo make install

 

I spoke with FM support but they were not helpful for this matter - as far as my security folks are concerned this is a vulnerable server.  The admins are seeing the apache banner or server information, possibly by using curl -I <hostname or ip address> or something like that.

 

Thanks,

-john

[JohnP]

this is the latest reply from FM support - - I will post when a solution is presented:

 

"I see what you mean. Thank you for bringing this to my attention. I have asked for clarification from my Quality Team. I will let you know as soon as I know more."

[cbum]

Sounds like I had a slightly more informative discussion with FM tech support.

 

For FMserver 13v3/4, OpenSSL 1.0.1h is installed, together with a patched instance of Apache server files, and FM server as well as any web-server functions are run off of these files.

 

The problem with institutional IT scans, such as the ones I just got subjected to, is that they do not look (or know about) these FM-installed files, and only look in the OS directories they know about, where the versions of these files installed by the OS remain untouched, indicating you are running OpenSSL 0.98x, even if you are in fact running 1.0.1 for anything FM is doing.

 

You can check the version FM is using here:

 

- "/Library/FileMaker Server/Database Server/Frameworks/OpenSSL.framework/Versions/Current/Resources/Info.plist"

 

 

I also talked to Apple Tech support, and they do not support any updates outside of their standard OS update mechanism, which has left openSSL at 0.98, presumably because it is not vulnerable to Heartbleed, ignoring other vulnerabilities (which may or may not be significant for the mac environment). They are aware of newer OpenSSL versions available "on the web", but do not want to get into endorsing anything outside of their official updates - so you are on your own if you want to do anything about the OS-installed versions to placate your IT dept...

 

I'd be interested in reading how others have dealt with this issue.

 

(For FM server 12 and earlier, no FM-version of the files are installed, they rely entirely on the OS installed versions)

[JohnP]

Unfortunately that does not seem to explain the situation - I do not believe the scans 'look in the OS directories they know about' - I believe they use other mechanisms (like curl and nmap, etc.) to determine the services running on the machine - they only know what is reported by the services running.  Neither of the responses explain why the apache server information banner reports 0.9.8y, and that is without a doubt a behavior caused by the FM server installation - I know because I removed it all, ran the scan, and it came up spotless.  In my case, if anything, it should report 0.9.8zb because I did touch those files and update them - as far as i can tell 0.9.8y no longer exists on my machine.  I understand FMS uses 1.0.1h, but these answers are not going to satisfy the network security folks.

[cbum]

Unfortunately that does not seem to explain the situation - I do not believe the scans 'look in the OS directories they know about' - I believe they use other mechanisms (like curl and nmap, etc.) to determine the services running on the machine - they only know what is reported by the services running.  Neither of the responses explain why the apache server information banner reports 0.9.8y, and that is without a doubt a behavior caused by the FM server installation - I know because I removed it all, ran the scan, and it came up spotless.  In my case, if anything, it should report 0.9.8zb because I did touch those files and update them - as far as i can tell 0.9.8y no longer exists on my machine.  I understand FMS uses 1.0.1h, but these answers are not going to satisfy the network security folks.

I don't have an answer, I'm just reporting what FM tech support told me. 

 

I get that the OS-installed versions may be detected and running, but are they relevant as threat if nothing is using them, e.g. if you only use the machine as FM server? If so, can they be shut down, leaving the FM-installed versions running?

 

When you mention you "removed it all", what happened to the system-installed files - did you remove those as well? And when you re-installed FMS, you got 0.9.8y back??? IF so, FM needs to provide more answers....

 

They did mention that FM installs its own instance of Apache server as well as OpenSSL - is it possible the Apache files have yet another version of OpenSSL?

[JohnP]

From what I understand there is the version built-in to Mac OS, typing 'openssl version' in a terminal window tells you that version.  I do not think you can 'turn it off', filemaker server just doesn't use that version - it has it's own version bundled in.  Also included as part of Filemaker server is a web server (apache), and that instance of apache is what is reporting the 0.9.8y version in use by that instance of apache - so I guess what you said is possible, that apache has another instance of ssl or it is simply reporting falsely.  

 

When I removed Filemaker Server, my Mac OS version stayed the same (0.9.8zb - because I updated it) - and of course the apache bundled with FMS was gone along with the version of opensll used by FMS.

 

I believe them when they say the guts of FM server uses the version bundled in with FM server, and I understand the concepts of FMS (web server -- web engine -- database engine) but I have to be able to explain to the security folks why their vulnerability scanner is wrong - and I can't do that at this point.  I might install on a windows machine and see how it goes from there, but that's not what I really want to do.

[cbum]

I agree with most of your post, but wonder about your take on the Apache server. FM tech support told me that their version of Apache was fully updated as well, so that should be using 1.0.1 for their Apache instance as well, I presume.

 

As you may know, the MacOS also installs Apache, even in the non-server version - is it possible that the 0.9.8y instance detected is the one installed by the OS, not FMS?

 

Alternatively, FMS installs OpenSSL 1.0.1 for itself, but uses 0.9.8y for in its Apache version, but that would not make much sense....

 

 

[JohnP]

Apache and openssl are separate programs, one being up-to-date does not mean the other is.   

 

You hit the nail on the head - this phenomenon doesn't make sense

[JohnP]

Just FYI - I was wrong about FMS bundling apache.  PHP and openSSL are bundled in FMS, not apache, according to FM support.  FMS uses the apache from the OS, so it's an Apple/apache issue.  This is old but it might be a possible explanation (from https://issues.apache.org/bugzilla/show_bug.cgi?id=23956):

 

mod_ssl (both 1.3.x and 2.x) currently uses the SSL_LIBRARY_TEXT define instead of the
SSLeay_version() function to determine the version number of OpenSSL which it is using.

This is bad because here the mod_ssl binary is carrying the OpenSSL version number instead of
querying the version of OpenSSL it's using. This can lead to confusion (especailly security related), if
for example an administrator patches OpenSSL to be 3.4.d instead of 3.4.a, to work around known
mod_ssl related vulnerabilities in OpenSSL.

Even though the system has been properly patched, it will still report the old (mod_ssl compiled in)
version number to Scanning software etc.

[cbum]

Does the new 10.9.5 update, which apparently has OpenSSL fixes, change anything?

[TinTin]

For FMserver 13v3/4, OpenSSL 1.0.1h is installed, together with a patched instance of Apache server files and FM server (as well as any web-server functions) are run off of these files.

The problem with institutional IT scans, such as the ones they just got subjected to, is that they do not look (or know about) these FM-installed files, and only look in the OS directories they know about, where the versions of these files installed by the OS remain untouched, indicating you are running OpenSSL 0.98x, even if they are in fact running 1.0.1 for anything FMS is doing.

They can check the version FMS is using here:
/Library/FileMaker Server/Database Server/Frameworks/OpenSSL.framework/Versions/Current/Resources/Info.plist

It might also be worth checking if they are running 10.9.5 and all security updates.  Apple often do their own patching of open-source software without necessarily changing the build number, so they should actually try the exploit to see if it allows it, rather than relying on the version number.

 

http://en.wikipedia.org/wiki/Backporting

 

Most vulnerability scanners can allow for backporting but you need to tell the scanner beforehand and that is where our IT Security friends may let us down.

 

http://www.tenable.com/blog/linuxunix-patch-auditing-using-nessus

 

Dealing with Backported Software Patches

Often, a Linux distribution will not upgrade their packages to the latest and greatest versions of software. Instead, they’ll keep the existing software version and only apply the security patch, keeping the version number the same. In this instance, the software no longer contains a vulnerability, but the version being displayed by the banner will trace back to being vulnerable. When this occurs, Nessus will report potentially backported software versions as follows:

Refer to our previous blog entry for information on how back port detection works in Nessus. Also note that using the quick search for "back ported" will display only the results from the back ports collection of plugins.