|
itt: the pgp key that would have been stolen from the user's hard disk by malware is much more secure than the username/password that would have been stolen from the user's hard disk by malware, because pgp key revocation much easier than changing passwords
|
#
?
Jul 13, 2018 01:16
|
|
|
|
| # ? Jun 1, 2024 08:32 |
|
|
npm and other package managers seem almost expressly set up to expedite supply chain attacks and the culture surrounding them makes it worse. left-pad is an indication of a problem of balkanization and abrogation if responsibility for understanding that supply chain. I don’t know what a better model is but I don’t have to to say that this one isn’t good
|
|
#
?
Jul 13, 2018 01:23
|
|
|
Suspicious Dish posted:please explain to me how this environment is any different from other language package systems like CPAN, PyPI, Maven, Ruby Gems, etc. Yeah I'm complaining about all of those too, and more broadly about containerization and ops and all the cloud buttons that try to make everything easy by downloading a hundred unsigned untrusted binaries from some 3rd party. It's all quite bizarre.
|
|
#
?
Jul 13, 2018 01:35
|
|
|
e: (wrong thread)
|
|
#
?
Jul 13, 2018 01:40
|
|
|
Suspicious Dish posted:please explain to me how this environment is any different from other language package systems like CPAN, PyPI, Maven, Ruby Gems, etc. maven has artifact signing and also jars can be signed.
|
|
#
?
Jul 13, 2018 02:05
|
|
|
Suspicious Dish posted:itt: the pgp key that would have been stolen from the user's hard disk by malware is much more secure than the username/password that would have been stolen from the user's hard disk by malware, because pgp key revocation much easier than changing passwords its not about trust of the package generator, its about trust of the package repository. its message security vs transport security. message security (package signing) lets me ignore where I get my package. I don't give a poo poo about the package source as long as the message is intact. If I trust Microsoft to secure their signing keys, I can trust where a Microsoft package came from regardless of source. If Microsoft is just uploading stuff to GitHub unsigned, im putting my faith in GitHub that they, not Microsoft, are doing things correctly. I mean now GitHub is owned by Microsoft sure but I trust ms for security way more than I trust the GitHub fedora bros.
|
|
#
?
Jul 13, 2018 02:14
|
|
|
also its not at all surprising javascript devs don't understand security.
|
|
#
?
Jul 13, 2018 02:15
|
|
|
even powershell scripts can be signed, even if they typically aren't because of the poor design decision not to enforce it.
|
|
#
?
Jul 13, 2018 02:20
|
|
|
Suspicious Dish posted:please explain to me how this environment is any different from other language package systems like CPAN, PyPI, Maven, Ruby Gems, etc. what is the perl/python/java/etc equivalent of eslint?
|
|
#
?
Jul 13, 2018 02:54
|
|
|
did powershell 3 fix the whole "you have to give yourself permaroot in order to execute stuff" garbage?
|
|
#
?
Jul 13, 2018 02:57
|
|
|
this eslint exploit only targeted dev machines right? if someone published a malicious minifier/transpiler version, would they be able to inject malicious code into any project that relied on those tools?
|
|
#
?
Jul 13, 2018 03:06
|
|
|
Plank Walker posted:this eslint exploit only targeted dev machines right? dev machines or really any other machine running npm stuff (so, prod servers lol) 💯 on the trusting trust attack
|
|
#
?
Jul 13, 2018 03:23
|
|
|
mrmcd posted:I'm Xenu's Link Sleuth 1.1c I'm Flaming AttackBot
|
|
#
?
Jul 13, 2018 03:26
|
|
|
Shaggar posted:its not about trust of the package generator, its about trust of the package repository. its message security vs transport security. message security (package signing) lets me ignore where I get my package. I don't give a poo poo about the package source as long as the message is intact. ok so now your malware-filled eslint zip file is signed as coming from the eslint developers. this helps you exactly... how?
|
|
#
?
Jul 13, 2018 03:29
|
|
|
Plank Walker posted:what is the perl/python/java/etc equivalent of eslint? by this you mean "a common enough perl/python/java package that a lot of things will install it"? how about log4j or python's flask/django
|
|
#
?
Jul 13, 2018 03:32
|
|
|
Suspicious Dish posted:ok so now your malware-filled eslint zip file is signed as coming from the eslint developers. this helps you exactly... how? don’t bother, he’s not worth the typing
|
|
#
?
Jul 13, 2018 03:37
|
|
|
*has publish access to a package that is downloaded 2.5 million times a week*quote:The maintainer whose account was compromised had reused their npm password on several other sites and did not have two-factor authentication enabled on their npm account.
|
|
#
?
Jul 13, 2018 03:45
|
|
|
if computers weren't involved that would be criminal negligence
|
|
#
?
Jul 13, 2018 03:46
|
|
|
Phone posted:did powershell 3 fix the whole "you have to give yourself permaroot in order to execute stuff" garbage? no because it was never a thing
|
|
#
?
Jul 13, 2018 04:16
|
|
|
Suspicious Dish posted:ok so now your malware-filled eslint zip file is signed as coming from the eslint developers. this helps you exactly... how? it doesn't. what it prevents is the scenario where they upload it for distribution and the distributor gets owned. Or the scenario where the artifact is distributed by someone else as in an artifact proxy repo. do you really not understand code signing?
|
|
#
?
Jul 13, 2018 04:18
|
|
|
fisting by many posted:*has publish access to a package that is downloaded 2.5 million times a week* but wahhhh I don't want to sign packages even though it would have prevented this because im a lazy lovely javascript developer who uses bad tools and thinks that's how it has to work for everyone
|
|
#
?
Jul 13, 2018 04:19
|
|
|
Cocoa Crispies posted:don’t bother, he’s not worth the typing lol Linux users continuing this threads tradition of ignoring security because they're always wrong.
|
|
#
?
Jul 13, 2018 04:20
|
|
|
flakeloaf posted:at least a usb port with a yubikey in it isn't going to be used to charge somebody's loving phone how dare they
|
|
#
?
Jul 13, 2018 04:24
|
|
|
javascript developer: lets not use tls because it doesn't protect you from the server getting owned.
|
|
#
?
Jul 13, 2018 04:27
|
|
|
Shaggar posted:it doesn't. what it prevents is the scenario where they upload it for distribution and the distributor gets owned. Or the scenario where the artifact is distributed by someone else as in an artifact proxy repo. ok, so it has no bearing on anything that happened today and wouldn't have fixed this issue. Shaggar posted:but wahhhh I don't want to sign packages even though it would have prevented this because im a lazy lovely javascript developer who uses bad tools and thinks that's how it has to work for everyone but you just said it wouldn't have prevented this
|
|
#
?
Jul 13, 2018 05:02
|
|
|
it would have prevented that attack since it was on the distributor, not the package generation. Someone broke into the npm account, not the developer's build environment, and uploaded a bad version of eslint that would have had no signature or an invalid signature. From there properly setup environments would reject it and prevent the exploit from executing on people dependent on eslint. it wouldn't prevent it in the event that the eslint build environment was compromised and the signing key was stolen, but that's not what happened here. Shaggar fucked around with this message at 05:38 on Jul 13, 2018 |
|
#
?
Jul 13, 2018 05:35
|
|
|
also in the event of key theft they could add it to its related crl so future use of the file would be prevented. Right now since there is no signing the invalid version is out in the wild forever and someone might reuse it from a local copy without realizing its tainted.
|
|
#
?
Jul 13, 2018 05:39
|
|
|
Shaggar posted:no because it was never a thing i haven't looked at the
|
|
#
?
Jul 13, 2018 06:15
|
|
|
if you want to run things as admin you run powershell as administrator like you would any other application. you're probably thinking of the execution policy which by default prevents you from running downloaded unsigned scripts. This is to prevent the most obvious attacks. It does not prevent you from running local scripts or remote scripts that you have unblocked. This works by looking for a flag on the file that's set when you download a file. Its not perfect but again it prevents you from doing something stupid without atleast giving it some effort. If you want to run a script you downloaded you can: A) unblock the file by removing the download flag B) sign the file yourself C) set the execution policy to something less restrictive. A and B are the correct options since they are per file. C is bad cause it removes that downloaded script protection for any future script you run. C also requires that you run the set-executionpolicy command as administrator like you would expect when changing system/security settings. You can also set it per user or per machine. Never ever change the machine setting like god drat please don't just learn to sign your scripts its not hard.
|
|
#
?
Jul 13, 2018 06:26
|
|
|
Also you can set the execution policy to only allow signed scripts to run. that's a great idea. but the problem is a lot of core powershell modules from Microsoft aren't signed so it means they wont run. its stupid. they should have just made the default machine policy signed only, signed all the Microsoft modules, and then required you to set your user policy separately to run your own scripts.
|
|
#
?
Jul 13, 2018 06:30
|
|
|
Phone posted:i haven't looked at the windows processes can't elevate while running in theory they could make a "sudo" command that would spawn a new elevated powershell process that would run whatever ps command was typed in after it
|
|
#
?
Jul 13, 2018 07:31
|
|
|
explain why the default execution policy (restricted, disallowing all scripts including ones you have written) is a sensible default for the new windows scripting language imo restricted is a bad default, because the first thing everyone does when trying to save and run a script is google the error, learn about execution policies, and disable them entirely. if the default was RemoteSigned, most people wouldn't even notice
|
|
#
?
Jul 13, 2018 08:16
|
|
|
yeah script signing in PowerShell is a perfect demonstration of a good idea wrt security but implemented so badly it has the opposite effect becausequote:the first thing everyone does when trying to save and run a script is google the error, learn about execution policies, and disable them entirely. it's me (though I haven't touched ps for ages)
|
|
#
?
Jul 13, 2018 08:47
|
|
|
In the default config you can disable the execution policy as a command line option to the script you're executing
|
|
#
?
Jul 13, 2018 08:54
|
|
|
redleader posted:explain why the default execution policy (restricted, disallowing all scripts including ones you have written) is a sensible default for the new windows scripting language because the very large majority of windows users will never launch powershell.exe let alone execute a powershell script so disabling untrusted script execution is a nice mitigation feature. for those who do want to run scripts they can just go and change it. in managed environments execution policy is usually set via group policy. Powerful Two-Hander posted:yeah script signing in PowerShell is a perfect demonstration of a good idea wrt security but implemented so badly it has the opposite effect because script signing is an excellent feature which is simply underutilised. this whole situation with execution policy is very analogous to when UAC was first implemented: initially poo poo because no one did things properly however when people did start doing things properly it became a non-issue. tbh i'm just glad that microsoft had the foresight to bake signing in from the beginning as an option. it's a nice feature that's good to have. of course as others have pointed out execution policy is pretty much moot because you can just pull a payload from the web (using Invoke-WebRequest or System.Net.Sockets.TcpClient) and execute it with Invoke-Expression within the shell. this can be mitigated ofc. in the last place i was at we configured the SEP client firewall (yeah yeah i know) to block network connections from powershell.exe except to specific internal trusted hosts.
|
|
#
?
Jul 13, 2018 10:41
|
|
|
Phobeste posted:npm and other package managers seem almost expressly set up to expedite supply chain attacks and the culture surrounding them makes it worse. left-pad is an indication of a problem of balkanization and abrogation if responsibility for understanding that supply chain. I don’t know what a better model is but I don’t have to to say that this one isn’t good Same but gentoo
|
|
#
?
Jul 13, 2018 14:42
|
|
|
redleader posted:explain why the default execution policy (restricted, disallowing all scripts including ones you have written) is a sensible default for the new windows scripting language it doesn't restrict ones you have written.
|
|
#
?
Jul 13, 2018 14:53
|
|
|
spankmeister posted:In the default config you can disable the execution policy as a command line option to the script you're executing it requires admin privileges though so at that point you already have total access to the machine.
|
|
#
?
Jul 13, 2018 14:54
|
|
|
what if like crates/gems/eggs/etc. could declare and have enforced limited permissions like if I did npm install left-pad node would grab the package metadata, see that it claims to be pure, puts that in the node-modules.json file, and from then on, even if left-pad gets sold to a capitalist and updated to be malware, if it does something that's not pure function behavior (pulls in file or network I/o stuff, etc.) the process gets killed so if there's a really compelling left-pad feature that renders it non-pure you have to go in and remove the pure annotation from node-modules, but even through updates it won't ever disappear on its own think pledge in bsd but for a platform people use and instead of a process lifetime (seconds to hours) it's a package lifetime (months to years ideally)
|
|
#
?
Jul 13, 2018 14:55
|
|
|
|
| # ? Jun 1, 2024 08:32 |
|
|
I don't think javascript is good enough to be able to enforce that reliably. it would be too easy to obfuscate in code and you'd have to rely on runtime enforcement which would be totally out of the developer's hands. plus non-malware authors could have legitimate reasons to change it in the future which would cause your poo poo to break. A better option would be like windows store and ios/android apps do where the application metadata requests certain privileges and the user allows or denies them. Then the runtime enforces the security. You could then push this all the way to the browser and users could start deciding if they want to let goog-analytics.js access all their poo poo.
|
|
#
?
Jul 13, 2018 15:02
|
|