this post was submitted on 09 Apr 2024
133 points (94.6% liked)

Programming

17313 readers
150 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
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
133
Critical Rust flaw enables Windows command injection attacks (www.bleepingcomputer.com)
submitted 6 months ago by 0x0@programming.dev to c/programming@programming.dev
35 comments fedilink hide all child comments
top 35 comments
sorted by: hot top controversial new old
[–] FizzyOrange@programming.dev 56 points 6 months ago (2 children)

Seems a bit clickbaity to me. It's a flaw in Windows/cmd.exe, not Rust. Rust is just called out because it tries to emulated proper argument passing on Windows (and didn't get it perfectly right). All languages are affected by this but most of them just throw their hands in the air and say "you're on your own":

  • Erlang (documentation update)
  • Go (documentation update)
  • Haskell (patch available)
  • Java (won’t fix)
  • Node.js (patch will be available)
  • PHP (patch will be available)
  • Python (documentation update)
  • Ruby (documentation update)

It's also extremely unlikely that you'd be running a bat script with untrusted arguments on Windows.

[–] porgamrer@programming.dev 29 points 6 months ago

I mean, let's be real, Rust is really called out because it causes high drama between C devs and Rust advocates, which drives engagement.

It's probably all kicking off in about 10 different comment sections right now

[–] Giooschi@lemmy.world 10 points 6 months ago

It's also extremely unlikely that you'd be running a bat script with untrusted arguments on Windows.

It happens in yt-dl, which is where this was first reported https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-hjq6-52gw-2g7p

[–] colonial@lemmy.world 38 points 6 months ago (1 children)

Oof. Looks like this affected some other languages as well - somebody at Microsoft needs to up their documentation game, methinks.

[–] UnfortunateShort@lemmy.world 4 points 6 months ago (1 children)

This hurts my brain. We have nice shell languages now, can we just lock down and phase out the rest please? I don't even want to know the hidden cost of running Bash or sh scripts tbh. Both are languages where you can do something not right enough, because everything just has to be obnoxious.

[–] Gobbel2000@programming.dev 3 points 6 months ago (4 children)

I won't argue with you that bash is janky and easily insecure, but what shell language do you think should replace bash?

[–] BatmanAoD@programming.dev 1 points 6 months ago

The only semi-realistic way I can see Bash becoming mostly obsolete is with a tool that provides automated migration of large scripts, and the only project I know of that's even attempting that is Oil: https://www.oilshell.org/

But for spawning a command in a subprocess, there really ought to be a standard OS API that doesn't involve invoking a shell at all. I expect that most or all implementations of posix_spawn and execve don't invoke a shell, but the standard call to start a process on Windows, CreateProcess, apparently does involve cmd.exe for some bizarre reason, and that's why this is a problem in the first place.

[–] maiskanzler@feddit.de 1 points 6 months ago (1 children)

Python😎

[–] Gobbel2000@programming.dev 7 points 6 months ago (1 children)

While there certainly is some overlap, Python is a scripting language and not a shell language. Some tasks that involve calling lots of different programs and juggling input and output streams are much easier done in bash than in Python.

[–] maiskanzler@feddit.de 2 points 6 months ago

Absolutely true, it was more of a joke because Python is being used for pretty much anything today. I really don't want to mess with correct indentation in my terminal.

[–] asyncrosaurus@programming.dev 1 points 6 months ago

Powershell

/s

[–] UnfortunateShort@lemmy.world -1 points 6 months ago

I think fish is simply fantastic. Not only is it significantly more readable than most other shell languages, it was also recently rewritten in Rust (still in testing I think), which gives me a lot of confidence when it comes to your typical vulnerabilities.

I mean sure, a Rust vulnerability the reason we're talking, but let's not forget how valuable memory and thread safety are.

[–] thingsiplay@beehaw.org 31 points 6 months ago

Got fixed: https://github.com/rust-lang/rust/releases/tag/1.77.2

[–] bonus_crab@lemmy.world 20 points 6 months ago

Windows is as much to blame as any affected languages tbh.

[–] xmunk@sh.itjust.works 17 points 6 months ago (2 children)

Now that it has been identified, it should be an easy fix, at least.

Still, it's important to remember that Rust is still a relatively young ecosystem and flaws like this exist until we get burned by them.

[–] BatmanAoD@programming.dev 19 points 6 months ago

And in fact it's not specific to Rust, and Rust is the first language with a fix available. (Thanks to some other comments for pointing this out.) Java has apparently declared it "won't fix."

https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/#appendix-b-status-of-the-affected-programming-languages

[–] bizdelnick@lemmy.ml 7 points 6 months ago (1 children)

it should be an easy fix

But it's not. Have you read the article?

[–] anton@lemmy.blahaj.zone 1 points 6 months ago (1 children)

