So you don't release hotfixes for OpenSSL updates. 1.0.1i has
several vulnerabilities that were fixed in 1.0.1j, and it seems like
they are finding more and more vulnerabilities within shorter and
shorter intervals.
These are all the vulnerabilities 1.0.1j just fixed in 1.0.1i:
I would suggest some kind of hotfixes, internal updates, or something to address these vulnerabilities and related fixes as soon as possible after they are updated and made available.
If that is something that you expect your users to do for themselves, then a how-to on the recommended procedure for doing so should be made public for your users to follow.
Not to mention that inside the PostgreSQL directory are very old and very vulnerable 1.0.1c versions of OpenSSL.
These are all the vulnerabilities 1.0.1j just fixed in 1.0.1i:
- CVE-2014-3513: 15th October 2014 - A flaw in the DTLS SRTP extension parsing code allows an attacker, who sends a carefully crafted handshake message, to cause OpenSSL to fail to free up to 64k of memory causing a memory leak. This could be exploited in a Denial Of Service attack. This issue affects OpenSSL 1.0.1 server implementations for both SSL/TLS and DTLS regardless of whether SRTP is used or configured. Implementations of OpenSSL that have been compiled with OPENSSL_NO_SRTP defined are not affected. (original advisory). Reported by LibreSSL project. Fixed in OpenSSL 1.0.1j (Affected 1.0.1i, 1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1)
- CVE-2014-3567: 15th October 2014 - When an OpenSSL SSL/TLS/DTLS server receives a session ticket the integrity of that ticket is first verified. In the event of a session ticket integrity check failing, OpenSSL will fail to free memory causing a memory leak. By sending a large number of invalid session tickets an attacker could exploit this issue in a Denial Of Service attack. (original advisory). Fixed in OpenSSL 1.0.1j (Affected 1.0.1i, 1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1)
- 15th October 2014 - OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications to block the ability for a MITM attacker to force a protocol downgrade. Some client applications (such as browsers) will reconnect using a downgraded protocol to work around interoperability bugs in older servers. This could be exploited by an active man-in-the-middle to downgrade connections to SSL 3.0 even if both sides of the connection support higher protocols. SSL 3.0 contains a number of weaknesses including POODLE (CVE-2014-3566). See also https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 and https://www.openssl.org/~bodo/ssl-poodle.pdf. Fixed in OpenSSL 1.0.1j (Affected 1.0.1i, 1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1)
- CVE-2014-3568: 15th October 2014 -When OpenSSL is configured with "no-ssl3" as a build option, servers could accept and complete a SSL 3.0 handshake, and clients could be configured to send them. (original advisory). Reported by Akamai Technologies. Fixed in OpenSSL 1.0.1j (Affected 1.0.1i, 1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1)
I would suggest some kind of hotfixes, internal updates, or something to address these vulnerabilities and related fixes as soon as possible after they are updated and made available.
If that is something that you expect your users to do for themselves, then a how-to on the recommended procedure for doing so should be made public for your users to follow.
Not to mention that inside the PostgreSQL directory are very old and very vulnerable 1.0.1c versions of OpenSSL.
I will do that. Why not publish the steps to fix POODLE here or somewhere on your site?Also we have the procedure to handle POODLE vulnerability hence kindly contact support team to get the latest hotfix and steps to fix POODLE vulnerability issue.Please write email to support@desktopcentral.com.