Supply Chain Attacks on Linux Distributions – Fedora Pagure
fenrisk.com
fenrisk.com
As a result of this, git and rsync wont work at all if the bashrc on the remote machine writes any data to stdout. Like setting a window title.
To work around that, every bashrc on this earth needs a case switch to return early to avoid this specific bug.
cmd foo
cmd ["/bin/foo"]
If you need to pass data through ssh you're better off doing it through stdin.
Git actually has a solution for this! I don’t know if it would work with the custom python stuff going on, but you can set the login shell to `git-shell`
Heck, just true the public key as the authentication header.
Or use authentication certificates.
If ssh is such a big problem, use something else
Traditionally both facets of the 3rd party trust model have had CVE over the years. SSL protocol misconfiguration is also very common, and connections can be downgraded by adversaries into a vulnerable version of the protocol.
It could be argued ssh is a weaker Trust on first use model, but in most cases the keys will rarely change for the short service life of the server instance... and the server may be setup from a local physical terminal, and keys communicated out-of-band to remote users.
At some point one has to admit if someone really wants in they will physically pull the drive in the data center. However, people using web vulnerability scanners on your systems are less of a nuisance.
Best regards =3
That is but an optional aspect of the configuration (albeit by far the most common).
Couldn't you use your "traditional" SSH keys to generate an ephemeral self-signed client certificate which shares the same keypair as your SSH key? That would at least solve the CA issue for the client-to-server authentication.
One should not completely trust TOFU over remote sessions, but it is the most practical solution. This is the inconvenient secret of cloud technology, and why the hosting company web panels often include abstracted firewall/vpn settings or proprietary key management (or the same authoritative problem manifests.)
Good luck, =3
It's not a problem. You can use SSH today (and since years already now) with Yubikey and the likes. I'm using Git over SSH with Yubikeys and it works.
Use Git over SSH, use a Yubikey (or whatever suits you), set the login shell to git-shell.
Reuse of an existing key for any reason after enrollment is not a good idea. A reluctance to just enroll another key may mean trouble with key rotation and revocation, and thus problematic security procedures. Key rotation should be fast, painless, and regular.
1. Does it ever expire?
2. What would you do exactly if you were to lose the hardware key? Same thing as if you lost your id_ed25519 file?
> Key rotation should be fast, painless, and regular.
I agree. Right now I keep changing the expiry date of my GPG keys (once in a good while).
2. If you lose a key, whatever its nature, you unenroll it where you have it enrolled. You better have some one-time codes set up, or another alternative method, like a password login to your VM via console.
Combined with port-knocking and fail2ban, the setup has proven rather reliable over the years. The Go language can make surprisingly resilient servers if you have the memory available.
The ssh key handling in gitea requires manual setup, and thus does not necessarily even have to use the same administrative user login key sets.
Best regards =3
It won't be long before that hardware device that is supposedly being held by a person becomes a soft device, which will then be impersonated.
There's a number of problems with the idea:
- The device (eg. Phone or Tablet) gets owned and gives up its value as a provider of confirmation
- Users end up nominating a password service like 1Password as the device
- Someone manages to convince the authentication systems that their faux device emitting the signal, is the device in question
For the second point, when I was integrating a (FOSS) passkey system into a product, it drove me up the wall having to have my phone right next to me every time I was working. I ciouldn't leave it in the next room on charge, for example.
As a user I drew no comfort from the system, and viewed it as a burden, and was concerned about replacing the device in the event of a loss/theft or destruction - which is usually the pathway malicious individuals take to insert their device as the one to be used instead of the original.
At a certain point, the user behavior IDS constraints become more important than building a deeper moat. 2FA cellphone based anything is $23 away from some adversaries control... ultimately more security theater in my opinion YMMV =3
Any device could get exploited. The requirement that it happen to both that device and my computer, simultaneously, significantly raises the difficulty bar.
> Users end up nominating a password service like 1Password as the device
I don't see the issue. Isn't that the user's choice to make? If you want better security then don't make that particular choice.
> Someone manages to convince the authentication systems that their faux device emitting the signal, is the device in question
By that logic why have passwords or keys or anything at all? Someone might exploit the server and get in regardless so why bother?
I've got at least a few objections to modern auth schemes but these aren't them.
Yes.
> The requirement that it happen to both that device and my computer, simultaneously, significantly raises the difficulty bar.
Well, only one of the two devices needs to be exploited. There's twice the attack surface for you.
> I don't see the issue. Isn't that the user's choice to make? If you want better security then don't make that particular choice.
Sure, and allowing people to use "password" as their password is bad, but the design of this system encourages using a "cloud" device, because of the issues already pointed out.
> By that logic why have passwords or keys or anything at all? Someone might exploit the server and get in regardless so why bother?
The system has added nothing that makes passwords or keys more secure.
> I've got at least a few objections to modern auth schemes but these aren't them.
/me shrugs
I'm almost at the point of caring.
I think we must be thinking of very different things here. Maybe I misunderstand the scheme you're objecting to. Would you mind elaborating?
As I already stated I'm no longer certain what scheme we're actually taking about. Is there some reason you don't feel like elaborating?
For my part I thought we were taking about a proof of possession scheme in addition to regular auth. The "regular auth" scheme was unspecified so could be password, software based TOTP, hardware token, whatever.
Widespread proof of possession already exists in the form of chips in bank cards. It seems to be quite resilient to attack in practice.
Even if I use software on my phone for proof of possession you still have to compromise the computer I'm actually logging in with, no? So the attack surface is either the same (primary device) or increased (primary plus secondary, simultaneously) depending on various practical details regarding implementation and usage.
If the "regular auth" scheme involves a half decent hardware token then good luck compromising that remotely. I won't be betting in your favor.
Perhaps what you had in mind are the PoP tokens from RFC 7800? (Sure would be nice not to play guessing games though.) Given that those are intended to replace OAuth bearer tokens they are quite a decent upgrade from a security perspective. Used with a purely software based password manager it is no longer enough to simply exfiltrate a token from the browser. Used with TPM backed keys it is approximately equivalent to the chip in a bank card.
Because I get to talk to people that actually understand technical discussions.
> How could I possibly demonstrate lack of understanding when you actively avoid clarifying what you're even talking about in the first place?
You came into the thread with no understanding, then some time later decided to play word games.
All of the rest of your contributions from now are going straight to /dev/null where they belong.
You don't need anything special to do that. Just select a hardware token that refuses to sign anything until it receives physical input from you.
If you're really dogmatic about it, I guess you would have no dependency lock files either, but commit all that code directly to git instead of having references. Some people do that, so wouldn't be a huge surprise.
It also may mean that git-shell could use a few PRs adding whatever is missing for git-lfs to work, given that git-lfs does not do anything extra fancy.
Thinking generally it seems something like the xz/lzma vulnerability could be snuck in by 1-2 nefarious people colluding across packaging and package producing, especially if we are talking about nation-state actors who can afford to look legit for years before being trusted to work without oversight - then when no one is watching, sneak in a backdoor.
I feel we are in a very innocent age and will look wistfully back at the days we trusted our anonymous open source brethren.
On macOS I think about this every time I “brew install”, and every time oh-my-zsh auto-updates. Do Linux users think about this?
I'll just enumerate my random thoughts
* If you're worried about nations, remember that they can, quite literally, send ninjas-in-attack-helicopters at you.
* Most nations already have "laws" that "require" you to provide passwords/data access on demand[4ab].
* If you use any "cloud", there's a high likelihood that they're already backdoored, either through legal means (i.e. through National Security Letters) or "not so legal, but who's going to stop them?" means such as just plain old hacking[1]
* All consumer CPUs already have builtin backdoors that can't really (but kind of, but who really know if it's effective) be disabled[2abc]
* Most printers print secret codes on printed documents that link back to the printer[3]
* I have no control over device firmware and some important drivers. I really don't know what my network card firmware is doing when I'm not using it and it has DMA to my system RAM. I "need" nvidia proprietary drivers to have a decent experience, no idea what they actually do.
* Nearly every piece of software includes some form of "Analytics" or "Telemetry", which often doesn't actually turn off when you click the stupid opt-out button.
[1] https://www.npr.org/sections/thetwo-way/2013/10/30/241855353...
[2a] https://en.wikipedia.org/wiki/Intel_Management_Engine
[2b] https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo...
[2c] https://en.wikipedia.org/wiki/ARM_architecture_family#TrustZ...
[3] https://en.wikipedia.org/wiki/Printer_tracking_dots
[4a] https://en.wikipedia.org/wiki/Key_disclosure_law [4b] https://www.eff.org/wp/digital-privacy-us-border-2017
There seems to be some kind of inflection point of things:
* Enough users
* Enough time
* Enough cost
* Enough financial reward
Eventually, as those things culminate together, there is a loss of the shared value and...innocence(?) of any scene.
I think back to when RMS was aghast at the idea of MIT adding usernames and passwords to their machines in 1977. [1] It's a battle that I still feel bad that he lost against; a kind of presumption of universal access is a thing that I am intrinsically drawn to. It breaks my heart to think that any sort of restriction exists to technological access, in spite of the obvious need for computer security. Think about it - in the modern day, it's not only unthinkable, it's largely impossible to access most computers without some form of locked down authentication - even for publicly accessible computers at libraries! Most Operating System setups are designed with a fundamental assumption that you will be using both, regardless of whether it's a computer shared by 50 people in an office, or a personal laptop in your home, locked room that no other person will ever touch or see.
I sit here and I think about how there was a period where it was simply understood that, you treat computers and that network with a kind of prestige and respect. That you conduct yourself and the things you do in a manner that is good, because you have a desire for that thing to continue being used, accessible, and enjoyable by other people who have that same inner passion - that hunger! That, there did not need to be a threat of some kind of legal consequence - no laws even existed in regards to it. You did so...merely because you grasped that it was right, and you desired to do what was right. You did things right because you had a passion, a care, and a shared common interest among all of those other people to use those systems in a way that was good for all.
Sure, perhaps there were a few jokes and gags. A few fights or arguments over this or that. Plenty of "frivolous" things that could be done like play games and whatnot, but there was a kind of obvious social understanding that you did not do what is bad because it was bad. You wouldn't do bad things for the same reason why you wouldn't stop in the middle of a sidewalk and start using the bathroom in public - because its unacceptable to do so; it was inconsiderate to do so.
I feel like there is a flower of naivety that has wilted with time. It's not quite dead, but so many of its petals have dried up, fallen off, and crushed beneath the boot of financial incentive.
I imagine it to be similar to how the invention of the car must have felt. So much early optimism and obvious benefits. Only to be used to escape police. To transport booze and drugs. To steal from owners so it can be sold for parts. To kidnap children in. To hit pedestrians with. To use in wartime. It's a grim bleakness in life, that all things that can be cherished and enjoyed by the kindhearted, so horribly abused by the malcontent.
[1] https://en.wikipedia.org/wiki/Richard_Stallman#Harvard_Unive...
>Do Linux users think about this?
Yes that's why i avoid packages not in the official distro repositories and where possible further minimize risks by using additional security layer such as sandboxing (flatpak and firejail), mandatory access control (Apparmor or SELinux), virtualization (KVM/Qemu) and application firewalls (Opensnitch).
It is 100% deterministic, hermetic, and reproducible. Also it is full source bootstrapped from 180 bytes of human-auditable machine code, all released artifacts are multi-party reproduced/reviewed/signed, and it is fully container-native all the way down "FROM scratch" making it easy to pin dependency hashes to reproduce your own projects with it.
I started it after years of unsuccessful pleading with existing distros to stop giving ultimate solitary trust to -any- maintainers or sysadmins involved in the project.
Unlike StageX, Nix has a wikipedia-style low friction approach to packaging allowing a large community to maintain a huge number of packages which are signed by a central trusted party, while being -mostly- reproducible. It relies on a custom language and toolchain for packaging. Nix is designed for hobbyists seeking to reproduce their own workstations.
Unlike Nix, StageX is 100% reproducible and all changes are independently signed by authors and reviewers, then artifacts are reproduced and signed by multiple distributed maintainers. It is also full source bootstrapped, and is built on the broadly compatible OCI standard for packaging. StageX is designed for production threat models where only compiler and infrastructure toolchains are needed and trusting any single person is unacceptable.
One maintainer even uses Nix as a workstation to contribute to StageX. They have fundamentally different goals and use cases.
This might displace chainguard as my goto docker images :-).
It looks like there is some prior work in this area, but it hasn't resulted in commonly available implementations (even something basic like a type/taint checking version of exec() etc. on one side and getopt() etc. on the other.)
Maybe a Rust alternative ?
Writing code that you barely understand is a surefire recipe to have /no clue/ how to debug said code (because debugging it will be more complex).
(let alone audit it for correctness/security).
This is looking more and more like hardware solutions are becoming more attractive.
2. If we are worried about Trusting Trust, then Rust is worse; at least C has the wide range of compilers needed for diverse double-compiling and as of https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-... we arguably have a working solution. Rust only has a single compiler, and that compiler is used to build itself, making it the poster child for Trusting Trust targets.
;-(
—- disambiguates revisions and paths in some commands so another option was needed.
Now I want an operating system where everything is a YANG model...
I legitimately wanted to get a package into Fedora a few years ago, a service that did not exist already, and I couldn't get past the fact that they require new contributor accounts to be sponsored by someone already a contributor. I was unable to secure sponsorship by anyone and just gave up.
Despite the amount of brilliance here, again, we never have had a single meet and greet.
It was amazing to hear that they chose the weakest path, argument injection and were able to found a vector in two weeks twice (fedora + opensuse).
This is the risk you take