Re: [xml] Research about vulnerabilities

[Eric Eberhard]

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:alek...@aleksey.com] 
Sent: Tuesday, October 29, 2019 3:41 PM
To: Eric Eberhard ; 'Webb Scales' ; 
'Raphael de Carvalho Muniz' 
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-boun...@gnome.org] *On Behalf Of *Webb Scales
> *Sent:* Tuesday, October 29, 2019 7:18 AM
> *To:* Raphael de Carvalho Muniz 
> *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 

Re: [xml] Research about vulnerabilities

[Aleksey Sanin]

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-boun...@gnome.org] *On Behalf Of *Webb Scales
*Sent:* Tuesday, October 29, 2019 7:18 AM
*To:* Raphael de Carvalho Muniz 
*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/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: 

Re: [xml] Research about vulnerabilities

[Eric Eberhard]

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-boun...@gnome.org] On Behalf Of Webb Scales
Sent: Tuesday, October 29, 2019 7:18 AM
To: Raphael de Carvalho Muniz 
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/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: raphaeld...@gmail.com   / 
raph...@copin.ufcg.edu.br  

Fone: +55 84 98801 1218





___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org  
https://mail.gnome.org/mailman/listinfo/xml

 

-- 

Webb Scales 
Principal Software Architect 
603-673-2306 
www.ursasecure.com   
w...@ursasecure.com   



___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml

Re: [xml] Research about vulnerabilities

[Webb Scales]

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: raphaeld...@gmail.com  / 
raph...@copin.ufcg.edu.br 

Fone: +55 84 98801 1218

___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml


--

Webb Scales
Principal Software Architect
603-673-2306
www.ursasecure.com 
w...@ursasecure.com 

___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml

Re: [xml] Research about vulnerabilities

[Nick Wellnhofer]

On 29/10/2019 14:30, Raphael de Carvalho Muniz wrote:
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).


More specifically python/libxml.c which is part of the Python bindings.

I believe 
that this commit presents a weakness that, If format strings can be influenced 
by an attacker, they can be exploited.


libxml_buildMessage is only called from error handlers which should never 
receive format strings from an external source.


You can't just pick a function that calls printf with a variable format string 
and assume that it's vulnerable. It depends on how the function is called and 
which format strings it receives.


Nick
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml

[xml] Research about vulnerabilities

[Raphael de Carvalho Muniz]

  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: raphaeld...@gmail.com / raph...@copin.ufcg.edu.br
Fone: +55 84 98801 1218
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml