Graham Leggett

Unfortunately Docuware does not log any message during the setup of Connect to Mail, so your support suggested that a Gmail setup be created which could have the configuration changed through direct access to the database. This bypassed the buggy configuration step and revealed an exception with the Limilabs IMAP client.

I was able to open a support ticket with Limilabs to get a cleared picture of how Docuware should have been using the Limilabs IMAP code, and this led to discovering a bug in Docuware which was in turn being triggered by a bug in Redhat Enteprise Linux's version of the dovecot server.

For people arriving here via Google, the full writeup and workaround is here:

https://www.docuware.com/forum/english-forums/docuware-help-technical-pr...

This is a write up of two bugs, one in Docuware's Connect to Mail, and the other in the Dovecot IMAP server as supplied by Redhat Enterprise Linux 6 and 7. These bugs together cause Docuware Connect to Mail to be unable to connect to RHEL6 and RHEL7.

When setting up a new IMAP service, you get the error "Not able to establish connection. Please verify your input!". No underlying error is given to the end user, and nothing is logged.

By manually creating a connection in the Docuware database, you find the underlying error is as follows:

<exception>DocuWare.ConnectToMail.Communication.Exception.CommunicationClientException: Could not establish connection to mail server ---&gt; System.Exception: Connection to IMAP server imap.example.com:993 timed out after 60000ms 
at DocuWare.ConnectToMail.Communication.Clients.Components.DWImap.EstablishServerConnection(ConnectionServerContainer conServer, List`1&amp; externalLog) 
at DocuWare.ConnectToMail.Communication.Clients.Components.DWImap.EstablishClientConnection(ConnectionServerContainer conServer, ConnectionUserContainer conUser, List`1&amp; externalLog) 
at DocuWare.ConnectToMail.Communication.DwCommunicationClient.EstablishConnection(List`1&amp; externalLog) 
--- End of inner exception stack trace --- 
at DocuWare.ConnectToMail.Communication.DwCommunicationClient.EstablishConnection(List`1&amp; externalLog) 
at DocuWare.ConnectToMail.Communication.DwCommunicationClient.EstablishConnection() 
at DocuWare.BPS.C2Mail.Implementation.ProcessImplementation.EstablishConnectionToMailProvider() 
at DocuWare.BPS.C2Mail.Implementation.ProcessImplementation.Run()</exception> 

First, the Docuware bug:

When an IMAP connection is diconnected by the server side and enters a broken state, the exception thrown is not caught by Docuware, and Docuware returns this broken IMAP object to it's connection pool.

When Docuware needs this connection it retrieves the connection from the pool, and attempts to use that connection. The connection, being disconnected by the server, returns the exception above, and no successful connection is possible.

To fix this, Docuware needs to ensure that all exceptions returned by the Limilabs IMAP client are caught and the IMAP object cleanly destroyed.

Limilabs shed light on the internal workings of their library here:

https://www.limilabs.com/qa/3033/limilabs-client-serverexception-tried-d...

Second, the Redhat Enterpise Linux bug:

When a secure IMAP connection is made to Dovecot as supplied by Redhat Enterprise Linux, and the Limilabs IMAP clients requests a graceful logout, dovecot logs out but does not flush the logout confirmation before closing the TCP connection. The Limilabs IMAP client does not see the BYE command, and returns an exception, with the expectation that the IMAP connection be destroyed. Docuware returns this broken connection to it's pool and attempts to reuse the connection, resulting in failure.

Workound:

The workaround is to apply the patches to dovecot as documented in the following two bug reports, one for RHEL6 and one for RHEL7. This causes the connection to be closed properly, and thus we avoid the Docuware bug above:

https://bugzilla.redhat.com/show_bug.cgi?id=1570361

https://bugzilla.redhat.com/show_bug.cgi?id=1570017

Alas, GDPR compliance is not a matter of opinion. With a breach being found, you are expected to have an independent security consultancy come in and perform an assessment of both the breach as well as the timeliness of your security response, and adopt their recommendations.

Please publish that assessment.

Unfortunately relying on external software provided by outside parties such as the Windows Firewall to act as a crutch does not close this security hole.

Three ways to fix this are:

- Configure the Apache Tomcat server to bind to localhost only in it's default configuration. This is the workaround advice in the advisory.

- Configure the Apache Tomcat server to limit connections from given IP addresses only, defaulting to localhost, using the RemoteAddrValve.

- Configure the Apache Tomcat server to password protect connections using Tomcat's Realm mechanism.

Docuware needs to follow the security advice as documented in Tomcat's security documentation here

https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html

Docuware also needs to properly harden the Tomcat configuration, specifically by removing the unused AJP support exposed on port 8009. It was through this port that all data in Docuware was exposed. (Obviously removing AJP but leaving HTTP exposed on 9200 will not close the hole).

Hi all,

In September of last year I reported a security vulnerability involving the Docuware Fulltext Server to Docuware, which in the default configuration bypasses authentication and exposes the complete solr index if you can reach ports 9200 or 8009 with a web browser. Docuware gave the bug number 203945 to the issue. By November Docuware had not created a fix, and so as per the CVE schedule this was disclosed to the bugtraq mailing list as follows:

http://seclists.org/bugtraq/2017/Nov/54

(The link above contains details of the vulnerability and the steps you can take to fix it)

With GDPR a month away, there is much concern at the lack of progress on this issue. Can someone from Docuware confirm when we can expect to see a hotfix for this?

> The possibilities could be endless

That is not encouraging - I was expecting an explicit error message telling me the one reason that triggered the failure path.

I am connecting to our SSL protected IMAP server. The server logs that Docuware connected to it successfully. Docuware claims it it failed to do so, but gives no details of why (connection refused? timed out? DNS not found? protocol error? SSL error and if so what was it?).

We raised a support ticket yesterday, but no response as yet. Will wait till the holidays are done for that.

Having just had "Connect to Mail" enabled on our Docuware installation, we have just just to use it for the very first time.

Having entered details of our IMAP email address we want to use for Docuware, has has suitable SRV records configured for autodiscovery, we get the message "Not able to establish connection. Please verify your input!".

The mailserver reports that Docuware has successfully connected to it, however something has caused Docuware to believe it has not. Has anyone encountered this issue before and come up with a solution?

If not, does anyone know where I can find a logfile on the Docuware server that will show me the actual error message corresponding to what went wrong? Docuware does not appear to log to the standard Windows event viewer.