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
Multiple security vulnerabilities in minilzo.c, nffile_inline.c and nfx.c #104
Comments
|
I will take care about that. As I was not informed beforehand I can not provide fixed immediately. |
|
After detailed investigation I fixed nfx.c and nffile_inline.c to exit nfdump properly, when feeded with garbage input. The issues are not to be considered as security related. Potential exploitation does not result in privileged escalation or similar effects. It can only be exploited on the host nfdump is installed. The crashes in minilzo are not yet fixed, as this is a third part library. See also www.oberhumer.com/opensource/lzo/. Maybe @e3prom can check those libraries first and get in contact with the author. |
|
Regarding the heap-based buffer overflow involving minilzo: the buffer can still be written out of bound and it seems to happen in the "redistributed" portion of their code (as it has been pointed out), however the buffer has been previously allocated in the nfdump code through a malloc() call. A similar memory allocation can be found at line 646 of 'bin/nffile.c'. Maybe some checks could be performed to avoid out-of-bound writes, or a bigger buffer could be allocated? I will let the developers figure out what is best in the interests of their users. I don't think theses issues could be trivially exploited, nor that they provide a lever interesting enough for privilege escalations, however if the attacks on the heap are successful and results in code execution, an attacker could "locally" perform lateral movement via a specially crafted file. I think that's enough to worry about. While I disagree with the conclusion of @phaag regarding the security implications of the reported issues, I would like to thanks Peter for the provided fixes. They at least allow nfdump to gracefully exit before invalid memory addresses are accessed. |
|
The issue in minilzo need to be fixed by the author of the minilzo code. He knows best his code. It does not help if nfdump allocates a larger buffer. The bug still exists, can be exploited and simply need more bytes to overrun. While we agree that these issues are easy exploitable, I am also convinced that this not a main threat on a system where nfdump is installed. |
|
This was assigned CVE-2019-1010057. |
|
Fixes have been commit for: |
|
updated minilzo 2.10 and changed to safe lzo decompress |
|
As of 7b26ee9 with regular compilation flow, on my machine the provided inputs such as |
|
I can not confirm: % ./nfreplay -r ghbo_nfx.c:473_1 Can't process block type 0. Skip block. Can't process block type 0. Skip block. PANIC! - Verify map id 59647: ERROR: element id 768 out of range [49]! % echo $? nfreplay ends cleanly with a processing error. No segfault with current repo code! |
|
Hi, I tried to use and I used gdb to debug, still use gdb ./bin/nfreplay Insert Extension Map: Extension info in slot 59647 already exists: 0x93824994460096 Insert Extension Map: Extension info in slot 59647 already exists: 0x93824994459728 Can't process block type 0. Skip block. Can't process block type 0. Skip block. Insert Extension Map: Breakpoint 1, PrintExtensionMap (map=map@entry=0x7ffff6b7301c) at nfx.c:473 gdb$ n gdb$ n Breakpoint 1, PrintExtensionMap (map=map@entry=0x7ffff6b7301c) at nfx.c:473 gdb$ n Breakpoint 1, PrintExtensionMap (map=map@entry=0x7ffff6b7301c) at nfx.c:473 .. Breakpoint 1, PrintExtensionMap (map=map@entry=0x7ffff6b7301c) at nfx.c:473 Program received signal SIGSEGV, Segmentation fault. From above debug process, I speculate @phaag 's run environment has mechanism to handle the array out of bound exception, thus throw a 'PANIC!' and stop the program. If the index is too large for the memory(as the above id, 0x206e), it will cause a segmentation fault. |
|
There is nothing special on my run environment. The panic error message is generated by nfx.c function FixExtensionMap, which does a sanity check on the map and exists if anything is not correct. In order to be consistent with nfdump.c, I inserted the early generic record size check also into the other nfdump binaries. This already blocks |
Summary
nfdump (commit 27f62a5) is affected by multiple security vulnerabilities in:
For obvious security reasons, I voluntarily omitted to mention the affected lines of codes, so the developers should have enough time to fix these issues. The program's author has been contacted with the necessary technical details.
Description
By crafting special malformed nfcapd input files, an attacker can crash the program by forcing it to dereference invalid memory addresses, and may overflow heap chunks to get arbitrary code execution.
Feel free to contact me if more information are necessary.
The text was updated successfully, but these errors were encountered: