CVE-2021-43620

An issue was discovered in the fruity crate through 0.2.0 for Rust. Security-relevant validation of filename extensions is plausibly affected. Methods of NSString for conversion to a string may return a partial result. Because they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first '\0' byte, which might not be the end of the string.

An issue was discovered in the fruity crate through 0.2.0 for Rust. Security-relevant validation of filename extensions is plausibly affected. Methods of NSString for conversion to a string may return a partial result. Because they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first '\0' byte, which might not be the end of the string.

An issue was discovered in the fruity crate through 0.2.0 for Rust. Security-relevant validation of filename extensions is plausibly affected. Methods of NSString for conversion to a string may return a partial result. Because they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first '\0' byte, which might not be the end of the string.

Methods of NSString for conversion to a string may return a partial result. Since they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first null byte, which might not be the end of the string.

In addition to the vulnerable functions listed for this issue, the implementations of Display, PartialEq, PartialOrd, and ToString for NSString are also affected, since they call those functions.

Since NSString is commonly used as the type for paths by the Foundation framework, null byte truncation might allow for easily bypassing file extension checks. For example, if a file name is provided by a user and validated to have one of a specific set of extensions, with validation taking place before truncation, an attacker can add an accepted extension after a null byte (e.g., file.exe\0.txt). After truncation, the file name used by the application would be file.exe.

It would be better to generate unique names for files, instead of using user-provided names, but not all applications take this approach.

An issue was discovered in the fruity crate through 0.2.0 for Rust. Security-relevant validation of filename extensions is plausibly affected. Methods of NSString for conversion to a string may return a partial result. Because they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first '\0' byte, which might not be the end of the string.

Methods of NSString for conversion to a string may return a partial result. Since they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first null byte, which might not be the end of the string.

In addition to the vulnerable functions listed for this issue, the implementations of Display, PartialEq, PartialOrd, and ToString for NSString are also affected, since they call those functions.

Since NSString is commonly used as the type for paths by the Foundation framework, null byte truncation might allow for easily bypassing file extension checks. For example, if a file name is provided by a user and validated to have one of a specific set of extensions, with validation taking place before truncation, an attacker can add an accepted extension after a null byte (e.g., file.exe\0.txt). After truncation, the file name used by the application would be file.exe.

It would be better to generate unique names for files, instead of using user-provided names, but not all applications take this approach.

Methods of NSString for conversion to a string may return a partial result. Since they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first null byte, which might not be the end of the string.

In addition to the vulnerable functions listed for this issue, the implementations of Display, PartialEq, PartialOrd, and ToString for NSString are also affected, since they call those functions.

Impact

Since NSString is commonly used as the type for paths by the Foundation framework, null byte truncation might allow for easily bypassing file extension checks. For example, if a file name is provided by a user and validated to have one of a specific set of extensions, with validation taking place before truncation, an attacker can add an accepted extension after a null byte (e.g., file.exe\0.txt). After truncation, the file name used by the application would be file.exe.

It would be better to generate unique names for files, instead of using user-provided names, but not all applications take this approach.

Example:

let string = NSString::from_str("null\0byte");
println!("{}", string);

That example only prints the string "null".