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
Back in my younger days I wrote a few such patches. Not a lot of people use tripwire anymore!
The old tripwire makes less sense in a world of cloudwalking cattle. Ephemeral containers and VMs everywhere. Machines go up, they go down.
Some of my containers run for weeks between deploys, I’d like to know what changes in ‘em just as much as thay oldskool iaas db server marketing uses ;)
Assuming you are talking about parent/child processes, use the --forest option in ps for an ascii art process tree.
I implemented the --forest option in ps. It can't fully work. The kernel forgets parent-child relationships when processes die. Every orphan is adopted by init, and the kernel doesn't bother to remember the original parent. I've always hated this. Anybody want to fix it? The simple fix, kind of bad, is to simply remember the number and report it. The trouble here is that the number might get recycled. Adding a boolea…
Why can’t Linux keep track of parent-child relationships and visualize them when you look at running processes? You could instantly identify this virus. And why can’t Linux apps have a universal and straightforward install directory?
> 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`.
So, it doesn't makes use of any 0day or exploit to enter the system. Has to be deliberately run. Makes me think of https://www.gnu.org/fun/jokes/evilmalware.en.html
Running something is as easy as hijacking one of those “copy and paste this line into your command prompt to install this package” things you see on many open source sites. The command always curls some bigger script down and executes it. Often times it even has you sudo to root. While it would be prudent to examine the script rather than just blindly execute it... I imagine most don’t (myself included).
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 doesn't truly help in terms of security or side-effects as it can still run scripts, so although ultimately the issue is still running binaries not vetted by your distro's maintainers)
I'm skeptical since you spelled it "herd" (or maybe auto-correct strikes again.) But yeah, keeping your system free from the systemd cancer has always been a good idea.
Maybe "herd" is an actual tool, separate from Hurd? Or "and herd" here is equivalent to "et al?" Impossible to search for though.
Running something is as easy as hijacking one of those “copy and paste this line into your command prompt to install this package” things you see on many open source sites. The command always curls some bigger script down and executes it. Often times it even has you sudo to root. While it would be prudent to examine the script rather than just blindly execute it... I imagine most don’t (myself included).
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…
> 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.
They're fine for security and super convenient. I get why it's so popular - packaging and publishing debs is often going to be a lot more work, and now you're in the world of either maintaining a package repo or having to deal with an official one.
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