You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@santuario.apache.org by "Ian Young (Jira)" <ji...@apache.org> on 2019/11/06 17:22:00 UTC

[jira] [Created] (SANTUARIO-514) XMLSignature processes KeyInfo elements twice

Ian Young created SANTUARIO-514:
-----------------------------------

             Summary: XMLSignature processes KeyInfo elements twice
                 Key: SANTUARIO-514
                 URL: https://issues.apache.org/jira/browse/SANTUARIO-514
             Project: Santuario
          Issue Type: Bug
          Components: Java
    Affects Versions: Java 2.1.4
            Reporter: Ian Young
            Assignee: Colm O hEigeartaigh


InĀ org.apache.xml.security.signature.XMLSignature's parsing constructor, it _looks_ like ds:KeyInfo elements are processed twice: first as KeyInfo as expected, but then a second time as if it were a ds:Object.

Around line 533 in the current trunk:

{code}
        Element keyInfoElem =
            XMLUtils.getNextElement(signatureValueElement.getNextSibling());

        // If it exists use it, but it's not mandatory
        if (keyInfoElem != null
            ....
        }

        // <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/>
        Element objectElem =
            XMLUtils.getNextElement(signatureValueElement.getNextSibling());
{code}

Note that objectElem is derived in exactly the same way as keyInfoElem, as the next sibling of the signatureValueElement.

Again, it _looks_ to me as if this means that any KeyInfo element will be additionally processed as if it were a ds:Object. The subsequent code doesn't bother to check the element's name (which is perhaps a separate concern) and instead examines every child element to see if their names are one of a couple of different specific strings without regard to namespace (only the local part of the name is compared).

This seems unintended, and in principle undesirable. I can't think of a way offhand to build an exploit around this behaviour, but perhaps someone with more imagination could...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)