AnsweredAssumed Answered

DoS security hole! Canceling find on unstored calc can block ALL USERS who search thereafter

Question asked by mrwatson-gbs on Oct 28, 2016
Latest reply on Nov 11, 2016 by TSGal

Issue

 

The blocking problem is a WELL AND LONG KNOWN ISSUE:

 

''Cancel'' button on ''Find in Progress" status window may cause FileMaker to seize (2009-02-13)

Can't cancel out of unstored finds or summaries (2013-08-27)

Can't cancel out of finds (2014-04-01)

Unstored Calculations Find Fails (2016-03-23)

+ This entry, today (2016-10-28)

 

Developers clearly want a solution to this problem:

 

Need the ability to cancel finds on unstored calc ( <- developers please vote here - has the most votes of the three ideas)

Find in progress dialog - improvements

Non-blocking Find

 

Maybe the scale of disruption caused by this issue is not yet appreciated:

 

My experience today:

 

I performed a search on a field (on an internal layout).

I noticed too late that it is unstored, and after waiting >10 minutes I pressed cancel. The cancel button disappeared - but the beachball remained.

In a second FileMaker Client I was working on, I tried to rename an account password => the client froze + beachball :-(

 

I checked the Client Stats on the FM Server Admin Console, and noticed that OTHER CLIENTS were also betting blocked:

 

Bildschirmfoto 2016-10-28 um 09.46.49.png

 

We testend the situation: Another user started the DB … and it too hung at the first search:

 

Bildschirmfoto 2016-10-28 um 09.48.10.png

 

Bildschirmfoto 2016-10-28 um 09.49.10.png

Note that the search is in a completely different file to the blocking-search I did (but same solution+server)!

 

After using the admin console to disconnect my blocked client, most users return to normal (some had crashed in the meantime):

 

Bildschirmfoto 2016-10-28 um 09.49.29.png

THIS PROBLEM CAN IN TIME WILL CAUSE THE SERVER TO BLOCK AN ENTIRE SOLUTION!

 

It is a DoS (Denial of Service) security hole in the FM Platform.

 

It is unacceptable that a single user - through misfortune, error or malice - be able to bring down an entire custom app solution COMPANY!

(Maybe this is why FMI requires FM-hosters to only host one company per FM-Server, otherwise read COMPANY PROVIDER!)

 

It is, in my opinion, also an unacceptable burden to place on developers to have to protect EVERY such field from being searched. That is not FileMakery!

 

Now that the scale of the problem has been clearly and correctly defined as a security hole - it is paramount that FMI escalate this issue and deal with this problem with top priority.

 

@FMI - please escalate this issue

@FM-developers - please vote on the ideas to show the importance

Outcomes