[jira] [Created] (XERCESC-2180) Handle surrogate pairs when reading a QName instead of ASSERTing

["Alberto Massari (Jira)" <xe...@xml.apache.org>]

Alberto Massari created XERCESC-2180:
----------------------------------------

             Summary: Handle surrogate pairs when reading a QName instead of ASSERTing
                 Key: XERCESC-2180
                 URL: https://issues.apache.org/jira/browse/XERCESC-2180
             Project: Xerces-C++
          Issue Type: Bug
          Components: Utilities
            Reporter: Alberto Massari
            Assignee: Alberto Massari
         Attachments: crash.xml

As discovered by Vincent Ulitzsch:

 {quote}The assertion fails when parsing a malformed xml-file, we attached a crashing testcase. We would suggest fixing this assertion, since it opens up the possibility
for Denial of Service attacks via malformed xml files.{quote}

The code expects that tre transcoder places a pair of surrogate characters in the Unicode buffers, but the UTF16 transcoder simply copies the data without checking if it ends in the middle of a surrogate pair. So the fix is to replace the assertion with a request for more data, and if there is no data or if it's not the other part of the surrogate, exit the method as we would be doing if we found the invalid character inside the buffer



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

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Upstreaming a fuzzer for xerces and integration into oss-fuzz

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

> Bhargava Shastry (in CC) and I have written a fuzzer for xerces. This
> fuzzer has already found a bug [0] and we expect it to greatly improve
> the security of xerces.

That isn't a given, as I already said. Finding dozens of bugs that nobody has enough knowledge of the code to fix could leave it in an untenable state. That isn't inherently the wrong outcome, I'm just pointing out that the risk of that does exist.

> We would like to send you a PR that upstreams that fuzzer and then integrate xerces into oss-fuzz. Where can we send
> you a PR for that fuzzer?

I don't know what all that means in terms of what changes to the code or project are involved, but major patches can be submitted to JIRA, as long as they are done with an appropriate license or with an Apache contribution agreement noted.

Whether they could be supported or incorporated just depends on what they are. I know nothing about fuzzing beyond the basic concept, so I don't know whether this is a feasible suggestion given the limited resources.

-- Scott



---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Upstreaming a fuzzer for xerces and integration into oss-fuzz

[Vincent Ulitzsch <vi...@gmail.com>]

Dear Xerces-C Development team,

Bhargava Shastry (in CC) and I have written a fuzzer for xerces. This
fuzzer has already found a bug [0] and we expect it to greatly improve
the security of xerces. We would like to send you a PR that upstreams
that fuzzer and then integrate xerces into oss-fuzz. Where can we send
you a PR for that fuzzer?

Cheers,
Bhargava and Vincent

[0] https://issues.apache.org/jira/browse/XERCESC-2180


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org