Don't let malformed set_parameters requests crash the node - #3256
Don't let malformed set_parameters requests crash the node#3256baszalmstra wants to merge 1 commit into
Conversation
The set_parameters and set_parameters_atomically service handlers only caught ParameterNotDeclaredException. A request carrying a parameter with an empty name (InvalidParametersException) or an unknown value type (UnknownTypeError, thrown by Parameter::from_parameter_msg) let the exception escape the service callback, unwind through the executor's spin(), and terminate the node -- an unauthenticated remote DoS on any node exposing the default parameter services. Broaden both handlers to catch std::exception and return an unsuccessful SetParametersResult instead. In the atomic handler, move the from_parameter_msg conversion inside the try so an unknown type raised during conversion is handled too. Adds regression tests covering empty name (typed client) and unknown type (raw client) for both services. Signed-off-by: Bas Zalmstra <4995967+baszalmstra@users.noreply.github.com>
0042af5 to
1434554
Compare
| result = node_params->set_parameters_atomically( | ||
| {rclcpp::Parameter::from_parameter_msg(p)}); | ||
| } catch (const rclcpp::exceptions::ParameterNotDeclaredException & ex) { | ||
| } catch (const std::exception & ex) { |
There was a problem hiding this comment.
nit: could scope this to just a handful of relevant exceptions
There was a problem hiding this comment.
but then as soon as a new exception is added you can introduce the same crash. What does scoping add here?
There was a problem hiding this comment.
Catchalls are considered back practice as you might also catch exceptions that were not meant to be catched.
You can also give better error messages depending on the type of exception you are catching...
There was a problem hiding this comment.
Given that backporting is desirable, what is the best type to use in this case? std::runtime_error?
There was a problem hiding this comment.
Catchalls are considered back practice as you might also catch exceptions that were not meant to be catched. You can also give better error messages depending on the type of exception you are catching...
Totally agreed but arguably completely missed exceptions also bad practice. I think catching broadly here fixes the current issue but to properly fix this with best practices, all throws in this repo should be re-evalued to be sure no generic exceptions are being thrown. Obviously this was already started from humble > rolling with that TODO I linked fixed, just this would be another case. I suppose the backport to humble for this exact issue could include fixing that generic throw. I will leave it to the folks implementing but that's my $0.02.
|
Pulls: #3256
|
4 participants
The default parameter services crash the whole node on a malformed
set_parametersrequest. Both handlers only catchParameterNotDeclaredException, but an empty name (InvalidParametersException) or an unknown value type (UnknownTypeErrorfromfrom_parameter_msg) escapes the callback andspin(), taking the node down. With no access control by default, any peer on the graph can trigger it.Both handlers now catch
std::exceptionand return an unsuccessful result. I also moved thefrom_parameter_msgconversion in the atomic handler inside thetry, which the unknown-type case there wasn't covered by before.Testing
Added regression tests for both services (empty name via the typed client, unknown type via a raw client). I couldn't build Rolling locally, so I'd like CI to confirm; the crash itself reproduces with a single
ros2 service callto/<node>/set_parametersusing{name: ''}.