Visual Studio Code for Linux: Remote Code Execution Vulnerability - Page 1
Forum section: electronics / general

author: madires
author_rank: Super Contributor
timestamp: October 12, 2024, 03:07:34 pm
content: This one is too funny.Visual Studio Code for Linux Remote Code Execution Vulnerabilityhttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43601

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 12, 2024, 10:29:14 pm
content: QuoteWhut?[After investigating for a bit:]Explanation,patch: Insufficient parameter/file checking in TypeScript code when saving files requiring elevated privileges (stuff done viasudo).So, just your garden-variety"we'll just pass along these file names you supplied as-is to our copy-file-using-sudocommand, she'll be alright, nobody will try any shenanigans I'm sure"type of idiocy.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 12, 2024, 10:42:06 pm
content: No input validation and let's throw some sudo on top of it.I would definitely trust MS code.

author: magic
author_rank: Super Contributor
timestamp: October 13, 2024, 05:58:58 am
content: Microsoft is backdooring LinuxNext thing, they will start contributing to systemd and add something similar

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 13, 2024, 06:19:50 am
content: You mean like CVE-2021-3560 or CVE-2020-1712 and others?

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 13, 2024, 06:29:21 am
content: Quote from: magic on October 13, 2024, 05:58:58 amWasn't the lead Rust dev working on getting Rust into the Linux kernel a MS dev? Just wondering.

author: magic
author_rank: Super Contributor
timestamp: October 13, 2024, 07:18:01 am
content: Quote from: Nominal Animal on October 13, 2024, 06:19:50 amWere the patches contributed by Microsoft, though, or just business as usual?Maybe I chose a wrong exampleQuote from: SiliconWizard on October 13, 2024, 06:29:21 amHere's food for thought: Microsoft bought GitHub, and they must have had some reason

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 13, 2024, 08:02:55 am
content: Quote from: magic on October 13, 2024, 07:18:01 amJust systemd as usual. The original systemd authorisemployed by Microsoft, though.Quote from: SiliconWizard on October 13, 2024, 06:29:21 amYep.To be Karl (because Frank is on holiday this weekend), it was an inevitable clash, due to the working principle of no fixed internal APIs, and subsystem maintainers and other developers not being interested in doubling their work by also maintaining the Rust interfaces to said subsystems. Plus having it lead by a young whippersnapper. When you truly get into the kernel, the developer workload and continuous changes are immense: easily enough to break the sanity of a normal person.The funky thing in the discussion was seeing how many were horrified at the kernel developer responses. First, they arekernel developers: they have no social skills by definition. The rare ones who do, like Greg KH, get exploited (see kdbus fiasco a decade ago) and then rather than publish a"mea culpa, this was a shit idea", do the social"you are behaving horribly, shame on you, now do as I asked you to"game; so whenever they post anything critical, one has to examine if the reasons are technical or social. The no-social-skills ones are easier, if you can handle the abrasiveness. Second, if your organization would not tolerate these developers lacking social skills, is it something your organization should be proud of? Is social interaction among workers more important than the proven track record of said developers and the product they maintain and develop? Just asking for a friend, mind you.In other words, all kidding aside, I don't think anyone had any nefarious ideas here; it was just a cultural clash. Just like this Visual Studio Code bug stems from a cultural issue, not understanding security and instead just slapping it on top hoping it works.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 13, 2024, 08:18:50 am
content: Quote from: Nominal Animal on October 13, 2024, 08:02:55 amYes, in terms of the clash, probably. But. In terms of more long-term "ideas", who knows.Quote from: magic on October 13, 2024, 07:18:01 amAnd they probably did this for no reason:https://www.webpronews.com/microsoft-donates-1-million-to-rust-foundation/

