New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
heap-buffer-overflow Error In tinyxml2.cpp:2286::strlen() #675
Comments
|
then I want to show my example of libfuzzer. |
|
then this is the error information. |
|
the strlen() in tinyxml2.cpp: |
|
This issue has been assigned CVE-2018-11210 |
|
OK,I will close this Issues. |
|
Why was the issue closed? What is the fixing commit? |
|
Re-opening. I don't track all the external bug sites, so it's better to have here. |
|
Although an actual test case would be great. |
|
But that is a bug; strlen() search should be bound by the buffer length. |
|
This one worries me; initial patch here: https://github.com/leethomason/tinyxml2/compare/strlen |
|
Despite some misguided hacking on my part, I'm pretty sure there is no fixing this. I suspect it comes from passing a bad If there is a crash here that isn't an incorrect use of the API, I'd like a test case, else it isn't technically a bug. |
|
@leethomason due to the severity of CVE-2018-11210 can we take your patches from https://github.com/leethomason/tinyxml2/compare/strlen ? |
|
The patches don't fix the issue. If there are correct inputs, I never found a bug. (Or a practical way to defend against bad inputs.) I don't think there's a bug if the 'len' is correctly specified. |
|
Hello,
Would you accept a patch that uses strnlen to read a maximum of 4K bytes when no size is specified for XMLDocument::parse()? The 4K bytes size comes from the fact that it's the default virtual memory page size on GNU/Linux. Of course, when the user wants to read more that a maximum of 4K, she can specify the size she wants. The patch would be this one: dodjiseketeli@665535a |
|
This 4K limitation makes no sense either. What if the user wants to parse a string tail only? Then the substring to parse will not start at page length. |
|
I agree with @Dmitry-Me that the limit doesn't make sense. |
|
I am not trying to prevent the program from crashing in case if bad input.
I am trying to avoid the program from *reading* an undetermined length of
data, just because the *end user* (not the programmer who used tinyxml)
passed unexpected input data: for instance, a small buffer that contains no
zero. In that case tinyxml should stop its execution in a predictable way
and not read data that it should not read. Otherwise it's not just a crash
it's a security issue that can be used for a buffer read overflow attack.
Said otherwise, I think that the parse method should always require a
length and never assume that there is going to be a zero in the input
string. Otherwise it's "easy" for the programmer using tinyxml to misuse it
by calling it with the -1 length argument, thinking "tinyxml will figure
out the length". And yet the end user passing an unexpected buffer (that
is obviously not proper xml) would cause that strlen to read an
unexpectedly long amount of data.
My problem is that I cannot change the API today to avoid the -1 case that
requires the buffer to end with zero. *You* can do that in the future
versions. Would you agree to do that?
So I am proposing a middle ground where programmers using tinyxml still use
the api with the -1 length (for now), but where the amount of unexpected
data read in case the end user providing unexpected input is bounded, if
not very small.
In any case I think we should do something. An unexpected end-user input
should never cause a buffer overflow, IMHO.
Le 19 nov. 2018 02:33, "Lee Thomason" <notifications@github.com> a écrit :
I agree with @Dmitry-Me <https://github.com/Dmitry-Me> that the limit
doesn't make sense.
@dodjiseketeli <https://github.com/dodjiseketeli> this is C++, if you pass
bad inputs, it will crash, like any library in C++. What are you trying to
solve?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#675 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AL6n10Qqn_YKiicQC2sMNRG3pGPobxrqks5uwglAgaJpZM4UAiQp>
.
|
|
@dodjiseketeli This is something unreasonable. A user passing a |
|
Just so I am sure to understand: Do you find it OK that just because the
end-user of a program invokes the program with unexpected data, the program
ends up reading *more* than said data in a undefined manner, (Read buffer
overflow) and thus causes a security issue?
Le lun. 19 nov. 2018 à 12:48, Dmitry-Me <notifications@github.com> a écrit :
… @dodjiseketeli <https://github.com/dodjiseketeli> This is something
unreasonable. A user passing a const char* into a C++ function and
expecting the function to figure out the length is expecting too much. The
contract is clear - either specify the length yourself and ensure that the
data is properly null-terminated. Failing to null-terminate the data is the
same as specifying too much of length - that's just malformed data being
passed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#675 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AL6n1-oMhcLO0iUQ3xea1a97q2tzmsPxks5uwpqcgaJpZM4UAiQp>
.
|
|
Anyway, I don't feel strong about this. I just thought I'd ask you guys if you'd agree to tighten the API a little more. I agree that in principle, the author of the fuzzing input test did mis-use the API. She or he should have forced the fuzzing program to pass in the size of the input buffer. My gut feeling is that the default argument -1 (for the size) makes it a little too easy to mis-use the API, as opposed to forcing the caller to always specify the size, but hey, that is just a design decision and I agree that stricto sensu, the test is failing because of a pre-condition violation. So please do not feel to strong about this either. If you feel like you don't want to change the API in the future, then I am fine with your decision. I just wanted to make sure. Thanks for your time! |
|
It's the same as passing a buffer and a positive length which is "too large". 30 bytes data buffer and |
|
I agree with @leethomason and @Dmitry-Me. The fuzzing test was the buggy "program" that allowed "end user" (libfuzzer in this instance) to cause the buffer to be over read. If instead of the Parse function there would be direct invocation of the strlen function with the otherwise same implementation of the test, would it lead to the CVE being filled for the C standard library? There is this thread about writing fuzzer test for the APIs that require C string in the buffer: libFuzzer: add an option to always null-terminate? The test program should have either use the suggested in this llvm thread aproach to update the buffer to be NULL terminated or call the Parse with 2 parameters. If any change on the tinyxml2 side I might tend to suggest removing optional parameter and instead providing 2 functions Parse(const char* c_string) and Parse(const char* data, size_t size). It would provide the same flexibility but would indicate (more strongly - because the API description is already clear) what is expected when calling the Parse with either one or two parameters. |
|
Just for reference fixed fuzzer tests would look like this: #include "tinyxml2.h"
#include <stdint.h>
extern "C" int LLVMFuzzerTestOneInput(const char *Data, size_t Size)
{
tinyxml2::XMLDocument doc;
doc.Parse(Data, Size);
return doc.ErrorID();
}OR #include "tinyxml2.h"
#include <stdint.h>
#include <string>
extern "C" int LLVMFuzzerTestOneInput(const char *Data, size_t Size)
{
tinyxml2::XMLDocument doc;
std::string data_string(Data, Size);
doc.Parse(data_string.c_str());
return doc.ErrorID();
}On a side note I have submitted request to reject the CVE-2018-11210. |
Hi, has CVE-2018-11210 beed cancelled? I found it still exist in NVD. |
@kurylo, have you received any response from MITRE? |
|
No response from MITRE. |
hello!I use libfuzzer to test XMLDocument::parse().then I meet heap-buffer-overflow Error.I think it is due to tinyxml2.cpp:2286 strlen().because function strlen() lead to heap-buffer-overflow.
The text was updated successfully, but these errors were encountered: