Santuario
  1. Santuario
  2. SANTUARIO-108

Xml canonization - UTF-8 encoding issue in Xml security 1.4.0

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Java
    • Security Level: Public (Public issues, viewable by everyone)
    • Labels:
      None
    • Environment:
      Operating System: Windows XP
      Platform: PC

      Description

      Overview Description:

      Implementation of c14n canonization method generates wrong canonical form of Xml
      document with latin characters.

      Steps to Reproduce:

      Generate canonical form of Xml document witch contains latin characters using
      Canonicalizer20010315OmitComments class and compare it with canonical form
      generated with Stylus Studio 2007 or Microsoft.NET 2.0.

      Actual Results:

      Canonicalizer20010315OmitComments class generates canonical form of Xml document
      with latin characters encoded in a wrong way.

      The problem is caused by wrong recognition if character is represented with one
      or many bytes in file "CanonicalizerBase.java" in method static final void
      outputTextToWriter(final String text, final OutputStream writer) in line 829
      ("if ((c & 0x80) ==0)")

      Example:
      let c = 0x15B //(int)c gives 347, a character 'ś'
      c & 0x80 == 0 is true so c is written to OutputStream as single byte 0x5B - '['
      character (line 830).

      As a result canonical form of input Xml document is generated in a wrong way.
      Wrong canonical form causes interoperability problems in verifying digital
      signature of files generated with libraries of other vendors.

      Expected Results:

      Xml security libraries for Apache should generate correct canonical form of Xml
      documents which contains latin characters.

        Issue Links

          Activity

          Hide
          Jason Marshall added a comment -

          This is a pretty awful bug. This will block me from being able to deploy 1.4.0,
          which I need to deal with the race condition in the X509 code.

          Has anyone figured out a workaround for this bug yet?

          From looking at the code, I think the submitter has it right here. This line he
          mentions below introduces the bug, and it was added in 1.4.

          A better option perhaps would be to achieve this optimization another way: let
          Hotspot do it for you.

          In many cases, such as exactly this scenario here, you have a method that has a
          frequently-executed conditional block at the top that uses a cheap, happy path
          (or short circuits). However, Hotspot only inlines very short methods, so the
          method call is preserved. (Can JDK 6.0 do partial inlining? I don't honestly
          know). So what some clever folks figured out is that if you factor out the
          'long path' into another method, then Hotspot will frequently inline the
          short-circuit logic into the caller.

          Show
          Jason Marshall added a comment - This is a pretty awful bug. This will block me from being able to deploy 1.4.0, which I need to deal with the race condition in the X509 code. Has anyone figured out a workaround for this bug yet? From looking at the code, I think the submitter has it right here. This line he mentions below introduces the bug, and it was added in 1.4. A better option perhaps would be to achieve this optimization another way: let Hotspot do it for you. In many cases, such as exactly this scenario here, you have a method that has a frequently-executed conditional block at the top that uses a cheap, happy path (or short circuits). However, Hotspot only inlines very short methods, so the method call is preserved. (Can JDK 6.0 do partial inlining? I don't honestly know). So what some clever folks figured out is that if you factor out the 'long path' into another method, then Hotspot will frequently inline the short-circuit logic into the caller.
          Hide
          Raul Benito added a comment -

          Fixed in SVN head, please check it.

          Show
          Raul Benito added a comment - Fixed in SVN head, please check it.
          Hide
          Raul Benito added a comment -
          Show
          Raul Benito added a comment - SANTUARIO-109 has been marked as a duplicate of this bug. ***
          Hide
          sean.mullan added a comment -
          Show
          sean.mullan added a comment - SANTUARIO-123 has been marked as a duplicate of this bug. ***
          Hide
          sean.mullan added a comment -

          Closing old bugs. Fixed in 1.4.1

          Show
          sean.mullan added a comment - Closing old bugs. Fixed in 1.4.1

            People

            • Assignee:
              Unassigned
              Reporter:
              Karol Rewera
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development