Security leak: Public disclosure of user data without their consent by installing software via pkg

[Kyle Evans]

On Thu, Apr 8, 2021 at 8:35 AM Chris BeHanna <chris at behanna.org> wrote:
>
> On Apr 7, 2021, at 8:50 PM, Stefan Blachmann <sblachmann at gmail.com> wrote:
> >
> > The answers I got from both "Security Officers" surprised me so much
> > that I had to let that settle a bit to understand the implications.
> >
> > Looking at the FreeBSD Porters' Handbook
> > [https://docs.freebsd.org/en_US.ISO8859-1/books/porters-handbook/pkg-install.html],
> > it describes the purpose of the package pre- and postinstallation
> > scripts as to "set up the package so that it is as ready to use as
> > possible".
> >
> > It explicitly names only a few actions that are forbidden for them to
> > do: "...must not be abused to start services, stop services, or run
> > any other commands that will modify the currently running system."
> >
> > Anything else is apparently deemed “allowed”.
> > Spying out the machine and its configuration, sending that data to an
> > external entity – perfectly OK. Not a problem at all.
> >
> > This has been proved by the handling of this last BSDstats security
> > incident, where the FreeBSD “pkg” utility is being abused to run
> > spyware without the users’ pre-knowledge and without his content.
> >
> > This abuse is apparently being considered acceptable by both FreeBSD
> > and HardenedBSD security officers.
> > Instead of taking action, you "security officers" tell the FreeBSD
> > users that it is their own guilt that they got “pwnd”.
>
>         This is an incredibly dishonest summary of their responses to you.  Gordon in particular wrote that it is NOT acceptable; however, rather than smash down the port's maintainer with the Security Officer sledgehammer, he preferred to give the maintainer some time to address the problem.
>

+1. Both of these reactions are way out of proportion, and Gordon's
response was 100% the right thing to do. By his own admission he
responded and looped in the port maintainer to the additional context,
which is how it should be handled. If so@ smacked everyone that
intentionally or unintentionally (as the case is here, clearly) did
something that secteam's attention was raised to, then we would end up
with a security officer that nobody on the project is willing to work
with and their job becomes that much more difficult.

Thanks,

Kyle Evans