ezXML Activity
Status: Beta
Brought to you by:
voisine
Activity for ezXML
-
Layne posted a comment on ticket #29
is this same algorithm in delta executor?
-
y4mrnie created ticket #29
Out-of-bounds read in ezxml_decode() leading to heap corruption
-
Egbert Eich posted a comment on ticket #20
For me, this issue is resolved by the fix for bug 26. Check my comment there.
-
For me, this issue is resolved by the fix for bug 26. Check my comment there.
-
The proposed patch also resolves the issues reported in bug 16 and bug 20. This exposes a general weakness of this parser: it assumes that the XML passed is well formed to a certain extent and doesn't have thorough checking. strcspn() (and strspn()) are used in many more places throughout the code and exhibit the same problem: if the requested condition cannot be met anywhere in the string, these function stop at the /0 terminating the string. This condition is never checked and acted upon as this...
-
The proposed patch addresses the issue demonstrated by the attached test case. All said in this comment applies.
-
The proposed patch addresses the issue demonstrated by the attached test case. All said in this comment applies.
-
The proposed patch addresses the demonstrated by the attached test case. All said in this comment applies.
-
This bug, just like bug 22 and bug 23 takes advantage of the fact, that ezxml assumes that (re)allocation of memory will always succeed. There are many more cases where this can be exploited. It seems that this project was chosen as a test case for a tool written for the purpose of testing whether software handles (re)allocation failures properly. The issue demonstrated by the attached test case can be mitigated by the attached patch. This begs the question how useful this patch is as it only addresses...
-
This segfault arises by not properly verifying if there is still data left to read after normalizing line endings. The proposed patch addresses this.
-
The issue is due to bogus input data where an entity reference does not end in a ';'. The proposed patch addresses this.
-
The proposed patch is incorrect: the memove() destination (s + c) does not have to contain valid data. The calculation performed seems to ensure that the move will fit into the bounds of the memory (re)allocated. The patch causes issues with perfectly valid XML. Also, performing an exit(-1) when the test condition fails would be the wrong way to handle an error condition anyway. In my tests the issue demonstrated by the test case was resolved by the fix for CVE-2019-20006 in bug 15.
-
This issue is resolved by the patch propose in bug 15.
-
The error occurs due to a bogus character reference that cannot be encoded as UTF-8. The proposed patch checks whether the character can be encoded in 36 bits (the maximum value that can be encoded using the UTF-8 encoding - note: the standard only uses 21 bits). This fix also resolves CVE-2019-20202 (bug 17) as well as CVE-2021-31598 (bug 28). Note: The solution as proposed in bug 28 is incorrect. It causes valid XML data to be rejected as well.
-
Attached a proposed fix: Check if ezxml_str2utf8() has succeeded with performing a conversion and return with an error if not. This is different for the case that no conversion is required in that 's' remains untouched in that case.
-
rc0r posted a comment on ticket #26
Please do not apply the originally proposed patch CVE-2021-31229-OOBW-000.patch as it calls ezxml_err() with a potentially corrupt t parameter leading to another crash (that does not occur without the patch applied). To avoid this newly introduced issue the offending call to ezxml_err() was changed to not include the potentially corrupt t: --- ezxml.c 2006-06-08 04:33:38.000000000 +0200 +++ ezxml-fixed.c 2021-04-15 15:40:38.054755080 +0200 @@ -320,6 +320,7 @@ { char q, *c, *t, *n = NULL, *v, **ent,...
-
Out-of-bounds write in ezxml_decode() leading to heap corruption
-
Out-of-bounds read/write in ezxml_parse_str() in ezxml.c:586/587
-
Out-of-bounds write in ezxml_internal_dtd()
-
Null pointer dereference in ezxml_internal_dtd()
-
fstark created ticket #24
Out-of-bounds write caused by Integer Overflow in ezxml_parse_str (ezxml.c:481)
-
CVE Reporting created ticket #23
Out-of-bounds write caused by incorrect error handling of malloc in ezxml_new (ezxml.c:750)
-
Out-of-bounds write caused by incorrect error handling of malloc in ezxml_new (ezxml.c:843)
-
Out-of-bounds write caused by incorrect error handling of malloc in ezxml_new (ezxml.c:838)
-
Stack overflow (uncontrolled recursion) - ezxml_ent_ok
-
Heap buffer overread (ezxml_decode:163)
-
NULL pointer defererence (ezxml_decode)
-
Using realloc on not allocated memory block (ezxml_char_content)
-
Additional files for reproduction of this crash.
-
Denial of Service vulnerability (infinite loop) while parsing malicious XML files
-
Using free on not allocated memory block (ezxml_char_content)
-
Heap buffer overread (ezxml_decode)
-
NULL pointer defererence (ezxml_parse_str)
-
Mohsen Pahlevanzadeh posted a comment on ticket #7
I wrote the patch that solve the above problem: patch -p0 < ezxml.patch
-
warning: operation on āsā may be undefined
-
netcat created ticket #2
a parse_str function that frees its argument automatically
-
Ramesh P posted a comment on ticket #12
got the solution, we need to traverse top level node by node instead of taking node...
-
correct you will not find root node. after parsing root pointer might be moved from...
-
please refer "12 ezxml_cut not functioning properly_modified ticket", since this...
-
ezxml_cut not functioning properly_modified
-
ezxml_cut not functioning properly
1
