this post was submitted on 11 Apr 2024
89 points (87.4% liked)

Technology

59374 readers
3392 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 20 points 7 months ago (12 children)

"The Rust standard library did not properly escape arguments when invoking batch files (with the bat and cmd extensions) on Windows using the Command API,"

If the issue is caused by rust not escaping arguments, and fixed by rust properly escaping arguments, how is it not a rust issue?

[–] [email protected] 12 points 7 months ago (2 children)

If the issue exists in the standard library of every language that provides this capability and Rust's standard library is the first to fix it, how is it a Rust issue?

It would be more accurate to say that it's an issue in almost every language EXCEPT Rust at this point.

The only reason it isn't being called a C or C++ issue is because their standard libraries don't even attempt to offer this capability. But you can bet that all sorts of C/C++ libraries that do offer this, like Qt, will also be having this issue.

[–] [email protected] 3 points 7 months ago* (last edited 7 months ago) (1 children)

Rust has an API they provide which allows for calling batch files. This API has a flaw. The rust team acknowledged, and fixed the flaw.

If you provide an API it should be safe to use. If you don’t provide an API (C/C++) then its up to the programmer to implement it themselves. If that implementation has an issue in how it parses command line args, you would fault the developer of the parsing functionality for not escaping correctly. Thus the developers of the rust api which handles parsing command line arguments has a fault in its implementation.

ed. quick additional example. SQL injection can still be written today; if you just take arbitrary user input and execute it on a db, you open yourself up to exploitation. DB engines provide ways to parameterise queries to prevent this.

If the parameterisation routine allowed for sql injection exploits because it didn’t handle the inputs correctly, who would be at fault?

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2024-24576

The `Command::arg` and `Command::args` APIs state in their documentation that the arguments will be passed to the spawned process as-is, regardless of the content of the arguments, and will not be evaluated by a shell. This means it should be safe to pass untrusted input as an argument.

It goes onto discuss how this is more complex to do in windows, but the rust team chose to implement this, and as a consequence this implementation has an issue.

That forces the standard library to implement custom escaping for arguments passed to batch files. Unfortunately it was reported that our escaping logic was not thorough enough, and it was possible to pass malicious arguments that would result in arbitrary shell execution.

[–] [email protected] 6 points 7 months ago* (last edited 7 months ago)

The entire problem with cmd.exe was not known and so obviously not documented when the Rust standard library developers were implementing the API, and the same goes for the standard library developers of every other language. Rust was among the first to fix this problem in their API, with many other languages opting to just document the issues instead of actually protecting users from it.

To take all this information and distill it down to trumpeting "Rust has a CVSS level 10 security vulnerability!!" without context is stupidity at best and maliciously disingenuous at worst.

Nitpicking whether the statement can be construed as true within a certain framing just demonstrates malicious intent when the reality is that users of Go, Python, and Java, whose standard libraries have taken a position of Won't Fix, are in a FAR more dangerous position than Rust users who are actually in the safest position of anyone in any language ecosystem besides perhaps Haskell.

load more comments (9 replies)