Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian....@packages.debian.org
Usertags: pu
Dear Release Team,
The Security Team advised that CVE-2018-0486 should be fixed by a stable
update, because it isn't exploitable in the stretch version of the
Shibboleth stack, but software outside Debian could still be affected
by the issue. Stretch currently has version 1.6.0; upstream fixed this
security issue in 1.6.3 (already uploaded to unstable). Since 1.6.2 was
a revert of the most part of the changes in 1.6.1, 1.6.3 is effectively
three code changes beyond 1.6.0: the security fix itself:
diff --git a/xmltooling/io/AbstractXMLObjectUnmarshaller.cpp
b/xmltooling/io/AbstractXMLObjectUnmarshal
ler.cpp
index ae2709e..487348e 100644
--- a/xmltooling/io/AbstractXMLObjectUnmarshaller.cpp
+++ b/xmltooling/io/AbstractXMLObjectUnmarshaller.cpp
@@ -206,6 +206,8 @@ void AbstractXMLObjectUnmarshaller::unmarshallContent(const
DOMElement* domEleme
else if (childNode->getNodeType() == DOMNode::TEXT_NODE ||
childNode->getNodeType() == DOMNode::CDATA_SECTION_NODE) {
m_log.debug("processing text content at position (%d)", position);
setTextContent(childNode->getNodeValue(), position);
+ } else if (childNode->getNodeType() == DOMNode::ENTITY_REFERENCE_NODE
|| childNode->getNodeType() == DOMNode::ENTITY_NODE) {
+ throw UnmarshallingException("Unmarshaller found Entity/Reference
node.");
}
childNode = childNode->getNextSibling();
a more general fix for the same issue for Xerces 3.2 (stretch has 3.1):
diff --git a/xmltooling/util/ParserPool.cpp b/xmltooling/util/ParserPool.cpp
index bad84f7..d157074 100644
--- a/xmltooling/util/ParserPool.cpp
+++ b/xmltooling/util/ParserPool.cpp
@@ -418,6 +418,7 @@ DOMLSParser* ParserPool::createBuilder()
parser->getDomConfig()->setParameter(XMLUni::fgXercesDisableDefaultEntityResolution,
true);
parser->getDomConfig()->setParameter(XMLUni::fgDOMResourceResolver,
dynamic_cast<DOMLSResourceReso
lver*>(this));
parser->getDomConfig()->setParameter(XMLUni::fgXercesSecurityManager,
m_security.get());
+ parser->getDomConfig()->setParameter(XMLUni::fgDOMDisallowDoctype, true);
return parser;
}
and an equivalent transformation of ptr_vector<> into vector<shared_ptr<>>
to work around some Visual C++ 15 quirk:
diff --git a/xmltooling/security/AbstractPKIXTrustEngine.h
b/xmltooling/security/AbstractPKIXTrustEngin
e.h
index 3666fb7..427904d 100644
--- a/xmltooling/security/AbstractPKIXTrustEngine.h
+++ b/xmltooling/security/AbstractPKIXTrustEngine.h
@@ -33,7 +33,8 @@
#include <set>
#include <string>
-#include <boost/ptr_container/ptr_vector.hpp>
+#include <vector>
+#include <boost/shared_ptr.hpp>
namespace xmltooling {
@@ -66,7 +67,7 @@ namespace xmltooling {
AbstractPKIXTrustEngine(const xercesc::DOMElement* e=nullptr);
/** Plugins used to perform path validation. */
- boost::ptr_vector<OpenSSLPathValidator> m_pathValidators;
+ std::vector< boost::shared_ptr<OpenSSLPathValidator> >
m_pathValidators;
/** Controls revocation checking, currently limited to CRLs and
supports "off", "entityOnly",
"fullChain". */
std::string m_checkRevocation;
diff --git a/xmltooling/security/impl/AbstractPKIXTrustEngine.cpp
b/xmltooling/security/impl/AbstractPK
IXTrustEngine.cpp
index 5554fb9..54ceada 100644
--- a/xmltooling/security/impl/AbstractPKIXTrustEngine.cpp
+++ b/xmltooling/security/impl/AbstractPKIXTrustEngine.cpp
@@ -50,7 +50,6 @@ using namespace xmlsignature;
using namespace xmltooling::logging;
using namespace xmltooling;
using namespace std;
-using boost::ptr_vector;
namespace xmltooling {
// Adapter between TrustEngine and PathValidator
@@ -162,7 +161,8 @@ AbstractPKIXTrustEngine::AbstractPKIXTrustEngine(const
xercesc::DOMElement* e)
delete pv;
throw XMLSecurityException("PathValidator doesn't
support OpenSSL interface.")
;
}
- m_pathValidators.push_back(ospv);
+ boost::shared_ptr<OpenSSLPathValidator> ptr(ospv);
+ m_pathValidators.push_back(ptr);
}
}
catch (exception& ex) {
@@ -175,11 +175,12 @@ AbstractPKIXTrustEngine::AbstractPKIXTrustEngine(const
xercesc::DOMElement* e)
}
if (m_pathValidators.empty()) {
- m_pathValidators.push_back(
+ boost::shared_ptr<OpenSSLPathValidator> ptr(
dynamic_cast<OpenSSLPathValidator*>(
XMLToolingConfig::getConfig().PathValidatorManager.newPlugin(PKIX_PATHVALIDATOR,
e)
)
);
+ m_pathValidators.push_back(ptr);
}
}
@@ -377,8 +378,8 @@ bool AbstractPKIXTrustEngine::validateWithCRLs(
auto_ptr<PKIXValidationInfoIterator>
pkix(getPKIXValidationInfoIterator(credResolver, criteria));
while (pkix->next()) {
PKIXParams params(*this, *pkix.get(), inlineCRLs);
- for (ptr_vector<OpenSSLPathValidator>::const_iterator v =
m_pathValidators.begin(); v != m_pat
hValidators.end(); ++v) {
- if (v->validate(certEE, certChain, params)) {
+ for (vector< boost::shared_ptr<OpenSSLPathValidator> >::const_iterator
v = m_pathValidators.be
gin(); v != m_pathValidators.end(); ++v) {
+ if (v->get()->validate(certEE, certChain, params)) {
return true;
}
}
Based on the above, a stable update straight to 1.6.3 does not seem
unreasonable to me, but it's your call, certainly. Backporting the
first hunk (the relevant security fix) is easy enough. On the other
hand, having version numbers reflecting the reality can be useful.
So, what version number should I post the debdiff for? Please include
the Debian part as well, I haven't prepared stable updates yet.
Also, if you can estimate: when can we expect the next stable update,
that is, how much time have I got for this process?
--
Thanks,
Feri.
