Re: Security lessons from liblzma

On Fri, Mar 29, 2024 at 7:00 PM Andres Freund <andres@anarazel.de> wrote:
> I am doubtful that every committer would find something sneaky hidden in
> e.g. one of the test changes in a large commit. It's not too hard to hide
> something sneaky. I comparison to that hiding something in configure.ac seems
> less likely to succeed IMO, that imo tends to be more scrutinized. And hiding
> just in configure directly wouldn't get you far, it'd just get removed when
> the committer or some other committer at a later time, regenerates configure.

I agree with this. If I were trying to get away with a malicious
commit, I'd look for files that other people would be unlikely to
examine closely, or would have difficulty examining closely. Test data
or test scripts seem like great possibilities. And I also would like
it to be part of some relatively large commit that is annoying to read
through visually. We don't have a lot of binary format files in the
tree, which is good, but there's probably some things like Unicode
tables and ECPG expected output files that very, very few people ever
actually examine. If we had a file in the tree that looked based on
the name like an expected output file for a test, but there was no
corresponding test, how many of us would notice that? How many of us
would scrutinize it? Imagine hiding something bad in the middle of
that file somewhere.

Maybe we need some kind of tool that scores files for risk. Longer
files are riskier. Binary files are riskier, as are text files that
are something other than plain English/C code/SGML. Files that haven't
changed in a long time are not risky, but files with few recent
changes are riskier than files with many recent changes, especially if
only 1 or 2 committers made all of those changes, and especially if
those commits also touched a lot of other files. Of course, if we had
a tool like this that were public, I suppose anyone targeting PG would
look at the tool and try to find ways around its heuristics. But maybe
we should have something and not disclose the whole algorithm
publicly, or even if we do disclose it all, having something is
probably better than having nothing. It might force a hypothetical bad
actor to do things that would be more likely to be noticed by the
humans.

We might also want to move toward signing commits and tags. One of the
meson maintainers was recommending that on-list not long ago.

We should think about weaknesses that might occur during the packaging
process, too. If someone who alleges that their packaging PG is really
packaging PG w/badstuff123.patch, how would we catch that?

An awful lot of what we do operates on the principle that we know the
people who are involved and trust them, and I'm glad we do trust them,
but the world is full of people who trusted somebody too much and
regretted it afterwards. The fact that we have many committers rather
than a single maintainer probably reduces risk at least as far as the
source repository is concerned, because there are more people paying
attention to potentially notice something that isn't as it should be.
But it's also more potential points of compromise, and a lot of things
outside of that repository are not easy to audit. I can't for example
verify what the infrastructure team is doing, or what Tom does when he
builds the release tarballs. It seems like a stretch to imagine
someone taking over Tom's online identity while simultaneously
rendering him incommunicado ... but at the same time, the people
behind this attack obviously put a lot of work into it and had a lot
of resources available to craft the attack. We shouldn't make the
mistake of assuming that bad things can't happen to us.

--
Robert Haas
EDB: http://www.enterprisedb.com