Hi,
I did a quick fuzzing test of the command line tools coming with nettle.
echo "]"|sexp-conv will cause an abort call and echo "{MiM}"|sexp-conv causes an assert: sexp-conv: /var/tmp/portage/dev-libs/nettle-3.2/work/nettle-3.2/tools/input.c:128: sexp_input_start_coding: Assertion `!input->coding' failed.
Not sure how relevant these tools are, but usually abort/assert calls are debugging tools for situations in a software that should never happen on normal operations.
Hanno Böck hanno@hboeck.de writes:
I did a quick fuzzing test of the command line tools coming with nettle.
echo "]"|sexp-conv will cause an abort call and echo "{MiM}"|sexp-conv causes an assert:
Thanks for the bug report. I'm investigating.
usually abort/assert calls are debugging tools for situations in a software that should never happen on normal operations.
That's my intention too. For invalid invalid input data, the program should terminate with a more-or-less friendly error message, not crash. Assertion failures are always bugs.
Regards, /Niels
Hanno Böck hanno@hboeck.de writes:
I did a quick fuzzing test of the command line tools coming with nettle.
Fixes checked in now.
echo "{MiM}"|sexp-conv causes an assert: sexp-conv: /var/tmp/portage/dev-libs/nettle-3.2/work/nettle-3.2/tools/input.c:128: sexp_input_start_coding: Assertion `!input->coding' failed.
This one was interesting. {} indicates "transport syntax", which is canonical syntax wrapped in base64 encoding. MiM is not a valid base64 encoding, but it nevertheless decodes to the two characters "2#" before the truncation is detected. And "2#" is the start of hex string in advanced syntax, but invalid in canonical syntax.
The code used to improperly accept it as a hex string and configure the input for base16 decoding. And then triggered an assertion failure because the code wasn't prepared to handle several layers of decoding, with base16 inside base64.
This case (and other uses of advanced syntax in this context) should now be rejected with an error message.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se