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

161–170 of 368 posts

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

#161

Post by dnnddidiej »

tmoertel wrote: post #83
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.

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…

Is this a win for .NET where the mothership provides almost all what you need?

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

#162

Post by dnnddidiej »

dijksterhuis wrote: post #33
bayindirh wrote: post #23

Earlier quoted context omitted.

That won't happen, because time to market is the biggest obstacle between the developers and the monies. If leftpad, electron, Anthropic, Zed, $shady_library$ gonna help developers beat that obstacle, they'll do it instantly, without thinking, without regret. Because an app is not built to help you. It's built to make them monies. It's not about the user, never. Note: I'm completely on the same page with you, with a…

i guess it's a market thing? because when i build stuff in a B2B scenario for customers, it is about the customer's users. Because the customer's users are the money. at least, that's my attitude on it :shrugs:

The customer is the money. If the customer cares about its users then they are the money.

Then you have the user is the product the customer is the advertiser situation. You please the customer enough to have a product to sell to advertiser.

And this before we even touch deceipt. E.g. lying to the customer to make more money.

companies work for their shareholders

kinda

they work for where the power lies. even shareholders get fucked too.

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

#163

Post by PaulHoule »

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…

There is a huge wetware problem too. Like if I can send you an email or other message that tricks you and gets you to send me $10k, what do I care if the industry is 100% effective at blocking RCE?

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

#164

Post by DrewADesign »

grvdrm wrote: post #160
dylan604 wrote: post #154

Earlier quoted context omitted.

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.”

The fundamental problem remains: it’s difficult to predict how long it will take to solve a series of puzzles. I worked in a dev group where we’d take the happy path estimate and double it… it didn’t help much. So often I’d think something would take me a week, so two walls was allotted, but I made a discovery in my first like hour/day whatever that reduced the dev time to like a couple days. Then, there were tasks that I thought I’d solve in a few days that took me weeks because I couldn’t foresee some series of problems to overcome. Taking a guess and adding time to it just shifts the endpoint of the guess. That didn’t help us much.

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

#165

Post by LeifCarrotson »

colonCapitalDee wrote: post #153
bruckie wrote: post #112

Earlier quoted context omitted.

> 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

Cost is a parameter subject to engineering tradeoffs, just like performance, feature sets, and implementation time.

Security and reliability are also parameters that exist on a sliding scale, the industry has simply chosen to slide the "cost" parameter all the way to one end of the spectrum. As a result, the number of bugs and hacks observed are far enough from the desired value of zero that it's clear the true requirements for those parameters cannot be honestly said to be zero.

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

#166

Post by BenjiWiebe »

stratts wrote: post #102
toniantunovi wrote: post #45

The supply chain attack surface in WordPress plugins has always been particularly dangerous because the ecosystem encourages users to install many small single-purpose plugins from individual developers, most of whom aren't security-focused organizations. Buying out an established plugin with a large install base is a clever approach because you inherit years of user trust that took the original developer a long time…

Not only that, but so many people are reluctant to pay for anything so your average installation is chock full of freemium plugins. I've worked on plenty of sites whose admin page looked a bit like the IE6 toolbar meme.

Hmmm... I'm reluctant to pay for WordPress plugins because a bunch of them are also single purpose plugins from random developers, and of questionable quality.

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

#167

Post by ablob »

colonCapitalDee wrote: post #153
bruckie wrote: post #112

Earlier quoted context omitted.

> 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

The question was not if it was possible within price boundary X, but if it was possible at all. There is a difference, please don't confound possibility with feasibility.

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

#168

Post by chii »

rcxdude wrote: post #159
bruckie wrote: post #112

Earlier quoted context omitted.

> 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.

building around bugs that you know exists but dont know where is also a part of it. Reliability in the face of bugs. The mere existence of bugs isn't enough to call the software buggy, if the outcome is reliable (e.g., a triple module redundancy).

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

#169

Post by knowaveragejoe »

rmccue wrote: post #132
knowaveragejoe wrote: post #85

Earlier quoted context omitted.

Is FAIR wordpress-only?

Currently the reference implementation is for WordPress, but we’re working to bring it to Typo3 and other software at the moment too. The protocol is comprised of a core plus per-software extensions when needed.

I see. Are there other similar projects for other ecosystems? I guess more broadly I'm intrigued by the idea of the decentralized supply chain concept, the way you described it sounds like it was more broadly applicable.

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

#170

Post by baby_souffle »

nulltrace wrote: post #158
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.

I mitigate this using a latest -1 policy or minimum age policy depending upon exactly which dependency we're talking about. Combined with explicit hash pins where possible instead of mutable version tags, it's saved me from a few close calls already... Most notably last year's breach of TJ actions
Post reply on HN