Re: Security lessons from liblzma

On Fri, Apr 05, 2024 at 11:40:46AM -0700, Jacob Champion wrote:
> On Fri, Apr 5, 2024 at 6:24 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I'm also sort of afraid that we're getting sucked into thinking real
>> hard about this SSL certificate issue rather than trying to brainstorm
>> all the other places that might be problematic. The latter might be a
>> more fruitful exercise (or maybe not, what do I know?).
>
> +1. Don't get me wrong: I spent a lot of time refactoring the sslfiles
> machinery a while back, and I would love for it to all go away. I
> don't really want to interrupt any lines of thought that are moving in
> that direction. Please continue.

There are a few things that I've not seen mentioned on this thread.

Any random byte sequences included in the tree should have ways to be
regenerated. One problem with xz was that the binary blobs were
directly part of the tree, with the input file and the test crafted so
as the test would skip portions of the input, one line in ./configure
being enough to switch the backdoor to evil mode (correct me if I read
that wrong). There could be other things that one would be tempted to
introduce for Postgres as test data to introduce a backdoor with a
slight tweak of the source tarball. To name a few:
- Binary WAL sequences, arguing that this WAL data is useful even with
alignment restrictions.
- Data for COPY.
- Physical dumps, in raw or just SQL data.

Anything like that can also be used in some test data provided by
somebody in a proposed patch or a bug report, for the sake of
reproducing an issue. If there is an attack on this data, another
contributor could run it and get his/her own host powned. One thing
that would be easy to hide is something that reads on-disk file in a
large dump file, with something edited in its inner parts.

An extra thing is if we should expand the use of signed commits and
potentially physical keys for committers, provided by pg-infra which
would be the source of trust? Some have mentioned that in the past,
and this could reduce the risk of committing problematic code if a
committer's host is powned because the physical key would be required.

Saying that, my spidey sense tingles at the recent commit
3311ea86edc7, that had the idea to introduce a 20k line output file
based on a 378 line input file full of random URLs. In my experience,
tests don't require to be that large to be useful, and the input data
is very hard to parse.
--
Michael