Re: Research about vulnerabilities

People do attack XML parsing (as well as any other input),
the encryption on the wire doesn't stop a malicious client
from crafting special input and sending it to the server.

I did a cursory look at the code and I believe Nick is correct
that the function in question is never called with a user-input
for the format string. Thus, I don't believe this particular
issue is really a vulnerability.

LibXML2 was tested by Coverity (last test from 2018 build):

https://scan.coverity.com/projects/libxml2

It might make sense to upload a fresh build and see what Coverity
finds. Looks like in 2018 it found a few issues (though hard to
say how real are those without deeper look).

Best,

Aleksey

On 10/29/19 3:05 PM, Eric Eberhard wrote:
> I agree.  I also don’t think people attack XML parsing.  The 
> sending/receiving can be done encrypted.  This seems a lot like a 
> theoretical problem, not a real-world problem.
> 
> My feelings are that protecting against all possible attacks is not 
> possible.  Or stupid programming.
> 
> Take the physical world.  Maybe you just lock your house.  Or maybe you 
> have an alarm system.  Or maybe locked gates.  Maybe patrolled by 
> Dobermans.  Maybe patrolled by armed guards with machine guns.
> 
> My point is – people can pick locks.  Defeat alarms.  Scale gates.  Kill 
> dogs.  Kill guards.  It can get silly.  Maybe one should make an 
> underground compound with fingerprint and retina scans as well.
> 
> You have to stop it someplace.  If this was CIA or FBI or something I’d 
> go along with the complaint.  But most of us use this in a business 
> setting and we apply *reasonable *security measures, not insanely 
> overkill measures.
> 
> Eric
> 
> *From:*xml [mailto:[email protected]] *On Behalf Of *Webb Scales
> *Sent:* Tuesday, October 29, 2019 7:18 AM
> *To:* Raphael de Carvalho Muniz <[email protected]>
> *Cc:* [email protected]
> *Subject:* Re: [xml] Research about vulnerabilities
> 
> Raphael,
> 
> First, the disclaimers:  I'm not an XML maintainer or even a 
> contributor; and, I've only given this a cursory glance.
> 
> Here are my reactions.
> 
> First, the routine in question is declared to be of module static 
> scope.  I believe that this means that any exploitation of it would have 
> to be indirect, coming from within LibXML2.
> 
> Second, the code appears to properly protect against buffer overflow, so 
> the only exploitation that I see is the one that you illustrated, 
> leaking memory position information.  However, the function in question 
> does nothing that its caller could not do -- it calls malloc() and (in 
> the example you provided) returns the address of what might be a stack 
> location (although, really, it could be any random junk, I think).  By 
> definition, the caller already knows the stack location, and the caller 
> certainly has its own access to malloc().
> 
> So, I for one, don't see any weakness exposed by the code which you 
> provided.  This doesn't mean that there is no weakness in LibXML2, but, 
> to find it if it's there, you'll have to interrogate the code which 
> calls this routine.
> 
> 
>                  Webb
> 
> 
> On 10/29/19 9:30 AM, Raphael de Carvalho Muniz wrote:
> 
>       Dear libxml2 owners,
> 
>     I am performing research about weaknesses in C open source programs.
>     As part of my research, I am studying weaknesses that may be
>     vulnerabilities in the Libxml2 project.
> 
>     I found in the commit history of Libxml2 (commit 9acef28) the
>     presence of the following code snippet in the libxml.c file (Lines
>     1,597 - 1,612). I believe that this commit presents a weakness that,
>     If format strings can be influenced by an attacker, they can be
>     exploited. This weakness is characterized by CWE Project as CWE-134:
>     Use of Externally-Controlled Format String. When an attacker can
>     modify an externally-controlled format string, this can lead to
>     buffer overflows, denial of service, or data representation problems.
> 
>     Moreover, I performed a software testing strategy with respect to
>     confirm the vulnerability. We provide as input to the char *msg the
>     value "%xtest" and the function libxml_buildMessage return the
>     value"fc0c748ex", exposing a memory position.
> 
>     This is the GitHub link to the commit:
> 
>     https://github.com/GNOME/libxml2/commit/9acef289285008f81b4b66b4880baf600773cf67
> 
>     Code snippet:
> 
>     static char *
>     libxml_buildMessage(const char *msg, va_list ap){
>        int chars;
>        char *str;
> 
>        str = (char *) xmlMalloc(1000);
>        if (str == NULL)
>          return NULL;
> 
>        chars = vsnprintf(str, 999, msg, ap);
>        if (chars >= 998)
>          str[999] = 0;
> 
>        return str;
>     }
> 
> 
>     Looking at this code snippet, I am wondering if you could answer the
>     following brief questions:
>     We understand that this code has a weakness. Do you agree?
>     How do you detect weaknesses? Do you use any tool to detect them?
>     We would be very grateful if you say to us if you agree, and if you
>     are going to fix it.
> 
>     -- 
> 
>     Raphael de Carvalho Muniz, M.Sc.
> 
>     Lattes: http://lattes.cnpq.br/1454914002384966
>     e-Mail: [email protected] <mailto:[email protected]> /
>     [email protected] <mailto:[email protected]>
> 
>     Fone: +55 84 98801 1218
> 
> 
> 
>     _______________________________________________
> 
>     xml mailing list, project pagehttp://xmlsoft.org/
> 
>     [email protected]  <mailto:[email protected]>
> 
>     https://mail.gnome.org/mailman/listinfo/xml
> 
> -- 
> 
> Webb Scales
> Principal Software Architect
> 603-673-2306
> www.ursasecure.com <https://www.ursasecure.com>
> [email protected] <mailto:[email protected]>
> 
> 
> _______________________________________________
> xml mailing list, project page  http://xmlsoft.org/
> [email protected]
> https://mail.gnome.org/mailman/listinfo/xml
> 
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
[email protected]
https://mail.gnome.org/mailman/listinfo/xml