On Thu, Sep 26, 2024 at 02:33:51PM +0200, Martin Steigerwald wrote:
> the pterodactyl - 26.09.24, 13:05:59 CEST:
> > > So how do you come to conclusion that a re-install will help?
> >
> > If the problem is in the CUPS browserd (which is enabled at install
> > time), *and* the broswerd does some magic to the router fw that opens a
> > port, a reinstall without the broswerd enabled might be a workaround.
>
> Even then a re-install makes no sense. Stop/uninstall the CUPS browserd
> and be done with it.

I beg to disagree. If one's box has been root compromised (say,
through CUPS browserd, but the method of attack in this scenario is not
important) then *any* and/or *all* executables on the system may have
been altered or have altered behavior. It is catastrophic! For
example, an attacker could replace critical executables on a
case-by-case basis to "cloak" their presence, or jigger the C library
DSO to change many of them at once, or--worse--jigger the dynamic linker
(ld.so) to change the behavior of *all* non-statically linked
executables.

If this were to happen, absolutely *nothing* the system tells the user
from that point on, from running processes to network connections to
software installs/updates can be trusted.

In this scenario, my suggested mitigation is to reinstall the system from
scratch (thus assuring all executables are pristine), disable the suspected
attack vector (CUPS browserd? who knows at this point?), then install
intrusion countermeasures software (like `tripwire' or similar) which will
provide a tremendously high-degree of confidence that all executables and
DSO's remain pristine on a day-to-day (or hour-by-hour if necessary) basis.

Or, one could boot and run the system off a read-only USB stick or DVD,
but this involves a lot more work and is less flexible for the user,
especially if one has a heavily customized system.

> And it does not match what you quoted: They said there is no working work-
> around yet! And with the guess you made it could be CUPS browserd, there
> would be a working work-around.

Forgive my oddness, but I don't believe anything I'm told until I verify
it for myself. Nullius in verba. ("Take nobody's word for it.") Meaning,
perform the experiments for yourself to verify our conclusions. (This has been
the motto of the Royal Society since 1660.) But I am not privy or capable of
investigating this RCE for myself, so all I can do is mitigate on my own
boxen as best as I am able according to my own knowledge. Or learn the
Truth in actual reality from the guru's here on DNG.

> Again: Guessing does not really help regarding security issues. That is my
> take on it. Harden your systems and when there is still something coming
> up that affects you see whether you can find something that is clearly
> actionable.

Agreed. Call the CUPS thing an un-educated guess--just feeling. I am likely
wrong. However, if I leave CUPS running and CUPS is the curprit, what is to
stop a root attacker from entering and inserting something
nefarious in a PC's UEFI firmware? (I curse Microsoft et al for
foisting this UEFI abomination on the world every time I think of it.)

All the tripwires and OS/system software reinstalls won't help then. In fact,
all bets are off until I dig out the spring clips and a rasperry pi and
reflash the BIOS chip myself. Major PITA with no guarantee that it won't
happen again until this RCE is fixed. Call shutting down CUPS is "hedging
my bets". I rarely print anyway.

> If you want something that helps in (almost?) all cases: Shutdown all your
> Linux machines or disconnect all your Linux machines from the network
> completely.

Hehe! :-)

For the purposes I use my boxen, that is unacceptable. I'm hardly
mission-critical, but disconnecting from the net would leave me deaf,
dumb, and blind.

I didn't intend to be so long-winded, but I will always talk shop to no
end if not pressed for time. :) Please read with a light heart.

Regards,

--
"Sometimes a feeling is all we humans^H^H^H^H^H pterodactyls have to
go on." -- Capt. Kirk, "A Taste of Armageddon"