[tlug] Dealing with software with wide attack surface

["Stephen J. Turnbull" <stephenjturnbull@example.com>]

Christian Horn writes:

 > I am wondering how you deal with software with a big
 > attack surface, or to which degree you care.

I've thought about it, but don't worry about it, since the server
doesn't know where sources live (no real data at risk), and with the
exception of Mediawiki which I don't really understand or trust but
isn't easily visible from the Internet, everything is well-maintained.
The problem with Mediawiki isn't Mediawiki itself, it's that I need
some third-party modules to do some of the stuff I want to do
conveniently, and they regularly fall out of maintenance and then a
year later out of compatibility.  Wikipedia is of course one of the
biggest sitting duck targets on the web, so I trust them to keep the
stuff they need up to snuff, but if it's not essential, I don't see
how I can trust it.

I may start worrying about it in the near future but that's more for
fun and profit than this particular host.

 > I'm in the market for alternatives, and looked at 2 of them:
 > https://pixelfed.org/ and https://github.com/LycheeOrg/Lychee .
 > Especially Lychee seems good, I like the style of presentation
 > more than what fgallery (from 2016, no longer developed) does.

I guess the question is how frequently Lychee is releasing and/or
patching, and how much they participate in upstream maintenance.  If
they're a small project cobbled together from 113 other small
projects, yeech.

You write

 > Since years I use scripts/software to make images available over
 > the internet.

That's not very much to go on.  If it's just a browsable archive of
*your* images, you can just shut off everything except GETs of images
that exist, and maybe allow thumbnails.  Push everything else into the
Javascript on the browser, and it's Someone Else's Problem.  But I
doubt that's what you mean.  If you're running a private
Instagram-like social network that would be an entirely different
worry.

Also, you write

 >   - an extra KVM guest (but that would mean I need an additional
 >     instance, so pay and maintain it).

What else is on the host that you're worried about?  Maybe Lychee
would be the least of your worries. (^^;

 >   - a container.  Means I need no extra KVM instance, but 
 >     container separation is not meant to be for security.

No, it isn't, but breaking out of a container and then hacking other
containers or the host OS makes things quite a bit more difficult for
most opponents.  They may give up and go for a site that's more wide
open, or you may slow them down enough to detect them and kick them
out before they do real damage.

Darren Cook writes:

 > The other angle is that each of those open source modules could be
 > quietly taken over by hackers, and bad code quietly inserted; and
 > here more modules is worse. There are known real-world attacks like
 > this against npm (JavaScript) modules.

It's been tried against Python, at least the package-name-typo attack
has (many times), and I think the "infiltrate or take over the name of
a defunct project" attack has happened at least once in the wild.
It's kinda scary since

 > audit all the code, then never upgrade. The first part of that
 > suggestion is impractical,

is the way everybody feels about code audits (especially developers).

Steve