SANTUARIO-513 bug status

[BEEK Graham <gr...@capgemini.com>]

Hi,

This bug was raised 2 and a bit years ago and would seem quite important at first glance, but there has been no activity. Would someone be able to confirm whether it is as important as it sounds and whether a patch is available or even where the check mentioned is located?

This is the description:


There's a bug in the Signature load routine that relates to a commented out check that was failing the load when unknown content appeared at the end of a Signature element.

The code was unwisely changed to permit "non-conformant signatures", which is an absolutely indefensible decision. This is how you get security bugs. Non-conformant signatures can go right to hell.

Adding an option to control this behavior is the absolute minimum we should do, but the default should be strict, and the rest of the load methods should be reviewed for any similar permissiveness.



Many thanks,
Graham

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

RE: SANTUARIO-513 bug status

[BEEK Graham <gr...@capgemini.com>]

Yes, that's correct. I should have mentioned that I'm interested in the C++ library.

-----Original Message-----
From: Colm O hEigeartaigh <co...@apache.org> 
Sent: 19 January 2022 15:43
To: dev@santuario.apache.org
Subject: Re: SANTUARIO-513 bug status

***This mail has been sent from an external source***

Note, this comment only applies to the C++ library, not the Java library.

Colm.

On Wed, Jan 19, 2022 at 3:39 PM BEEK Graham <gr...@capgemini.com> wrote:
>
> Hi,
>
>
>
> This bug was raised 2 and a bit years ago and would seem quite important at first glance, but there has been no activity. Would someone be able to confirm whether it is as important as it sounds and whether a patch is available or even where the check mentioned is located?
>
>
>
> This is the description:
>
>
>
> There's a bug in the Signature load routine that relates to a commented out check that was failing the load when unknown content appeared at the end of a Signature element.
>
> The code was unwisely changed to permit "non-conformant signatures", which is an absolutely indefensible decision. This is how you get security bugs. Non-conformant signatures can go right to hell.
>
> Adding an option to control this behavior is the absolute minimum we should do, but the default should be strict, and the rest of the load methods should be reviewed for any similar permissiveness.
>
>
>
>
>
>
>
> Many thanks,
> Graham
>
>
>
> This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

Re: SANTUARIO-513 bug status

[Colm O hEigeartaigh <co...@apache.org>]

Note, this comment only applies to the C++ library, not the Java library.

Colm.

On Wed, Jan 19, 2022 at 3:39 PM BEEK Graham <gr...@capgemini.com> wrote:
>
> Hi,
>
>
>
> This bug was raised 2 and a bit years ago and would seem quite important at first glance, but there has been no activity. Would someone be able to confirm whether it is as important as it sounds and whether a patch is available or even where the check mentioned is located?
>
>
>
> This is the description:
>
>
>
> There's a bug in the Signature load routine that relates to a commented out check that was failing the load when unknown content appeared at the end of a Signature element.
>
> The code was unwisely changed to permit "non-conformant signatures", which is an absolutely indefensible decision. This is how you get security bugs. Non-conformant signatures can go right to hell.
>
> Adding an option to control this behavior is the absolute minimum we should do, but the default should be strict, and the rest of the load methods should be reviewed for any similar permissiveness.
>
>
>
>
>
>
>
> Many thanks,
> Graham
>
>
>
> This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

Re: SANTUARIO-513 bug status

["Cantor, Scott" <ca...@osu.edu>]

On 1/19/22, 10:39 AM, "BEEK Graham" <gr...@capgemini.com> wrote:

>    This bug was raised 2 and a bit years ago and would seem quite important at first glance, but there has been
> no activity. Would someone be able to confirm whether it is as important as it sounds and whether a patch is
> available or even where the check mentioned is located?

It's "important" in the sense that if I felt the code had a future I would have spent time on it, but my time is being spent getting off this code so that I'm no longer exposed to it. (That's much more because of Xerces' moribund state than Santuario's.) There is no patch and no feature releases expected that could add it.

There are no other committers left on this code base and once I no longer use it, I will not be maintaining it any further. Whether anyone else chooses to I cannot say. Nothing is stopping them now. 

As a practical matter, the bug itself is not directly a security bug, it's just a design decision that leaves the code more vulnerable to creative attacks that have not been disclosed or even invented (I hope the latter of course). Processing XML grammars used for protocols non-strictly is not a feature, and JSON approaches make the same mistake because people think flexibility is more important. Postel's Law is not only not a law, it's not even a good idea when it comes to security specs.

-- Scott