Re: Informatica and SSL connections

Hi again

Ok when i said that i have tried to replace the libraries i was doing
it in the wrong place (not the crashing client but the server).

Just let you know that copying the libeay32 and ssleay32 from the
ODBC driver and replacing the ones in the Informatica client seems to
resolve the issue. So i suspect that something like
(https://github.com/droe/sslsplit/issues/16) was happening and openssl
libraries from Informatica somehow corrupted data structures used inside
libpq... leading to the crash while freeing the ssl connection.

Just writing this to let you know or for anybody with a similar behavior.

Regards!

Jacobo

On 16-Feb-17 14:25, Jacobo Sánchez wrote:
>
> Hi
>
> I think so.At least it includes libeay and ssleay dlls (which i
> tried to replace with the ones from the driver).
>
> I managed to narrow it down to libpq in fe-secure-openssl.c in
> pgtls_close.
>
> With the mentioned heidiSQL fields in conn->ssl struct seems to be
> messed up with invalid values so it is not the same issue than
> Informatica.
>
> The call to openssl crashing Informatica is
>
> SSL_free(conn->ssl);
>
> dont know why currently. Just printed some conn->ssl struct fields
> (ssl->type, ssl->version, ssl->quiet_shutdown, ssl->shutdown,
> ssl->references) but still did not found anything suspicious. I will
> try to figure out at least when it will fail in order to prevent the
> call then.
>
> Thanks for your replys BTW!
>
> Regards
>
> Jacobo
>
>
>
> El 16/02/17 a las 13:30, Inoue, Hiroshi escribió:
>> Hi,
>>
>> Does informatica itself use SSL communications?
>>
>> regards,
>> Hiroshi Inoue
>>
>> On 2017/02/16 18:50, Jacobo Sánchez wrote:
>>>
>>> Hi again
>>>
>>> I could somehow install a similar environment in my machine and
>>> new version also crashes when using SSL. However from what i have
>>> found from google it points more to an issue with libpq (interacting
>>> with some other libraries maybe). I could avoid the issue by not
>>> calling PQFinish() in method SOCK_Destructor of socket.c from
>>> version 09.03.400 but im not sure which kind of problems/leaks this
>>> may raise, do you have any idea of how bad may be this workaround?
>>>
>>> I could also reproduce the error by installing 32 bit version of
>>> heidiSQL (following the error described in
>>> http://www.heidisql.com/forum.php?t=15646) and it also crashes
>>> calling PQFinish() method (by calling directly libpq and not using
>>> ODBC).
>>>
>>> There is also an old (2005) thread in the postgres mailing list
>>> that seems related but im not really sure
>>> http://postgresql.nabble.com/BUG-2246-Bad-malloc-interactions-ecpg-openssl-td2119930.html
>>>
>>> All i found points more to libpq than to the driver itself.
>>> However seems to be a tricky thing and i have not an isolated test
>>> case without using external clients :(
>>>
>>> Regards
>>> Jacobo
>>>
>>>
>>> El 14/02/17 a las 12:21, Inoue, Hiroshi escribió:
>>>> Hi,
>>>>
>>>> On 2017/02/14 17:34, Jacobo Sánchez wrote:
>>>>>
>>>>> Hello
>>>>>
>>>>>
>>>>> Im currently looking for a test environment under my control
>>>>> in order to check this or any other solution. Is there any
>>>>> specific change that may lead to think that this could be already
>>>>> fixed in 09.06.100?
>>>>
>>>> After 09.05.0100 the driver uses libpq fully, whereas the driver
>>>> used libpq partially before.
>>>>
>>>> regards,
>>>> Hiroshi Inoue
>>>>
>>>>> That may give me a chance to speed up things by asking for testing
>>>>> it in a real environment.
>>>>>
>>>>> Thanks for your response, I will notify the results with
>>>>> 09.06.100 when tested.
>>>>>
>>>>> Regards
>>>>>
>>>>> Jacobo
>>>>>
>>>>>
>>>>> El 14/02/17 a las 03:26, Inoue, Hiroshi escribió:
>>>>>> Hi Jacobo,
>>>>>>
>>>>>> On 2017/02/14 1:06, Jacobo Sánchez wrote:
>>>>>>>
>>>>>>> Hello all
>>>>>>>
>>>>>>>
>>>>>>> Im facing an issue using the ODBC driver from Informatica which
>>>>>>> may be resumed in the following (im using 09.03.400):
>>>>>>
>>>>>> Could you try the latest version 09.06.0100?
>>>>>>
>>>>>> regards,
>>>>>> Hiroshi Inoue
>>>>>>
>>>>>>> https://kb.informatica.com/solution/23/Pages/52/320564.aspx
>>>>>>>
>>>>>>> If someone does not want to open the URL the failing trace is as
>>>>>>> follows:
>>>>>>>
>>>>>>> Crashing Thread is as follows:
>>>>>>>
>>>>>>> ntdll!RtlFreeHeap+132
>>>>>>> msvcrt!free+1c
>>>>>>> libeay32!CRYPTO_free+2e
>>>>>>> libeay32!ASN1_STRING_free+27
>>>>>>> libeay32!ASN1_primitive_free+ac
>>>>>>> libeay32!ASN1_template_free+128
>>>>>>> libeay32!ASN1_template_free+9b
>>>>>>> libeay32!ASN1_item_free+1e9
>>>>>>> libeay32!X509_free+1a
>>>>>>> libpq!PQinitSSL+105c
>>>>>>> libpq!PQinitSSL+1113
>>>>>>> libpq!PQencryptPassword+7cf
>>>>>>> libpq!PQfinish+12
>>>>>>> psqlodbc35w!ConfigDriver+1b7e
>>>>>>> psqlodbc35w!Ordinal93+4162
>>>>>>> psqlodbc35w!Ordinal93+3285
>>>>>>> psqlodbc35w!SQLDisconnect+5f
>>>>>>> odbc32!SQLDisconnect+2ae
>>>>>>> pmodbc!TODBCDb::Disconnect+7f
>>>>>>> pmodlnt!TDatabase::Disconnect+3c
>>>>>>> pmrelrdr!relReader::fetch+54be
>>>>>>> pmservnt!readerSource::operator=+307f
>>>>>>> pmservnt!DTMMain+219e8
>>>>>>> pmservnt!Writer::Writer+632b
>>>>>>> pmservnt!SSeqGenHandler::operator=+2897
>>>>>>> pmservnt!isForeignKey+6dd
>>>>>>> pmcef!SThread::init+293
>>>>>>> kernel32!BaseThreadInitThunk+d
>>>>>>> ntdll!RtlUserThreadStart+1d
>>>>>>>
>>>>>>>
>>>>>>> ODBC Trace is as follows:
>>>>>>>
>>>>>>> _dss_000PQZ0I0 19d8-256c ENTER SQLFreeStmt
>>>>>>> HSTMT 0x0000000005C2D030
>>>>>>> UWORD 1 <SQL_DROP>
>>>>>>>
>>>>>>> s_dss_000PQZ0I0 19d8-256c EXIT SQLFreeStmt with return code
>>>>>>> 0 (SQL_SUCCESS)
>>>>>>> HSTMT 0x0000000005C2D030
>>>>>>> UWORD 1 <SQL_DROP>
>>>>>>>
>>>>>>> s_dss_000PQZ0I0 19d8-256c ENTER SQLTransact
>>>>>>> HENV 0x0000000000000000
>>>>>>> HDBC 0x0000000005C25560
>>>>>>> UWORD 0 <SQL_COMMIT>
>>>>>>>
>>>>>>> s_dss_000PQZ0I0 19d8-256c EXIT SQLTransact with return code
>>>>>>> 0 (SQL_SUCCESS)
>>>>>>> HENV 0x0000000000000000
>>>>>>> HDBC 0x0000000005C25560
>>>>>>> UWORD 0 <SQL_COMMIT>
>>>>>>>
>>>>>>> s_dss_000PQZ0I0 19d8-256c ENTER SQLDisconnect
>>>>>>> HDBC 0x0000000005C25560​
>>>>>>>
>>>>>>> I am searching for the root of the issue in order to prevent it
>>>>>>> from happening but i am not really sure if the problem comes
>>>>>>> from libpq or the driver itself. As far as i understand this is
>>>>>>> a segmentation fault by trying to free a malloc that has been
>>>>>>> already freed, however im not sure if the problem comes from
>>>>>>> PQfinish of the driver calling it when it shouldn't.
>>>>>>>
>>>>>>> Anyone can point me to where the issue comes from?
>>>>>>>
>>>>>>> Regards, Jacobo
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>