• sepulcher@lemmy.ca
      link
      fedilink
      English
      arrow-up
      1
      ·
      7 months ago

      I’m honestly surprised windows can even exist at this point.

      It’s mind-boggling to me that people would dedicate their lives to learning that system when it’s such a shoddy piece of crap.

      It’s amazing what a motivator money can be.

  • 5C5C5C@programming.dev
    link
    fedilink
    English
    arrow-up
    32
    ·
    7 months ago

    Funny how the headline makes it sound like a Rust specific problem, as if the Rust language is unsafe or the core team was incompetent, but then other affected language standard libraries include

    • 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)

    So actually this is a vulnerability that originates in Windows, and Rust and Haskell are the only languages that are actually protecting users from it as of right now, with Node.js and PHP to follow.

    • Blue_Morpho@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      arrow-down
      1
      ·
      edit-2
      7 months ago

      It’s not Rust, the language or even Windows.

      It’s if you write a program that allows the end user to call a command prompt and don’t carefully sanitize the input, bad things could happen.

      I mean, maybe Windows could do something different but if you wrote JavaScript that takes text input from a webpage and pass it to “sudo bash ##commands”, you’re going to have a bad time.

      It’s complete click bait because Rust has a reputation for security.

      • wkk@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        ·
        edit-2
        7 months ago

        It’s definitely not Rust’s fault, but it’s kinda Windows’ one and cmd.exe escape logic… It’s really difficult to write logic that will correctly escape any argument given to it, cmd.exe really is a pain to deal with :/

        The Rust security team faced a significant challenge when dealing with cmd.exe’s complexity since they couldn’t find a solution that would correctly escape arguments in all cases.

        As a result, they had to improve the robustness of the escaping code and modify the Command API. If the Command API cannot safely escape an argument while spawning the process, it returns an InvalidInput error.

        “If you implement the escaping yourself or only handle trusted inputs, on Windows you can also use the CommandExt::raw_arg method to bypass the standard library’s escaping logic,” the Rust Security Response WG added.

        I get that in situations where they can’t safely escape a parameter they’ll just stop with an error, which sound as sane as one could go with this!

  • ShittyBeatlesFCPres@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    7 months ago

    I’m no Windows expert but I wonder why they don’t offer a “Windows Now” type product that breaks backwards compatibility but is more secure. Something that doesn’t even come with cmd.exe because Powershell exists. (Not that it would solve the issue in the article. This is more an aside.) Windows RT was probably not that. From what I understand, it was a “Windows But Weirdly Limited” product. I mean full Windows that can run reasonably modern software but does away with all the backwards compatibility stuff only certain businesses need.

    Apple is ruthless about that and it doesn’t seem to hurt them. Linux distros barely bother because you can always find a way to run an old version if you really want to. It’s kind of neat that Windows can still run Excel 1.0 or whatever but as a non-Windows user, it seems like they could break with the past and fix a lot of security issues for a fraction of what they’re spending on A.I. PowerPoints or whatever.

      • Thomas@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        1
        ·
        7 months ago

        Yes, one of the factors that contributed to the demise of Windows Mobile was the lack of backwards-compatibility for apps between 7, 8, an 10.

    • pycorax@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      7 months ago

      That was what 10X was supposed to be. It was supposed to be practically a full rewrite of the OS to shake off all the legacy cruft with support for existing Win32 apps through containerization. It was dropped along with the Surface Neo and they shifted their focus to Win 11 instead which is a real shame.