I looked at the diff, it's around 100 lines of new code and a few hundred lines of comments and tests.
I couldn't have written it, but there are many smarter people that fixed it after they learned of the problem.

What also made it easier to fix is that they (sensibly) chose to error on certain strings that can't be escaped safely.

[–] bizdelnick@lemmy.ml 1 points 6 months ago

It's not a proper fix, there are still cases when correct escaping is impossible and the function simply returns a error. I don"t know if if this possible at all to escape any string or if it is just because of lack of documentation, but anyway i wouldn't call this a thing that is easy to fix.

[–] onlinepersona@programming.dev 14 points 6 months ago (2 children)

At least it's not a segfault, buffer overflow, or whatever else plagues C/C++ programs and is not easy to detect.

Anti Commercial AI thingyCC BY-NC-SA 4.0

[–] thingsiplay@beehaw.org 24 points 6 months ago (2 children)

But it got a 10/10 on the scoring system by Github.

The issue isn't actually too much related to the Rust core language itself, but rather how they handle scripts on Windows platform. So if you don't have a Windows program that runs Batch scripts, then it doesn't matter to you. I wonder how common it is to run Batch scripts in Rust?

[–] TehPers@beehaw.org 8 points 6 months ago

if you don't have a Windows program that runs Batch scripts with untrusted arguments

This only matters when running the scripts with user inputs passed as arguments to the command, which I can't imagine being remotely common at all.

[–] tatterdemalion@programming.dev 5 points 6 months ago

I don't think my company uses batch scripts anywhere, but if they did, it would probably be in the app installer for Windows or something.

[–] Sekoia@lemmy.blahaj.zone 14 points 6 months ago (2 children)

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.

[–] Buttons@programming.dev 8 points 6 months ago

Our bug is their status quo.

[–] xmunk@sh.itjust.works 6 points 6 months ago (1 children)

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.

[–] arendjr@programming.dev 1 points 6 months ago (1 children)

What are the chances Qt is affected by this issue too?

[–] xmunk@sh.itjust.works -1 points 6 months ago (1 children)

Vanishingly small. In Qt that'd have to be an issue in QStringList IIRC.

[–] arendjr@programming.dev 3 points 6 months ago* (last edited 6 months ago)

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.

[–] drjkl@programming.dev 12 points 6 months ago

I've run into bizarre behavior with windows command lines plenty of times before, but I'd never put all the pieces together and realized that:

a) windows really does pass around unadorned monolithic strings containing the entire command line of an executed command, and

b) there's no parsing standard for command lines in windows

sigh, windows

[–] eveninghere@beehaw.org 11 points 6 months ago* (last edited 6 months ago) (3 children)

In February, the White House Office of the National Cyber Director (ONCD) urged technology companies to adopt memory-safe programming languages like Rust.

My comment is somewhat unfair, but WH is not the right body to make this kind of recommendation.

[–] JustBrian7872@feddit.de 12 points 6 months ago* (last edited 6 months ago)

And the problem is about executing programs in windows. This is not about memory-safety.

A bunch of other languages are affected as well as noted by @colonial@lemmy.world.

[–] thingsiplay@beehaw.org 9 points 6 months ago

Why not? I mean they are right. Adopting memory safe languages is a good step forward, because it would eliminate bunch of mistakes before they happen. And the White House does not recommend Rust only, but a memory-safe language, something like Rust or something different. I wish my government would do the same.

[–] notfromhere@lemmy.ml 3 points 6 months ago (1 children)

Who would be then, Department of Defense, NSA, CIA, FBI, Department of Homeland Security? Aren’t all those the same body (executive) as White House of the National Cyber Director? Is your problem with having White House in the name?

[–] MachineFab812@discuss.tchncs.de 7 points 6 months ago* (last edited 6 months ago)

Those agencies are under the executive branch, and its been made very clear in the past that they prefer sneaking in backdoors to valid best practices.

The NSA sabotaging the Elliptic Curve method of random number generation used in the RSA algorithm comes to mind. They would otherwise be THE experts to trust, but lets look at the others:

FBI - Waco, Ruby Ridge, planned to assassinate Martin Luther King and so many others. CIA - promotes fascism internationally, causing all sorts of chaos in Latin America and the Middle East. Ever wonder how Komeni's faction overthrew the Shah? The CIA decided he had gone soft.

Germany is so trusting of the US on cyber-security measures that their government has been trying to ditch Windows for over a decade.

TL;DR: In the US, government experts do NOT have your personal security best interests at heart. They can and will use any dirty trick possible to spy on and control both our own citizens and those of other countries. Last authories that anyone should trust.

https://blog.cloudflare.com/how-the-nsa-may-have-put-a-backdoor-in-rsas-cryptography-a-technical-primer