Earlier quoted context omitted.
Sure. Just use this one: http://totally-legit-website.com/downloads/linux-systemd-roo...
Should one use the "curl | sh" idiom to install this tool?
Add some sudos in there for good measure.
RotaJakiro: A long live secret backdoor with 0 VT detection
141–150 of 183 posts
Re: RotaJakiro: A long live secret backdoor with 0 VT detection
#142Earlier quoted context omitted.
This technique is really effective when the attacker does a little bit of homework on the system: if it’s a web server, a lot of people (even security analysts) will miss that the 147 httpd process are 146 /usr/sbin/httpd and one /usr/local/sbin/httpd — or they’ll assume that was where someone installed a custom build.
You could set argv[0] too: $ perl -e '$0="/usr/sbin/httpd";fork or sleep 1000';ps
$ readlink /proc/`pgrep /usr/sbin/httpd`/exe
/usr/bin/perlRe: RotaJakiro: A long live secret backdoor with 0 VT detection
#143Earlier quoted context omitted.
> Why can’t Linux keep track of parent-child relationships and visualize them when you look at running processes? Linux does keep track of parent-child process relationships. Linux, however, is just a kernel. It's not your operating system and it's definitely not your GUI. I suggest you look at something like `htop`.
It doesn’t. See below
It does. You're mistaking reparenting with another concept: the concept of an absolute parent PID.
The concept of an absolute parent PID is nonsensical. Having an absolute parent PID would reduce the maximum number of processes effectively infinitely by creating a linked list of parent IDs even if the original parent process is gone.
Imagine if PID 2 is a parent process. It spawns a child. The child spawns a child. That child spawns a child... all the way down to the maximum number of PIDs... the final child is PID n. Then, all of the intermediate processes exit.
The final child process with the maximum PID wants to look at its parent process... but it's gone. Now, what do you want the kernel to do?
Should the kernel tell you about that PID n-1? What if another process has been created and has inherited PID n-1? Does your check now think that the process's parent is still alive? Your check is incorrect and will lead to very aggrevating bugs. Should the kernel prevent PID n-1 from being reused? Congrats you've basically just reinvented zombie processes.
No. The solution is to just reparent PID n onto PID 1 and tell you that process is the parent now. Then you, as a developer, have to actually deal with an aspect of computer science: lifetime management of your objects processes. And the kernel is therefore more efficient for the vast majority of processes who don't need or care about their parent.
Re: RotaJakiro: A long live secret backdoor with 0 VT detection
#144Earlier quoted context omitted.
White side effects does Nix have when you install a package? IIUC it just updates the programs that are symlinked into various locations (like a directory in your $PATH).
If you’re installing from a binary cache, that’s true, but a nix expression is just a build specification: it can run any program available to build and install a package. The “normal” way this works is you install the software to $out and $out gets copied into the nix store, but a malicious nix package can bypass this (and, assuming you’re not using nix’s sandboxing mechanisms, do arbitrary things to your computer).
Building without a sandbox is really pushing the definition of "just installing a package". Also the sandbox is enabled by default on at lest NixOS.
I do admit that this sandbox is likely more for purity than security. Nonetheless while there may be exploits it is quite different than executing an installer or packages that have after-install scripts.
Re: RotaJakiro: A long live secret backdoor with 0 VT detection
#145Earlier quoted context omitted.
I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle as well. I hate the idea of any arbitrary, unknown side-effects happening to my system. Providing an archive `.deb`, `.rpm`, etc is at least more convenient and predictable so it can be installed like a normal package by your package manager (although it does…
As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and makefiles and the various scripts inside Debian packages and RPMs. Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.
> unless you’re the sort of person who reads configure scripts and makefiles
I always read these files before building from source. Is this really so rare? Why wouldn't people read the scripts they're about to run?
> the various scripts inside Debian packages and RPMs
It's reasonable to assume package repository maintainers have ensured their packages are not malicious.
Re: RotaJakiro: A long live secret backdoor with 0 VT detection
#146Earlier quoted context omitted.
As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and makefiles and the various scripts inside Debian packages and RPMs. Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.
> unless you’re the sort of person who reads configure scripts and makefiles I always read these files before building from source. Is this really so rare? Why wouldn't people read the scripts they're about to run? > the various scripts inside Debian packages and RPMs It's reasonable to assume package repository maintainers have ensured their packages are not malicious.
But, we’re talking about installing software from non-distribution sources. E.g. the Minecraft Launcher ships as a .deb that you install: there’s no benefit security-wise for that over curl … | sh
And, I doubt most people have the time or ability to read all the scripts that come with large software packages and ensure that they’re safe. For better or worse, executing code downloaded from the internet without verifying it manually is the norm these days.
Re: RotaJakiro: A long live secret backdoor with 0 VT detection
#147Earlier quoted context omitted.
I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle as well. I hate the idea of any arbitrary, unknown side-effects happening to my system. Providing an archive `.deb`, `.rpm`, etc is at least more convenient and predictable so it can be installed like a normal package by your package manager (although it does…
As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and makefiles and the various scripts inside Debian packages and RPMs. Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.
curl'ing is not the same at all as running, say, a Debian apt-get install.
You apt-get signed packages coming from official mirrors (at least I do). Most of the Debian packages, by very far, are also fully deterministic and reproducible. If someone serves a backdoored package, that's probably incredibly noisy, leaving lots of traces everywhere and evidence can be gathered.
When you curl, there's no way to know if you're the "lucky" one to get served malware by the server on that one curl call.
This is completely different.
Re: RotaJakiro: A long live secret backdoor with 0 VT detection
#148Earlier quoted context omitted.
If you’re installing from a binary cache, that’s true, but a nix expression is just a build specification: it can run any program available to build and install a package. The “normal” way this works is you install the software to $out and $out gets copied into the nix store, but a malicious nix package can bypass this (and, assuming you’re not using nix’s sandboxing mechanisms, do arbitrary things to your computer).
Building without a sandbox is really pushing the definition of "just installing a package". Also the sandbox is enabled by default on at lest NixOS. I do admit that this sandbox is likely more for purity than security. Nonetheless while there may be exploits it is quite different than executing an installer or packages that have after-install scripts.
We aren’t really talking about installing packages from official distributions, right? We’re talking about things like installing an interesting tool from GitHub using the ability of nix to download an build master.tar.gz. In most of these cases, there’s always going to be some amount of reliance on the assumption that the developer of the software is trustworthy.
Also, I mainly use nix on Mac, where the sandbox is disabled by default and doesn’t work as well as the Linux sandbox, by all accounts.
Re: RotaJakiro: A long live secret backdoor with 0 VT detection
#149Earlier quoted context omitted.
As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and makefiles and the various scripts inside Debian packages and RPMs. Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.
curl'ing is not the same at all as running, say, a Debian apt-get install. You apt-get signed packages coming from official mirrors (at least I do). Most of the Debian packages, by very far, are also fully deterministic and reproducible. If someone serves a backdoored package, that's probably incredibly noisy, leaving lots of traces everywhere and evidence can be gathered. When you curl, there's no way to know if you…
In this context we’re not talking about .debs from an official repository
PPAs and debs downloaded from a GitHub release page have all the same problems as curl | sh
Re: RotaJakiro: A long live secret backdoor with 0 VT detection
#150This is pretty noisy as backdoors go. I wouldn't call this stealthy. It places a whole bunch of files in various locations, is running as a separate process, and doesn't do https properly. It's surprising really - when LD_PRELOAD'ing your malware into an existing process is way stealthier. Preferably one that nobody will bat an eyelash at for making TCP connections. The best ones will probably hide in (places such as…
It depends on what you consider stealth. This is the equivalent of someone social engineering their way into a building by looking like an employee. Are they using stealth? By the definition of the word, I think so.
> Anyways. This isn't 'stealthy'. Not at all. It's hardly the bare minimum.
It's using techniques to encourage people and systems overlook it when it's noticed. I think that qualifies.