2 Replies Latest reply on Sep 21, 2015 11:00 AM by isvsecwatch

    Security issues with Filemaker Server


      We recently became aware of two security issues for Filemaker Server;


      1. The bundled Java SE installed by the trial version is woefully out of date; Java 8 U31 is installed, when U60 is the current, supported version of the software available from Oracle.
      2. Filemaker Server ships with weak 512-bit DH keys, and prioritises the DHE ciphers over static ones, which quite likely makes it vulnerable to things like the Logjam attack. The minimum size DH key currently recommended is 2048-bit, see Weak Diffie-Hellman and the Logjam Attack for details.


      This means that by default, any instance of Filemaker Server exposed to the Internet will be vulnerable in ways that few users will be aware of, and, even if they are aware, they can do nothing about, because there does not seem to be a documented way to define the cipher suite offered by Filemaker Server on port 5003.


      For an example of this problem on one of quite a few Filemaker Server instances on the Internet, see;
      n324.fmphost.com - filemaker database server · Issue #46 · isvsecwatch/httpstracker · GitHub


      Again, the above is one example, there are a lot more of them.


      Please review your code, and update your software.

        • 1. Re: Security issues with Filemaker Server



          Thank you for your post.


          FileMaker Server was certified to run with Java 8 Update 31, and it was bundled into the product installation.  This ensure the minimum version of Java is installed onto machines.  Users can download and install more recent versions of Java.


          Thank you for the more critical information about FileMaker Server being susceptible to Logjam Attack.  I have forwarded this information to our Development and Testing teams for review.  When I receive any feedback, I will let you know.



          FileMaker, Inc.

          • 2. Re: Security issues with Filemaker Server

            You're shipping a Java version that expired in April/May this year;
            Java™ SE Development Kit 8, Update 31 Release Notes


            If you ship Java, updating your bundle is something you should do on a regular basis, including any internal certification. I understand that this might take a while, but a lag of six months or more is a bit irresponsible.