GNOME.org
 

Re: [xml] Research about vulnerabilities

You are not wrong -- I just put this issue into the unlikely to happen category.  If it was higher level and 
easy to do I might have another opinion.  This is like getting past the Dobermans :-)

I do have a funny story.  I had a customer with a simple firewall (basically IP rules) that cost a few 
hundred dollars.  They were never hacked in over a decade.  But, someone told them they had a theoretical 
security problem (e.g. in some insane case someone might hack them -- although they only sell T-Shirts so 
what is the point?).  

So they bought the latest and greatest 30k Cisco Firewall.  And were promptly and successfully hacked that 
week.  It seems that this new Cisco was a challenge that interested the hacker, whereas grinding through IP 
spoofing and passwords is just dull.

Luckily he was not malicious -- he just made the log in screens display "I was here" before executing the 
application and it was easy to remove.

Security is a funny issue.

E

-----Original Message-----
From: Aleksey Sanin [mailto:aleksey aleksey com] 
Sent: Tuesday, October 29, 2019 3:41 PM
To: Eric Eberhard <flash vicsmba com>; 'Webb Scales' <webb ursasecure com>; 'Raphael de Carvalho Muniz' 
<raphael copin ufcg edu br>
Cc: xml gnome org
Subject: Re: [xml] 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:xml-bounces gnome org] *On Behalf Of *Webb Scales
*Sent:* Tuesday, October 29, 2019 7:18 AM
*To:* Raphael de Carvalho Muniz <raphael copin ufcg edu br>
*Cc:* xml gnome org
*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/9acef289285008f81b4b66b4880baf
600773cf67

    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: raphaeldecm gmail com <mailto:raphaeldecm gmail com> /
    raphael copin ufcg edu br <mailto:raphael copin ufcg edu br>

    Fone: +55 84 98801 1218



    _______________________________________________

    xml mailing list, project pagehttp://xmlsoft.org/

    xml gnome org  <mailto:xml gnome org>

    https://mail.gnome.org/mailman/listinfo/xml

--

Webb Scales
Principal Software Architect
603-673-2306
www.ursasecure.com <https://www.ursasecure.com> webb ursasecure com 
<mailto:webb ursasecure com>


_______________________________________________
xml mailing list, project page  http://xmlsoft.org/ xml gnome org 
https://mail.gnome.org/mailman/listinfo/xml
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]