author: magic
author_rank: Super Contributor
timestamp: October 13, 2024, 09:45:48 am
content: Quote from: Nominal Animal on October 13, 2024, 08:02:55 amDamn, how could I forget.What if he was secretly on M$ payroll for the whole decade?This could explain systemdQuote from: Nominal Animal on October 13, 2024, 08:02:55 amI don't follow the drama, did things reach a point where people have their work blocked because it breaks Rust bindings?

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 13, 2024, 11:43:51 am
content: Quote from: magic on October 13, 2024, 09:45:48 amSilly!No, it's just a case of him perfectly suited to the centralized approach used in Windows, and very poorly suited for the modular Unix philosophy –– I do believe he has publicly stated it is outright outdated concept that should be discarded anyway. So, no secret; just birds of a feather.It is funny how people can ignore the historical precedent, and decide that now that they're in charge, designs that have always failed before (centralization and single-point failure problems) shall now magically succeed. Because everyone else who tried it before did it wrong.If you start with the assumption that those that created and designed the things we still use and rely on weresmarterthan we are now, understood thingsmore fullythan we do, things start making sense. Scary thought, though.Quote from: magic on October 13, 2024, 09:45:48 amNo, but hepostedthis youtube linkas "context", as if that was "nontechnical nonsense", which later bystanders commented as being horrific behaviour from Linux kernel developers that wouldn't be accepted anywhere where the commenters work.Fact is, the Linux kernel changes constantly, at a rate that very few software project sees. At 30+ million lines of code, it is already so large no single human being, not even Linus himself –– and he openly admits this! –– can encompass it all. To keep doing what they are doing, subsystem maintainers and developers have to actively avoid adding to their maintenance burden; otherwise they will fail as a maintainer. And even then, the maintainers change; it's justtoo muchfor a normal person. Normal people just don't understand the complexity and the cognitive load involved.Fundamentally, because the kernel is written in C, it is the Rust bindings (and thus the Rust API) that have to keep up with the kernel innards, and this is what has offended so many, including tons of Google and Microsoft developers, plus a fuckton of commenters. Very few understand the real issue, and it is not that kernel devs are ossified and too stupid to learn Rust: it is that to do what they do now and want to do better in the future, they cannot afford wasting time on Rust, because just tokeep upwith the kernel development they need to use all the brainpower they have.Thatis the exact reason there are no fixed internal APIs in Linux, too: they need the freedom to find the solutions they want!Adding to that load with a completely new set of complexity and issues –– the Rust bindings/API –– is just unrealistic. Try to do the job oftwokernel developers, and you will fail, no matter who the fuck you think you are. Telling those that refuse to do so are "nontechnical" and old refuseniks standing on past achievents or whatnot is idiotic, Poettering-level asshattery. Just subscribe to LKML for a month, drinking from that firehose, andunderstandthe issues discussed, and you'll be hit with the fifty-ton cluebat of what kind of environment it is. Go away for a month, and you'll likely spend six months catching up.

author: magic
author_rank: Super Contributor
timestamp: October 14, 2024, 05:54:04 am
content: I don't get this Rust thing. As far as I see this is a classic case of Rust Evangelism Strikeforce setting to rewrite yet another C project in Rust, a bunch of outsiders coming to Linux mainly for Rust's sake and demanding babysitting by maintainers, rather than existing developers seriously thinking about going dual-language. Everybody knows that those people consider C obsolete and their long term goal is to rewrite the whole world, so they are guaranteed to be resented for their attitude alone and for the problems a growing amount of code written by a separate group all over the codebase is going to cause.Not being content with existing APIs and providing a high-level wrapper in Rust can be seen as an attempt to circumvent the "no stable APIs" rule and may be part of the reason why a bunch of commercial companies want it to happen. Then there will be friction between any out of tree Rust drivers and core when shit breaks.Allowing external Rust fanboys to join a project basically means that you sign up for a Rust rewrite, and this should be announced rather more formally if it's the case. Otherwise, somebody will end up disappointed.I like the concept of "pain allocation"editAnd all of that is for a language which is not as low-level and WYSIWYG as C, never really designed to replace C, and even less designed to rewrite C codebases in. A few years spent to produce wrapper libraries around C because you can't just import and call it, and it's all isolated to one rust/ directory because it's not a serious "all hands on deck" project, because that would frankly be nuts.At this point maybe the kernel should design its own programming language, like they already have a VCSAnd at least commit to it for real.I dislike Rust not for having static analysis built-in, but for simply being not a great language overall. Yet, Rust Evangelism Strikeforce behaves as if Rust were the only statically memory safe language possible and we are doomed to it. I hope for agit rm -r rust/one day.

author: madires
author_rank: Super Contributor
timestamp: October 14, 2024, 01:39:23 pm
content: Every few years there's a new software developement paradigm and also new programming languages, coming with many promises about how everything will become better, faster, more secure, and so on. Let's look at the outcome. Has software improved considerably? Would have Rust prevented CVE-2024-4360?