[HN Gopher] We've learned nothing from the SolarWinds hack
___________________________________________________________________
We've learned nothing from the SolarWinds hack
Author : dvfjsdhgfv
Score : 67 points
Date : 2023-11-13 21:56 UTC (1 hours ago)
(HTM) web link (www.macchaffee.com)
(TXT) w3m dump (www.macchaffee.com)
| LtWorf wrote:
| > "We should sign and verify all our dependencies"
|
| pypi: "YOLO, let us deprecate signatures!"
| esafak wrote:
| If pypi won't let you add signatures, can you generate one of
| your own (for internal use) using a repository manager like
| jfrog, operating as a pypi proxy?
| hiatus wrote:
| New signatures cannot be uploaded to pypi
| https://blog.pypi.org/posts/2023-05-23-removing-pgp/
| LtWorf wrote:
| They email me at every upload telling me to stop sending
| them my archaic signature.
|
| It seems the focus now is more to keep the secrets on
| github and authenticate with those.
|
| https://discuss.python.org/t/2fa-usability-on-pypi-and-
| with-...
| api wrote:
| The sheer amount of eggs in the GitHub basket is
| absolutely terrifying to me. If something happens to that
| thing, the entire computing world will halt.
|
| It reminds me a bit of what the journalism world did by
| becoming so reliant on Twitter for sourcing and
| communication, but in our case I think it's deeper and
| worse. We've hard coded GitHub into countless systems.
| I'd venture to say that most CI systems, package
| managers, build farms, etc. would break.
| LtWorf wrote:
| Debian would keep working :D
|
| And at work my team uses a mirror on LAN. The other teams
| on the other hand...
| LtWorf wrote:
| I use .deb packages mostly rather than pip.
|
| Signatures are checked if present, at least.
|
| Also packages that stop working because python removes stdlib
| modules that they use, tend to get found and patched in
| distributions. In pypi if they are abandoned, they will be
| unusable for all eternity.
| chha wrote:
| Not sure about jfrog, but Sonatype does something similar.
| They basically hash all components/packages from a bunch of
| different repositories, and then tag the hash with various
| metadata you can use to create policies.
|
| I started using this in my org a couple years back, and we've
| ended up using it to check commercial software as well just
| to get an overview of known components, vulnerabilities and
| things to watch out for.
|
| I really wish the big repositories would invest more in
| useful mechanisms; when we looked into this before making our
| decision, the only repository with any kind of checking was
| Maven Central. Nuget had support for author signing and
| repository signing, and Pypi (at the time) author signing. As
| far as I remember none of the other repositories had any
| verification of anything including the git repo, so you
| couldn't even determine what commit hash the code was based
| on or who was behind it.
| lijok wrote:
| > There is absolutely no way we can perform a full binary
| analysis of every new version of every binary blob that powers
| modern IT
|
| I wonder if there's enough demand for a service like this to be
| viable. Bundled with a universal package manager, signed and
| verified binaries, caching mechanisms, etc.
| throwawayapples wrote:
| I'd settle for a source analysis and reproducible builds for
| just our myriad open source dependencies. All it takes is a
| single developer to be compromised in the thousands throughout
| a typical stack..
| hotnfresh wrote:
| Making and maintaining a universal package manager then getting
| it deployed completely enough at any large org to make a
| difference strikes me as on the order of "let's build a
| perpetual motion machine that's also a fusion reactor" as far
| as feasibility level.
|
| ... now, that doesn't mean one couldn't make money while
| utterly failing to ultimately deliver the promised value.
| ryukafalz wrote:
| I'm sure there's enough demand for someone to sell a service
| that attempts this, but for several of the reasons mentioned in
| the post I expect it would be ineffective.
|
| When you run all your code and all its dependencies with full
| authority, it only takes one tiny piece of malicious code to
| blow the whole system wide open. I think scanning will always
| be a losing battle.
| lrvick wrote:
| Working on this right now.
| debatem1 wrote:
| Oh?
| neilv wrote:
| A deeper root cause arguably of this and countless other security
| incidents involving software:
|
| https://xkcd.com/2030/
|
| > _I don 't quite know how to put this, but our entire field is
| bad at what we do, and if you rely on us, everyone will die._
| nuc1e0n wrote:
| Putting all your eggs in one basket sure saves money as don't
| need to buy extra baskets :P
| 1970-01-01 wrote:
| >The Inconvenient Truth about how to actually fix this
|
| The security game is just too fast paced for a profitable
| business. Until we reach the point where it makes financial sense
| to move slowly and take extra time to ensure critical business
| systems are secure, nothing will be fixed.
| LtWorf wrote:
| You mean we should make companies pay hefty fines
| AndyMcConachie wrote:
| We need to recognise that features bring bugs, and if we want
| fewer bugs we need to settle for fewer features. Same goes for
| security bugs as well.
|
| You can have devs work on bug fixing or you can have them work
| on features. Whichever brings in more money will be
| prioritized.
| spaceribs wrote:
| > If we could agree on a good, standardized capabilities model
| for software and everyone starts using it, we will have reached
| security Nirvana.
|
| I want to get there, but I also don't trust anyone except (maybe)
| myself to determine what capabilities are "good" versus "bad".
|
| I literally just spent most of today messing with my 2018 Samsung
| TV trying to get rid of the bloatware they pre-installed removed.
| I had to do that because the apps took up 96% of the storage
| within. These apps cannot be deleted normally.
|
| If we're heading towards a place where vendors are the ones
| deciding what users are allowed to do, as well as what the
| software is allowed to do, and at what level of granularity, I
| have no reason to trust them any more than I trust a russian
| state-sponsored hacker.
| jk_i_am_a_robot wrote:
| "I literally just spent most of today messing with my 2018
| Samsung TV trying to get rid of the bloatware they pre-
| installed removed."
|
| Can you elaborate?
| gjsman-1000 wrote:
| > If we could agree on a good, standardized capabilities model
| for software and everyone starts using it, we will have reached
| security Nirvana.
|
| That's about as likely as everyone agreeing on a good,
| standardized operating system architecture, API, and driver model
| that also happens to be Written In Rust(tm) for good measure.
| dheera wrote:
| > Some people carry around headphones, smartwatches, etc - but
| some don't carry any devices at all (or keep Bluetooth off on
| their phone).
|
| I wonder if one could do better by using a HackerRF and spy on
| LTE+WiFi communications. You wouldn't need to decrypt them, just
| identify how many different devices there are.
| Terretta wrote:
| _Over time (particularly since iOS 6), less and less permissions
| have been granted to iOS apps by default, instead requiring apps
| to request those permissions from users explicitly. It 's still
| not perfect (like access to contacts still being a binary
| "yes/no"), but every permission clawed back from the default set
| required breaking backwards compatibility, a phrase rarely
| uttered in regard to the Linux and Windows kernels._
|
| _If you have been an iOS developer since 2012, I 'm sorry you
| had to go through that, but your extra work has been profoundly
| important to the privacy and security of mobile OSes. I'd like to
| see that same principled energy brought to desktop and server
| OSes._
|
| Or, demand the EU let you side-load so you don't have to bother.
| orf wrote:
| Side-loaded apps still have the same permission model?
| marcosdumay wrote:
| We are still installing obscure binary-only datacenter-wide
| software with full system permissions for security reasons, and
| powerful organizations still require that from third parties.
|
| If we can't change _that_ , what hope we have for a sane small-
| kernel capability-based system?
___________________________________________________________________
(page generated 2023-11-13 23:00 UTC)