xmlparse.c: Fix extraction of namespace prefix from XML name (#186)

[hartwork]

My impression is that function setElementTypePrefix extracts the XML namespace prefix from an XML name and puts it into elementType->prefix if it was able find a registered prefix for that namespace:

libexpat/expat/lib/xmlparse.c

Lines 6050 to 6078 in 7f32910

	static int
	setElementTypePrefix(XML_Parser parser, ELEMENT_TYPE *elementType)
	{
	DTD * const dtd = parser->m_dtd; /* save one level of indirection */
	const XML_Char *name;
	for (name = elementType->name; *name; name++) {
	if (*name == XML_T(ASCII_COLON)) {
	PREFIX *prefix;
	const XML_Char *s;
	for (s = elementType->name; s != name; s++) {
	if (!poolAppendChar(&dtd->pool, *s))
	return 0;
	}
	if (!poolAppendChar(&dtd->pool, XML_T('\0')))
	return 0;
	prefix = (PREFIX *)lookup(parser, &dtd->prefixes, poolStart(&dtd->pool),
	sizeof(PREFIX));
	if (!prefix)
	return 0;
	if (prefix->name == poolStart(&dtd->pool))
	poolFinish(&dtd->pool);
	else
	poolDiscard(&dtd->pool);
	elementType->prefix = prefix;
	}
	}
	return 1;
	}

Now according to this quote …

[4] NCName ::= Name - (Char* ':' Char*) /* An XML Name, minus the ":" */

… from Namespaces in XML 1.0 (Third Edition) namespace prefixes cannot contain a colon.

It also seems that colons should be used in XML names for namespaces only, but do not render the name malformed if used otherwise they way I read this:

The Namespaces in XML Recommendation [XML Names] assigns a meaning to names containing colon characters. Therefore, authors should not use the colon in XML names except for namespace purposes, but XML processors must accept the colon as a name character.

To conclude from those two, my understanding is that we should treat all text before the first colon (if any) as a namespace prefix and treat the remainder as a name from (or relative to) that namespace, containing further colons or not.

To me, the "right" fix seems to be be to just add a break statement to the end if the inner if-block to stop after the first time we handled a colon. In my test, this patch does defuse the case of the file attached to issue #186 while keeping the test suite happy.

Review welcome and appreciated!

---

Related:

• issue [CVE-2018-20843] 88k xml file uses >2G memory #186
• pull request Fix: Skip continuous coping the string into DTD string pool #261

[pointsman]

I feel a bit uneasy about the "fix" and even more so about the explanation. It is right, that in "bare" (namespace agnostic) XML documents colons (:) are allowed in element (and also) attribute names. That is: parser created with XML_ParserCreate() should accept documents with such names (and they did and do, as far as I'm aware).

Now, if you want a parser, that accepts documents which are compliant not only to the w3c XML recommendation but also to the w3c XML namespaces recommendation the rules are a little bit adjusted. For expat this are the parsers created with XML_ParserCreateNS().

For such documents at max one colon per element (or attribute) name is possible. The productions only a few lines below the place (https://www.w3.org/TR/xml-names/#NT-QName) cited by hartwork are cristal clear in this regard (if one need a confirming look into the spec for such a basic fact about XML). More than colon is a well-formedness error in this case.

So, either the parser is a "bare" XML rec parser then any number of colons (not as start char, but otherwise) in an element or attribute name is OK and there is no special meaning to them. So there is no point in looking them up with SetElementTypePrefix().

Or the parser is an XML and XML namespaces aware parser. Then SetElementTypePrefix() should simply return parsing error at the second colon in a name.

[kwaclaw]

I have not been following this issue, just noticed it now. But it seems Rolf Ade's comment is correct. Can't go really look at the code change as I am on vacation and only have my phone at hand.

…

On Mon., Jul. 8, 2019, 1:04 a.m. Rolf Ade, ***@***.***> wrote: I feel a bit uneasy about the "fix" and even more so about the explanation. It is right, that in "bare" (namespace agnostic) XML documents colons (:) are allowed in element (and also) attribute names. That is: parser created with XML_ParserCreate() should accept documents with such names (and they did and do, as far as I'm aware). Now, if you want a parser, that accepts documents which are compliant not only to the w3c XML recommendation but also to the w3c XML namespaces recommendation the rules are a little bit adjusted. For expat this are the parsers created with XML_ParserCreateNS(). For such documents at max *one* colon per element (or attribute) name is possible. The productions only a few lines below the place ( https://www.w3.org/TR/xml-names/#NT-QName) cited by hartwork are cristal clear in this regard (if one need a confirming look into the spec for such a basic fact about XML). More than colon is a well-formedness error in this case. So, either the parser is a "bare" XML rec parser then any number of colons (not as start char, but otherwise) in an element or attribute name is OK and there is no special meaning to them. So there is no point in looking them up with SetElementTypePrefix(). Or the parser is an XML and XML namespaces aware parser. Then SetElementTypePrefix() should simply return parsing error at the second colon in a name. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#262?email_source=notifications&email_token=AAFABKUYA3J7PD4C7RTPPETP6JY65A5CNFSM4HX5H6QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZLUYSI#issuecomment-509037641>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFABKX6EK2KSEWJMXNF6ALP6JY65ANCNFSM4HX5H6QA> .

[hartwork]

Hi @pointsman and @kwaclaw ,

I appreciate the review and feedback. I would like to clearly separate the two topics that we might be about to mix here: (1) Whether the fix in this pull request made things better and/or worse and (2) if we can and should reject multiple colons and under what circumstances.

For (1) the security issue is fixed — that's better — and the name prefix extracted eventually now contains the the text up to but excluding the first colon rather than the last one. Given that a name prefix cannot contain a colon by the spec, that seems also better than before to me. Is if there is anything off in that evaluation for (1) so far?

For (2) I am happy to team up on improving the situation further. The way I read …

All element and attribute names contain either zero or one colon;

… at 7 Conformance of Documents supports @pointsman's argument. If enabling namespace support flips Expat from reporting about XML well-formedness to reporting about namespace-well-formed I guess we need to error out with a parse error in future releases indeed.

Let me know what you think!