this post was submitted on 09 Apr 2024
133 points (94.6% liked)
Programming
17391 readers
145 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Also, the reason this is a CVE is because Rust itself guarantees that calling commands doesn't evaluate shell stuff (but this breaks that guarantee). As far as I know C/C++ makes no such guarantee whatsoever.
Our bug is their status quo.
C++ has no guarantees built into stdlib but frameworks like Qt provide safe access - the ecosystem has options. C++ itself is quite a simple language, most of the power comes out of toolsets and frameworks built on top of it.
What are the chances Qt is affected by this issue too?
Vanishingly small. In Qt that'd have to be an issue in QStringList IIRC.
That’s certainly not the case, because that’s like saying the issue is with Rust’s string slices. I think you may have missed the part of the issue where batch scripts require additional escaping due to Windows’ command handling. It’s a ridiculous design of the Windows API system, which is also why (almost?) every language they tested was vulnerable, so it would be actually very outstanding if Qt prevented this.
For C++ devs not using Qt it’s just another footgun they’ll likely keep introducing security issues with as well. But if you do use Qt, I think it’s better to double-check since it may also require a patch.