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
stack out of bounds read in function iterate_rc4 #147
Comments
|
Thanks. I am able to reproduce this. I will make sure it is fixed before 7.0.0 is released. |
|
I looked through the code, and there are places where I'm passing buffers that are too short. I'll audit all the calls to iterate_rc4 and make sure this is fixed properly. |
|
I've fixed this one and am now going through and making sure qpdf's test suite is clean with address sanitizer. That was the only invalid read. There are several small leaks, though most are not for situations that would occur under ordinary use. Still, they all have to be fixed, and right now, they all look like they'll be easy to fix. |
|
Actually, address sanitizer gets false positives with PointerHolder. valgrind doesn't show any leaks throughout the entire test suite. Address sanitizer doesn't show any errors except leaks, and based on my analysis with a quick script, every direct leak reported by address sanitizer has PointerHolder in its stack trace. There was actually only one exception, which was a missing free() call in the test suite for the C API. It was just test code. I fixed it. The actual library isn't leaking anything. So I think there are no actual memory leaks for any situation exercised by the test suite at this point. That should be most of them. I'm not sure why address sanitizer is reporting leaks with PointerHolder. I've been using that code since around 1997 including on long-running systems. I tried quickly to reproduce it, but my first attempt didn't work. Anyway, thanks for this report. I think we should be in good shape overall with this type of issue. |
|
I'll have a look at the leak. It is very rare that asan produces false positives (and if it does I'd rather like to report them to the asan devs). Other than that: If you're interested here's the code stub I used to test qpdf with libfuzzer: libfuzzer stops with every bug found, so for proper fuzzing it required all the easy to find bugs I reported lately to be fixed first. Also I'd recommend that you add all the malformed PDFs I sent you in the bug reports to the test suite to make sure they're properly archived for future testing. (I also recommend cross-testing with known bug-triggering samples of different PDF implementations, I'll write a blogpost about this soon.) |
|
I have added all but one of the PDFs to the test suite. I didn't add this one because it doesn't actually cause a test failure before the fix, though I should recheck that. You can configure with asan and run the test suite. There are about 10 or 15 failures. Take a look at the leaks. valgrind does not recognize them as leaks. I'll see if I can narrow down to either reproduce a bug to report or figure out why they are actually leaks if they are. I'll reopen until I've done this. Thanks again. |
|
I also didn't add 148. I'll add these and make sure I have a way to see test failures with them. I would like to make qpdf test clean with address sanitizer so I can have it turned on as a routine part of my development. I do test with valgrind as a routine part of my development, and qpdf tests clean with that. |
|
It's possible that there may be leaks with PointerHolder if the object being stored throws an exception on its constructor. This idea just occurred to me as this is a common leak case in C++. I haven't actually checked. I'll give it a look. This is as much a reminder to myself as anything else. |
|
I've had only 10 minutes to look at it, but there is definitely a leak. I will find and fix it. |
|
I found the leak. There were circular references in stream dictionaries and involving stream providers. There was already a mechanism in qpdf to break circular references at the time of destruction, and it was already being used for arrays and dictionaries, but not for streams. It was a very small code change to break cycles for streams and it could be done without breaking binary compatibility. After that small fix, there are only three tests left with leaks. I will look at them now. |
|
qpdf's test suite is now clean with address santizer up through this issue, so I'm closing it again. |
|
This has been assigned CVE-2017-18184 |
The attached file will cause an out of bounds read in qpdf, detectable with address sanitizer.
qpdf-stack-oob-iterate_rc4.zip
The text was updated successfully, but these errors were encountered: