[lug] PCI-DSS followup thoughts

[Bear Giles]

I was pretty busy when the discussion came up earlier but I wanted to add a
few add'l thoughts.

1. It's a cheap trick but set the 'immutable' extended attribute on
everything under /usr, /bin, and /lib. It won't stop a knowledgeable
attacker but will stop some.

It makes software upgrades (which should only be security upgrades) a pain.
I know package managers usually have extension points that allow you to run
code before and after installation - it could possibly clear the immutable
flag on all files within a package (if present) pre-installation and set
them post-installation. Maybe someone has already done this.

That said you'll often find surprising undocumented implementations. E.g.,
for a while I mounted /tmp as noexec,nosuid. Sounds great but some packages
created and executed scripts in /tmp. I tried remounting /tmp on entry and
exit but then had problems where I was left in the wrong state. I could
cache the flags on entry but something else might have started running
which also needed the directory mounted exec and/or suid and it would break
if the installed exited first.

2. Debian-based systems store information about the files in a package
under /var/cache/dpkg (iirc). A list of files and md5sums per package.
Again it won't stop a knowledgeable attacker but it's a good first source
for a bit of code to:

- find any unexplained files in /usr, /bin, and /lib
- have a reference MD5 checksum.
- maybe SHA-1 checksums as well - I can't remember if that's been added to
the standard list.

3. Finally a hard-core solution that I was playing with a few years ago.
It's basically the same approach except I started with the .deb package. At
the time they were "ar" archives containing just two files, control.tar.gz
and data.tar.gz (iirc) and the latter is the standard files that should be
immutable. (Control.tar.gz contained config files that might be modified.)
It was easy to write a bit of code that read the .deb file directly,
extracted filenames, checksums, ownership, permissions, etc., from the tar
file, and then compare it to what was on the filesystem. I read local files
but it would be easy to either read them from a read-only filesystem or
download them each time from a local repository.

The latest versions include digital signatures so you can high confidence
that you're looking at the correct files (module anyone screwing up your
list of authorized signers.) However the archive format also changed and I
don't know how easy it is to find libraries to read the new format.

4. All of this assumes a relatively unsophisticated attacker that could not
load a malicious library in the LD_PATH or malicious kernel module. If
those are in play it's easy for the malicious code to return what you
expect to find while actually executing something else. E.g., hiding files,
returning the expected bytes via file IO, etc.

There are some counters, e.g., mmap your files and read the buffer instead
of using the file IO functions, but again that just moves the goal posts
but doesn't eliminate all risk. E.g., one malicious coder might tweak
fopen/fread but not open/read, another might tweak open/read but not mmap,
and a third might also tweak mmap so everyone except for a specific user
calls it/an unusual flag is set/etc.

So, bottom line, there's no guarantees but there are a few options if
you're willing to do a bit of coding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20170905/ba808394/attachment.html>