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

Someone bought 30 WordPress plugins and planted a backdoor in all of them

anchor.host

Post reply on HN
Print view View original

151–160 of 368 posts

Re: Someone bought 30 WordPress plugins and planted a backdoor in all of them

#151

Post by K0IN »

LtWorf wrote: post #98
tmoertel wrote: post #83

Earlier quoted context omitted.

For exactly this reason, when I write software, I go out of my way to avoid using external packages. For example, I recently wrote a tool in Python to synchronize weather-statation data to a local database. [1] It took only a little more effort to use the Python standard library to manage the downloads, as opposed to using an external package such as Requests [2], but the result is that I have no dependencies beyond…

I generally limit myself to what's available in my distribution, if the standard library doesn't provide it. But normally I never use requests because it's not worth it I think to have an extra dependency.

This might hold true for easy deps, but (let's be honest who would install is promise) if you have complex or domain specific stuff and you don't have the time to do yourself or the std lib does not have anything then yeh you might still fall into the pit, or you have to trust that the library does not have an supply chain chain issue itself.

Re: Someone bought 30 WordPress plugins and planted a backdoor in all of them

#152

Post by grvdrm »

dylan604 wrote: post #123
stouset wrote: post #116

Earlier quoted context omitted.

> No matter where I look, up and down the stack, across different OSes and tech stacks, there are bugs. I’m not sure I’d go quite as far as GP, but they did caveat that we often choose not to write software with few bugs. And empirically, that’s pretty true. The software I’ve written for myself or where I’ve taken the time to do things better or rewrite parts I wasn’t happy with have had remarkably few bugs. I have c…

> I’m not sure I’d go quite as far as GP, but they did caveat that we often choose not to write software with few bugs. And empirically, that’s pretty true. Blame PMs for this. Delivering by some arbitrary date on a calendar means that something is getting shipped regardless of quality. Make it functional for 80% of use, then we'll fix the remaining bits in releases. However, that doesn't happen as the team is assign…

I don’t disagree but is the alternative unbounded dev where you write code until it’s perfect? That doesn’t sound like a better business outcome. The trade off can’t be “take as long as you want”

Re: Someone bought 30 WordPress plugins and planted a backdoor in all of them

#153

Post by colonCapitalDee »

bruckie wrote: post #112
KronisLV wrote: post #101

Earlier quoted context omitted.

> We know how to write software with very few bugs (although we often choose not to) Do we, really? Because a week doesn’t go by when I don’t run into bugs of some sort. Be it in PrimeVue (even now the components occasionally have bugs, seems like they’re putting out new major versions but none are truly stable and bug free) or Vue (their SFC did not play nicely with complex TS types), or the greater npm ecosystem, o…

> Do we, really? Yes, or pretty close to it. What we don't know how to do (AFAIK) is do it at a cost that would be acceptable for most software. So yes, it mostly gets done for (components of) planes, spacecraft, medical devices, etc. Totally agreed that most software is a morass of bugs. But giving examples of buggy software doesn't provide any information about whether we know how to make non-buggy software. It onl…

Then we can't do it. Cost is a requirement

Re: Someone bought 30 WordPress plugins and planted a backdoor in all of them

#154

Post by dylan604 »

grvdrm wrote: post #152
dylan604 wrote: post #123

Earlier quoted context omitted.

> I’m not sure I’d go quite as far as GP, but they did caveat that we often choose not to write software with few bugs. And empirically, that’s pretty true. Blame PMs for this. Delivering by some arbitrary date on a calendar means that something is getting shipped regardless of quality. Make it functional for 80% of use, then we'll fix the remaining bits in releases. However, that doesn't happen as the team is assign…

I don’t disagree but is the alternative unbounded dev where you write code until it’s perfect? That doesn’t sound like a better business outcome. The trade off can’t be “take as long as you want”

Some coding doesn't fit your schedule. If you've scheduled 2 weeks, but it takes 3, then it takes 3. Scheduling it to take 2 does nothing to actually make the coding faster.

Re: Someone bought 30 WordPress plugins and planted a backdoor in all of them

#156

Post by da_chicken »

antaviana wrote: post #129

Crypto has single handedly created a very large malware industry and has also made information security a massive industry. Ban crypto and both industries will become way, way smaller.

No, data exfiltration is just as lucrative as crypto.

We are unfortunately long past the point where viruses would frequently be merely annoying.

Re: Someone bought 30 WordPress plugins and planted a backdoor in all of them

#157

Post by wnevets »

chromacity wrote: post #32

This is a perfect illustration of what cracks me up about the hyperbolic reactions to Mythos. Yes, increased automation of cutting-edge vulnerability discovery will shake things up a bit. No, it's nowhere near the top of what should be keeping you awake at night if you're working in infosec. We've built our existing tech stacks and corporate governance structures for a different era. If you want to credit one specifi…

> it's cryptocurrencies

Its arguably the single worse thing to happen to infosec since the internet.

Re: Someone bought 30 WordPress plugins and planted a backdoor in all of them

#158

Post by nulltrace »

bradley13 wrote: post #7

Whenever I look at a web project, it starts with "npm install" and literally dozens of libraries get downloaded. The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.

Lockfiles help more than people realize. If you're pinned and not auto-updating deps, a package getting sold and backdoored won't hit you until you actually update.

The scarier case is Dependabot opening a "patch bump" PR that probably gets merged because everyone ignores minor version bumps.

Re: Someone bought 30 WordPress plugins and planted a backdoor in all of them

#159

Post by rcxdude »

bruckie wrote: post #112
KronisLV wrote: post #101

Earlier quoted context omitted.

> We know how to write software with very few bugs (although we often choose not to) Do we, really? Because a week doesn’t go by when I don’t run into bugs of some sort. Be it in PrimeVue (even now the components occasionally have bugs, seems like they’re putting out new major versions but none are truly stable and bug free) or Vue (their SFC did not play nicely with complex TS types), or the greater npm ecosystem, o…

> Do we, really? Yes, or pretty close to it. What we don't know how to do (AFAIK) is do it at a cost that would be acceptable for most software. So yes, it mostly gets done for (components of) planes, spacecraft, medical devices, etc. Totally agreed that most software is a morass of bugs. But giving examples of buggy software doesn't provide any information about whether we know how to make non-buggy software. It onl…

That software also often has bugs. It's usually a bit more likely that they are documented, though, and unlikely to cause a significant failure on their own.

Re: Someone bought 30 WordPress plugins and planted a backdoor in all of them

#160

Post by grvdrm »

dylan604 wrote: post #154
grvdrm wrote: post #152

Earlier quoted context omitted.

I don’t disagree but is the alternative unbounded dev where you write code until it’s perfect? That doesn’t sound like a better business outcome. The trade off can’t be “take as long as you want”

Some coding doesn't fit your schedule. If you've scheduled 2 weeks, but it takes 3, then it takes 3. Scheduling it to take 2 does nothing to actually make the coding faster.

3 sounds fine.

Then I ask: why not add a week to how long that thing will take, meaning it stretches two sprints (or whatever you call it).

Add upfront. Then if you get to hard convo where someone says “do it sooner” you say “not possible.”

Post reply on HN