I don't condone using a replacement voice with bad intentions,And this is clearly what it is.
However!
With this mentality, the mentioned paid voice actresses voice is not hers anymore because another one's voice is similar and it's used in a movie? So she can't work and voice any other work without Scarlet Johansson's permission?
If your goal is to get in as many homes as possible but also not pay for it, convincing the government it's a basic necessity seems to be a way to do it.
Yes there were very serious software written in different Basic dialects.
One that I was interacted with was a CAD software written in QBasic. It was about civil engineering and static analysis tool for concrete buildings. You could export projects to dxf format so you could import into AutoCad to fix bugs and plot.
Funny how the name was MGCad and author insisted it stood for MegaCad. I suppose It was a nice coincidence that the Author's initials were MG :)
The paper was written by Dijkstra, and even he doesn't like how it's become some kind of mindless mantra, instead of a warning against spaghetti code which it was. He never meant that you should never, ever use GOTO.
Wouldn't dlopen make you more vulnerable to runtime library attacks? Instead of having dependencies defined at the build/start up time, they will be loaded at runtime on demand. So the dependency library could be changed at any time and you wouldn't have any idea what code you are loading at this time?
So upgrading XZ could even attack already running sshd too?
I would be more inclined to have static linked libraries instead of having lazy loading of them for preventing this kind of attacks..
> So upgrading XZ could even attack already running sshd too?
With the specifics of how the xz injection attack worked, actually it wouldn't. libsystemd would have been loaded to implement the service-started notification, and then there is no reason to use anything further and therefore nothing to trigger the loading of the xz library.
Which is kind of the point of this change: the goal is to load libraries on-demand instead of eagerly, so if there is nothing demanding the library load, the library is never loaded.
Lazy loading would have achieved the same thing with less codebase churn. However, the `dlopen()` thing means that the dependencies are then optional as far as the packaging system go, and therefore you can run with fewer dependencies installed. Also, lazy loading can be turned off with an environment variable -- we would need a way to indicate that a dependency is optional in order to have something like always-lazy loading for it.
There's also "filters" and "auxiliary filters", which can be used to make dependencies optional without having to go to `dlopen()`. However, IIRC filter functionality is very bare-bones or non-workin in the Linux link-editors and ld.so.
Loading at runtime is a feature. You're supposed to lock down the environment for execution so the right libraries get used. The trouble with statically linking is that you have to relink everything to update. You also can't easily audit which versions are in a binary. It seems appropriate for some small userspace programs but not for complex software like services with many dependencies.
This seems a bit nitpicky: you just move the threshold for where you might load a backdoored library from first exec to first use which dlopens that library (which might even just be at exec anyway, I haven't checked the source to see how systemd handles it). I think the focus on the specific means that the xz backdoor used to get into sshd is misdirected: it's code that is run in all kinds of priviledged contexts and has thousands of different ways to turn that into RCE. If sshd didn't load it directly the developers of the backdoor would have simply taken a different route.
It's like security 101. If a system has been infiltrated, you can't trust any part of it. So it's better to discard any part that has been reached or possibly affected.
Perhaps it's the correct action to distrust xz/lzma or any source code this team has control over and switch to alternatives. If there are no alternatives, to start ones.
Hiding more backdoors in the library would only increase the risk of getting discovered. Care is certainly advised on the source level, but I'd leave the paranoia to the state of systems where the code has run.
From the attackers' perspective, what they'd want to do is use their project infiltration success as little as possible, only enough to squeeze in other backdoors completely unrelated to xz. But that's all operations, not development.
What are your definitions of 'system' and 'any part'? Any big company has been breached at some point. They don't throw away all their hardware everytime, even though it was connected. You have to draw the line somewhere.
You're assuming a world with separate hardware and software. That's not the case any more. We have closed sourced firmware running anywhere and no way to verify what's running.
Sure that's a problem for threat assessment process. And I totally agree in today's world software/hardware and wetware are too interconnected. And that's another threat for this kinds of attacks.
In this case, is the whole git repo a threat? Or are just the manually created distribution files? Threat actors' access reach defines that. As time passes by we see that reach is not too limited. They even reached to other software with patches too. So that assessment should be done.
They just added an example to the documentation[0] of how to implement the sd_notify protocol without linking to libsystemd, so a little bit of discarding systemd (or at least parts of it) does seem to be part of the solution.
People have been bandying about "10 lines of C", but I'm curious if you know why the protocol is not "2 characters" of shell, namely ":>PATH" (ok, ok, PATH is probably something like /run/serviceName/I-B-ready). At the user (i.e. service daemon) -level this seems much simpler. (EDIT: and systemd would unlink the file as soon as it "gets the message", of course.)
There's just a 40 year culture of using some "official" lib to implement socket protocols - even if the docs suggest you roll your own. I feel like file creation escapes that "reach-for-the-official-lib TCP/UDP/datagram" culture.
It's probably not harder for systemd either if they just use/require the Linux inotify and incorporate that into its select or poll or whatever. I mean, if they wanted to be portable to non-inotify kernels some timeouts/stat-loop would be an ok fallback that would probably be rarely-to-never needed.
It sounds like it's not even hard to add this simpler channel in after the fact just as an alternative option for `whateverd` and then deprecate the datagram one for 10 years (if they even care to).
If there is a known good copy of the repo from before the attacker had sufficient access to alter history, then that is an acceptable starting point.
From there you look at each update since and assess what they do to decide if you want to keep (as they are valid improvements/fixes) or discard them. If some are discarded, then later ones that are valid may need further work to integrate them into the now changed codebase. Similar to Debian assessing upstream security patches to the latest version to possibly back-port them to the version they have in stable, when there is significant disparity (due to a project being much faster moving than Debian:Stable).
As xz/xzutils is a relatively stable package, with very few recent changes, this should be quite practical. A full rewrite shouldn't be needed at all here.
> If there is a known good copy of the repo from before the attacker had sufficient access to alter history, then that is an acceptable starting point.
I heard someone calling themselves “Honest Ivan” has just the thing, totally trustworthy.
Given how spread the copies could be, and that we know when the bad actor gained the level of control needed to upset history, or if we want to go further back when that user started making contributions, it is likely that by comparing many claims we can prove to a reasonable level of assurance¹ that a given version is untouched in that regard.
Furthermore the original main maintainer seems to have a repository with an untouched lineage. While true paranoia says they can't be trusted without verification (he could be under external influence, as could anyone) I think we can safely give their claims more credence than those of Honest Ivan.
--
[1] to the level where a clean-room implementation is not significantly less likely to be compromised by external influence with bad motives.
