vulnarable code
https://github.com/rooch-network/rooch/blob/main/crates/rooch-open-rpc/src/lib.rs
Summary
The lib.rs file contains a critical vulnerability where the assert_eq! macro is used in production code within the add_examples method. This macro is intended for debugging and testing purposes, and its use in production can lead to application crashes if the assertion fails. This issue poses a significant risk of denial of service, as it can cause the application to terminate unexpectedly when encountering mismatched parameters.
Vulnerable Code.
The vulnerability is present in the add_examples method, specifically in the following line:
assert_eq!(
param_names, example_param_names,
"Provided example parameters don't match the function parameters."
);
Description
Issue
The assert_eq! macro is used to compare two vectors: param_names and example_param_names. If these vectors do not match, the macro will cause the program to panic, leading to a crash. This behavior is inappropriate for production environments, where robustness and error resilience are crucial. Assertions are typically used during development and testing to catch bugs early, but they should be replaced with proper error handling in production code.
Impact
Denial of Service: The use of assert_eq! can lead to a denial of service if the application crashes due to mismatched parameters. This can disrupt service availability and negatively impact user experience.
Lack of Error Handling: The assertion does not provide a mechanism to recover from or handle the error gracefully, leading to potential data loss or incomplete operations.
Inconsistent Behavior: Assertions are typically disabled in release builds, which can lead to inconsistent behavior between development and production environments. This means that issues caught by assertions in development may not be detected in production, leading to undiagnosed failures.
Severity Level: Critical
Justification: The potential for application crashes and service disruption makes this issue a high-severity vulnerability. Proper error handling is essential to maintain service availability and reliability.
Attack Scenario.
An attacker or user could exploit this vulnerability by providing input that causes the parameter names to mismatch. This could be done intentionally or accidentally, leading to a crash and potential denial of service.
Steps to Reproduce.
Setup: Ensure the application is running in a production environment with assertions enabled.
Trigger: Provide input that results in mismatched parameter names in the add_examples method. This could be achieved by supplying an example_provider with parameters that do not align with the method's expected parameters.
Observe: The application will panic and crash, demonstrating the denial of service.
Proof of Concept (PoC)
fn main() {
let mut project = Project::new(
"1.0.0",
"Example Project",
"An example project to demonstrate the issue.",
"John Doe",
"https://example.com",
"[email protected]",
"MIT",
"https://opensource.org/licenses/MIT",
);
let example_provider = BTreeMap::from([
("example_method".to_string(), vec![ExamplePairing::new(
"example",
vec![("param1", Value::String("value1".to_string()))],
Value::String("result".to_string()),
)]),
]);
project.add_examples(example_provider);
}
In this PoC, if the example_method in example_provider has parameters that do not match the method's expected parameters, the assert_eq! will trigger a panic, causing the application to crash.
Recommendations.
Replace assert_eq!: Use proper error handling instead of assert_eq!. For example, return a Result or log a warning if the parameters do not match.
Fixed Code.
To address the issue, we should replace the assert_eq! macro with proper error handling. Instead of causing the program to panic, we can log a warning or return an error if the parameters do not match. Here's a revised version of the add_examples method with improved error handling:
impl Project {
pub fn add_examples(&mut self, mut example_provider: BTreeMap<String, Vec>) {
for method in &mut self.methods {
if let Occupied(entry) = example_provider.entry(method.name.clone()) {
let examples = entry.remove();
let param_names = method
.params
.iter()
.map(|p| p.name.clone())
.collect::<Vec<_>>();
// Check if example's parameters are correct.
for example in examples.iter() {
let example_param_names = example
.params
.iter()
.map(|param| param.name.clone())
.collect::<Vec<_>>();
if param_names != example_param_names {
eprintln!(
"Warning: Provided example parameters don't match the function parameters for method: {}",
method.name
);
continue; // Skip this example if parameters don't match
}
}
method.examples = examples;
} else {
println!("No example found for method: {}", method.name);
}
}
}
}
Explanation of Fixes.
Error Handling:
Instead of using assert_eq!, we compare param_names and example_param_names using an if statement. If they do not match, we log a warning using eprintln! and skip the mismatched example.
vulnarable code
https://github.com/rooch-network/rooch/blob/main/crates/rooch-open-rpc/src/lib.rs
Summary
The lib.rs file contains a critical vulnerability where the assert_eq! macro is used in production code within the add_examples method. This macro is intended for debugging and testing purposes, and its use in production can lead to application crashes if the assertion fails. This issue poses a significant risk of denial of service, as it can cause the application to terminate unexpectedly when encountering mismatched parameters.
Vulnerable Code.
The vulnerability is present in the add_examples method, specifically in the following line:
assert_eq!(
param_names, example_param_names,
"Provided example parameters don't match the function parameters."
);
Description
Issue
The assert_eq! macro is used to compare two vectors: param_names and example_param_names. If these vectors do not match, the macro will cause the program to panic, leading to a crash. This behavior is inappropriate for production environments, where robustness and error resilience are crucial. Assertions are typically used during development and testing to catch bugs early, but they should be replaced with proper error handling in production code.
Impact
Denial of Service: The use of assert_eq! can lead to a denial of service if the application crashes due to mismatched parameters. This can disrupt service availability and negatively impact user experience.
Lack of Error Handling: The assertion does not provide a mechanism to recover from or handle the error gracefully, leading to potential data loss or incomplete operations.
Inconsistent Behavior: Assertions are typically disabled in release builds, which can lead to inconsistent behavior between development and production environments. This means that issues caught by assertions in development may not be detected in production, leading to undiagnosed failures.
Severity Level: Critical
Justification: The potential for application crashes and service disruption makes this issue a high-severity vulnerability. Proper error handling is essential to maintain service availability and reliability.
Attack Scenario.
An attacker or user could exploit this vulnerability by providing input that causes the parameter names to mismatch. This could be done intentionally or accidentally, leading to a crash and potential denial of service.
Steps to Reproduce.
Setup: Ensure the application is running in a production environment with assertions enabled.
Trigger: Provide input that results in mismatched parameter names in the add_examples method. This could be achieved by supplying an example_provider with parameters that do not align with the method's expected parameters.
Observe: The application will panic and crash, demonstrating the denial of service.
Proof of Concept (PoC)
fn main() {
let mut project = Project::new(
"1.0.0",
"Example Project",
"An example project to demonstrate the issue.",
"John Doe",
"https://example.com",
"[email protected]",
"MIT",
"https://opensource.org/licenses/MIT",
);
}
In this PoC, if the example_method in example_provider has parameters that do not match the method's expected parameters, the assert_eq! will trigger a panic, causing the application to crash.
Recommendations.
Replace assert_eq!: Use proper error handling instead of assert_eq!. For example, return a Result or log a warning if the parameters do not match.
Fixed Code.
To address the issue, we should replace the assert_eq! macro with proper error handling. Instead of causing the program to panic, we can log a warning or return an error if the parameters do not match. Here's a revised version of the add_examples method with improved error handling:
impl Project {
pub fn add_examples(&mut self, mut example_provider: BTreeMap<String, Vec>) {
for method in &mut self.methods {
if let Occupied(entry) = example_provider.entry(method.name.clone()) {
let examples = entry.remove();
let param_names = method
.params
.iter()
.map(|p| p.name.clone())
.collect::<Vec<_>>();
}
Explanation of Fixes.
Error Handling:
Instead of using assert_eq!, we compare param_names and example_param_names using an if statement. If they do not match, we log a warning using eprintln! and skip the mismatched example.