4 ms·

Consider this your call to write native software. There is yet to be a supply chain attack on libc

ddp26 7mo ago
Sure, but this is a pretty onerous restriction. Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack)
- dmitrygr 7mo ago
  > Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack) I think the attacks will get worse and more frequent -- ML tools enable doing it easily among people who were previously not competent enough to pull it off but now can. There is no stomach for the proper defensive measures among the community for either python or javascript. Why am i so sure? This is not the first, second, third, or fourth time this has happened. Nothing changed.
  - applfanboysbgon 7mo ago
    Not only do the tools enable incompetent attackers, they also enable a new class of incompetent library developers to create and publish packages, and a new class of incompetent application developers to install packages without even knowing what packages are being used in the code they aren't reading, and a new class of incompetent users who are allowing OpenClaw to run completely arbitrary code on their machines with no oversight. We are seeing only the tip of the iceberg of the security breaches that are to come.
    - dmitrygr 7mo ago
      100%
    - mckennameyer 7mo ago
      So basically the attacker and the dev who caught it were probably using the same tools if the malware was AI-generated (hence the fork bomb bug), and the investigation was AI-assisted (hence the speed). Less "tip of the iceberg" and more just that both sides got faster.
- ting0 7mo ago
  They will certainly get worse. LLMs make it so much easier.
  - hxugufjfjf 7mo ago
    Agreed, as proven quite brutally over the last two weeks and especially the last three days.
woodruffw 7mo ago
This is presumably because libc just doesn't change very often (not meaning code changes, but release cadence). But the average native software stack does have lots of things that change relatively often[1]. So "native" vs. not is probably not a salient factor. [1]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor https://en.wikipedia.org/wiki/XZ_Utils_backdoor
- everforward 7mo ago
  I think that article proves the opposite. > While xz is commonly present in most Linux distributions, at the time of discovery the backdoored version had not yet been widely deployed to production systems, but was present in development versions of major distributions. Ie if you weren’t running dev distros in prod, you probably weren’t exposed. Honestly a lot of packaging is coming back around to “maybe we shouldn’t immediately use newly released stuff” by delaying their use of new versions. It starts to look an awful lot like apt/yum/dnf/etc. I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks.
  - consp 7mo ago
    This is the security equivalent of having a better lock than your neighbour. Won't save you in the end but you won't be first. Then again, yours could also be broken and you don't get to tick of that audit checkbox.
  - woodruffw 7mo ago
    Per below, xz is also an example of us getting lucky. > I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks. Yes, but this also has nothing to do with native vs. non-native.
- dmitrygr 7mo ago
  your link disproves your claim. no naive app depended on xz version >= latest. Most sane distros take time to up-rev. That is why the xz backdoor was, in fact, in NO stable distro And not changing often is a feature, yes.
deleted 7mo ago
[deleted]
hrmtst93837 7mo ago
[flagged]
- dmitrygr 7mo ago
  100% with you. Anything that builds from the first try is 100% malicious. No real software builds without 5-30 tweaks of the makefile. And anything on npm/pip is malicious with a fixed chance that you have no control over, as seen in this attack. But the data remains: no supply chain attacks on libc yet, so even if it COULD happen, this HAS and that merely COULD.
  - hxugufjfjf 7mo ago
    None that we know of, just like we didn’t know of the attack on xz until we did.
mr_mitm 7mo ago
Native software? You mean software without dependencies? Because I don't see how you solve the supply chain risk as long as you use dependencies. Sure, minimizing the number of dependencies and using mostly stable dependencies also minimizes the risk, but you'll pay for it with glacial development velocity.
- dmitrygr 7mo ago
  Slower development velocity but no third-party-induced hacks surely has a market. :)
kryptiskt 7mo ago
Only because C code presents so many juicy security holes by default that it's completely unnecessary to subvert the projects to add them.

ddp26 7mo ago

Sure, but this is a pretty onerous restriction. Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack)

dmitrygr 7mo ago
> Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack) I think the attacks will get worse and more frequent -- ML tools enable doing it easily among people who were previously not competent enough to pull it off but now can. There is no stomach for the proper defensive measures among the community for either python or javascript. Why am i so sure? This is not the first, second, third, or fourth time this has happened. Nothing changed.
- applfanboysbgon 7mo ago
  Not only do the tools enable incompetent attackers, they also enable a new class of incompetent library developers to create and publish packages, and a new class of incompetent application developers to install packages without even knowing what packages are being used in the code they aren't reading, and a new class of incompetent users who are allowing OpenClaw to run completely arbitrary code on their machines with no oversight. We are seeing only the tip of the iceberg of the security breaches that are to come.
  - dmitrygr 7mo ago
    100%
  - mckennameyer 7mo ago
    So basically the attacker and the dev who caught it were probably using the same tools if the malware was AI-generated (hence the fork bomb bug), and the investigation was AI-assisted (hence the speed). Less "tip of the iceberg" and more just that both sides got faster.
ting0 7mo ago
They will certainly get worse. LLMs make it so much easier.
- hxugufjfjf 7mo ago
  Agreed, as proven quite brutally over the last two weeks and especially the last three days.

woodruffw 7mo ago

This is presumably because libc just doesn't change very often (not meaning code changes, but release cadence). But the average native software stack does have lots of things that change relatively often[1]. So "native" vs. not is probably not a salient factor. [1]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor https://en.wikipedia.org/wiki/XZ_Utils_backdoor

everforward 7mo ago
I think that article proves the opposite. > While xz is commonly present in most Linux distributions, at the time of discovery the backdoored version had not yet been widely deployed to production systems, but was present in development versions of major distributions. Ie if you weren’t running dev distros in prod, you probably weren’t exposed. Honestly a lot of packaging is coming back around to “maybe we shouldn’t immediately use newly released stuff” by delaying their use of new versions. It starts to look an awful lot like apt/yum/dnf/etc. I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks.
- consp 7mo ago
  This is the security equivalent of having a better lock than your neighbour. Won't save you in the end but you won't be first. Then again, yours could also be broken and you don't get to tick of that audit checkbox.
- woodruffw 7mo ago
  Per below, xz is also an example of us getting lucky. > I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks. Yes, but this also has nothing to do with native vs. non-native.
dmitrygr 7mo ago
your link disproves your claim. no naive app depended on xz version >= latest. Most sane distros take time to up-rev. That is why the xz backdoor was, in fact, in NO stable distro And not changing often is a feature, yes.

deleted 7mo ago

[deleted]

hrmtst93837 7mo ago

[flagged]

dmitrygr 7mo ago
100% with you. Anything that builds from the first try is 100% malicious. No real software builds without 5-30 tweaks of the makefile. And anything on npm/pip is malicious with a fixed chance that you have no control over, as seen in this attack. But the data remains: no supply chain attacks on libc yet, so even if it COULD happen, this HAS and that merely COULD.
- hxugufjfjf 7mo ago
  None that we know of, just like we didn’t know of the attack on xz until we did.

mr_mitm 7mo ago

Native software? You mean software without dependencies? Because I don't see how you solve the supply chain risk as long as you use dependencies. Sure, minimizing the number of dependencies and using mostly stable dependencies also minimizes the risk, but you'll pay for it with glacial development velocity.

dmitrygr 7mo ago
Slower development velocity but no third-party-induced hacks surely has a market. :)

kryptiskt 7mo ago

Only because C code presents so many juicy security holes by default that it's completely unnecessary to subvert the projects to add them.