abadideainfo on the github breach appears to only be available on xitter 🙄 , I fished it out for you.
gonna gently push back that there's no reason (according to github's version of the story) to associate this with AI or with spectacular incompetence on the part of the employee; the issue is that industry standard, extremely widely used text editor Visual Studio Code has a big button that says "click here to add useful functionality to do your job" that has a 1% chance of installing ransomware
Ian@0xabad1dea Or the extension was legitimate and got compromised (their use of the term "poisoned" makes me think that).
Supply chain attacks are on the rise; the best course of action is to admit when they happen, learn from them, and use those learnings to prevent it in the future.
JA@soviut @0xabad1dea Checkmarkx (appsec company!) recently couldn't kick out the attackers for a month, so one of their recommended action to clients was to disable auto update of the Checkmarkx extension in VSCode (which was poisoned)
Nephrite@0xabad1dea I'm honestly not sure if you're joking or if this is literally true.
Ratsnake@Nephrite @0xabad1dea 1% is maybe a bit exaggerated but VS Code marketplace is kinda notorious for malware
@ratsnakegames @0xabad1dea That sounds pretty bad. Don't they do reviews or anything?
@Nephrite @0xabad1dea which package registry does these days?
@ratsnakegames @0xabad1dea Maybe I shouldn't learn coding. Sounds more and more like a well of cursed knowledge these days.
Radek Pietruszewski 🐶@Nephrite @ratsnakegames @0xabad1dea The problem IMO is a complete lack of sandboxing. You can have completely legitimate extension one day, then next day it gets updated with a compromised version (perhaps via a dependency)
@radex @Nephrite @0xabad1dea you cannot meaningfully sandbox an extension whose functionality includes compiling and running code from the user's workspace
@radex sandboxing the web browser was reasonably easy at the start because web pages had extremely limited functionality. But every time that allowable functionality gets extended, there is another multi-year process of defining and standardizing new interfaces including new permissions.
You cannot do that in an IDE without severely compromising the usefulness of thr IDE's plugin model
@ratsnakegames @Nephrite @0xabad1dea Sure. I'd rather say that _not every_ extension can be meaningfully sandboxed.
Required permissions could be clearly displayed and those that require full unsandboxed access could be additionally flagged.
IMO this would go a long way towards reducing risk of pwnage via extensions. Long process, sure, but worth it.
DerPumu (he/him)
Michael Newton@[email protected] This is literally true, and has been giving many of us nightmares for a long time. See also the package managers for most popular programming languages.
Nephrite (@[email protected])
59 Posts, 94 Following, 50 Followers · Currently in recovery from burnout. Rediscovering the joy of creativity. Hobby page (very much still under construction): https://nephritescastle.neocities.org/
luna the doggie 
@0xabad1dea yay systemic problems!
Kevin Boyd (he/him) 🇨🇦@0xabad1dea but it is the same company, so they are not at all absolved
Edit: and yes, you are very right about how problematic that is.
fat hairy chud@0xabad1dea vscode, the editor that automatically runs arbitrary shell commands from .vscode/config.json without confirmation the moment you press the big "trust workspace" button that it conditions users into clicking without thinking. and somehow that is still one of the most popular editors
mlen@lea @0xabad1dea Not that I disagree, but in certain languages just compiling the code without executing the resulting binary can execute arbitrary code. Same for running the LSP. Sadly the workspace trust problem goes beyond that editor.
Irenes (many)@0xabad1dea sigh, thanks
SMillerNL@0xabad1dea here’s a xcancel link: https://xcancel.com/i/status/2056949168208552080
GitHub (@github)
1/ We are sharing additional details regarding our investigation into unauthorized access to GitHub's internal repositories. Yesterday we detected and contained a compromise of an employee device involving a poisoned VS Code extension. We removed the malicious extension version, isolated the endpoint, and began incident response immediately.
tatiana 
@0xabad1dea wth is 'directionally consistent'
Tom Head@tati @0xabad1dea I don't know how someone decides to use the phrase "directionally consistent". Maybe they took too many drugs, or not enough. Anyway, something went wrong, for sure.
The Witch of Crow Briar@tati @0xabad1dea “we don’t think we can get away with denying it”
tkissing@0xabad1dea Happy GitHub Breach Day! Enjoy this one. Starting next week we will go back to just calling it Wednesday again.
groxx@0xabad1dea maybe they'll build a status page some day. they're still a scrappy startup though, they probably have higher priorities like making investor pitch decks.
Ryan Finnie@0xabad1dea My favorite take so far: "holy shit, how did the attackers find a large enough uptime window to get in?"
Cogito ergo mecagoendios@0xabad1dea while this is not directly related to AI as far as reported, I can't help but imagine that hiring people who buy into the AI idiocy is a surefire way to get your entire organization packed full of imbeciles likely to make this fuck up one day or another
David Chisnall (*Now with 50% more sarcasm!*)@0xabad1dea Huh. It’s almost as if an editor with a marketplace for extensions and zero thought to the security model (beyond ‘extensions have complete access to your computer’) might not have been the best idea after all.
Phil@david_chisnall @0xabad1dea
While yes, I think it's more about the perception of extensions being secure. Emacs has the same security model, but you don't see Big News™ about it.
Granted part of this is that Emacs itself requires a certain level of understanding to use so it filters out users who Just Install Things© but still.
While yes, I think it's more about the perception of extensions being secure. Emacs has the same security model, but you don't see Big News™ about it.
Granted part of this is that Emacs itself requires a certain level of understanding to use so it filters out users who Just Install Things© but still.
I’ve thought about this for a while and I think the difference is the marketplace. I use a bunch of vim extensions but vim and emacs don’t have a built-in thing that advertises extensions to me. There’s no ‘click here to install…’ button with flashy marketing. There’s no built-in concept of ‘recommended extensions’.
When I install an extension in vim, it’s almost always because someone looks over my shoulder and says ‘wow, I forgot how bad vim was without [my favourite extension]’ and I try it and decide it actually does make life nicer. When people install extensions in VS Code it’s because they’ve been trained that there’s always an extension in the store and it’s the top result for their search. And that gives people a big incentive to put malicious extensions in the store.
Duncan Bayne@phil @0xabad1dea @david_chisnall No no, Emacs has a *far* more sophisticated security model than VSCode.
Malware authors sit down to learn Emacs, so they can write Elisp malware ...
... and ten years later they're still customising their editor, and haven't written a single line of malicious code.
(Posted with love as an 
user for several decades ...)
Lars Wirzenius@david_chisnall @0xabad1dea I could not ever have thought that to be a problem! Who has ever heard of it being problematic to download random code from the Internet and run it with full privileges on your computer? This realization is a breakthrough in infosec. Someone deserves a Nobel price for this. And a Turing award.
(#sarcasm just in case)
muddle@0xabad1dea (horselegged/sanserif Swastikas...)
Benoît B.They wrote:
> "2/ Our current assessment is that the activity involved exfiltration of GitHub-internal repositories only. […]
3/ We moved quickly to reduce risk. Critical secrets were rotated yesterday and overnight with the highest-impact credentials prioritized first."
Do they really put "Critical secrets" in their "GitHub-internal repositories" !?
endrift 🏳️⚧️@0xabad1dea That is a fuckton of repos. Unless it counts each individual fork as a distinct repo, in which case that may or may not be a fuckton of repos. Would be nice for them to clarify that, but considering their comms team doesn't even seem to have a blog to post status updates to, perhaps that's more than can be expected of, um, the largest code forge in the world.
@endrift 3800 properly distinct repos doesn’t strike me as an unlikely number if it includes every employee’s minor side project over the last 18 years
@0xabad1dea Yeah I suppose so. I was thinking more org scope as opposed to user scope, which is a huge difference.
degenerating degenerate@0xabad1dea It's great Microsoft are really getting into "Open Source"
James"Directionally consistent"
nick@JHB17 @0xabad1dea it's a positive number of repositories with no imaginary component.
tmaher@0xabad1dea thank you for the fishing
Taggart 
Yossi@0xabad1dea paraphrased comment I saw on xitter:
"how did the hackers find a window of uptime to get in?"