RE: Steemd 0.20.6 bug - memory exhaustion when parsing malicious hello_message
Hi @fuzz-ai, welcome to Steem and great to see you contributing to Utopian! Amazing work with AFL to find this issue. I especially like the linked post where you provide more detailed information on how the fuzzing was done. Great to see you reached out to Steemit privately and published this information only after the bug was fixed by Steemit.
You've identified this issue with the hello message, which is typically sent by witness nodes. Could have user operations triggered a similar issue? I'm thinking of custom_json ops with only arrays of arrays of arrays... as the payload (but limited at 4k per transaction, not 2MB)? This should go through the same logic, shouldn't it?
Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.
To view those questions and the relevant answers related to your post, click here.
Need help? Write a ticket on https://support.utopian.io/.
Chat with us on Discord.
[utopian-moderator]
I thought that custom_json ops didn't use the C++ variant type, but just a JSON string. There is a bug in the JSON parser, but not an exploitable one in the way it is used. But I haven't looked at that in detail, it would certainly be good to understand what sort of things somebody could insert using a custom_json operation.
You're right about the custom_json not using the varint type, this is indeed just a string. The
witness_set_properties.propsfield might be a candidate, though? Looking forward to more fuzzing results from you :)Thinking about this a little more, I was worried you might have been right about nested JSON objects, and that deeply-nested JSON objects in the JSON-RPC API could still cause the thread to die because of stack overflow.
The parser does have a check that you can't nest JSON objects or arrays more than 100 deep: https://github.com/steemit/steem/blob/9e83f66c85a2c76bef1a07cef7dd302d2c4be572/libraries/fc/src/io/json.cpp#L442
But I'm not sure it's effective, I can think of one way it might be fooled.
Thank you for your review, @crokkon! Keep up the good work!