freebsd security - Apr 2021 - Security leak: Public disclosure of user data without their consent by installing software via pkg

On Apr 6, 2021, at 7:42 AM, Shawn Webb <shawn.webb at hardenedbsd.org>
wrote:
> 
> On Tue, Apr 06, 2021 at 04:39:40PM +0200, Miroslav Lachman wrote:
>> On 06/04/2021 16:27, Shawn Webb wrote:
>> 
>>> 1. BSDStats isn't run/maintained by the FreeBSD project. File
the
>>>    report with the BSDStats project, not FreeBSD.
>>> 2. You install a package that is made to submit statistical data.
>>> 3. You're upset that it submits statistical data?
>> 
>> The problem here is that it collects and sends data right at the
install
>> time. It is really unexpected to run installed package without user
consent.
>> If you install Apache, MySQL or any other package the command / daemon
is no
>> run by "pkg install" command.
>> This must be avoided.
> 
> It's probably easier to submit a patch than it is to write a
> lolwut-type email. All you gotta do is rm the post-install script.
> Also `pkg install` has the -I option. But whatever, let the lolwut
> mentality prevail!
I had a conversation on the side with the requestor. In short, there is already
a patch to address this issue in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251152
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251152>. Not sure why
it hasn't been committed yet, but hopefully it gets picked up shortly.

Gordon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20210406/5262719c/attachment.sig>

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?.
Just because they trustingly installed software from the package repo
hosted by FreeBSD, without religiously-carefully auditing every and
each packages' pre- and postinstallation script before actual install,
using the ?pkg -I? option.

Indeed, I felt very surprised that the ?Security Officer? of ?Hardened
BSD? chimed in, only to publicly demonstrate his lack of competence to
recognize obvious security problems.
Like two fish caught with a single hook!

Are you "Security Officers" aware that you basically are tearing down
any trust that conventional, non-big-corporate users without large own
IT staff can have in FreeBSD?


So, I believe that not only the reasons that made the Wireguard
debacle possible need to be discussed.
This discussion should not occur in hermetic private circles, but in
public places like /r/freebsd, IT news outlets and other competent and
independent media.
Not only Wireguard needs to be discussed, but also things like the
responsibility for software that is not part of the base system, but
nevertheless being distributed by the FreeBSD organization.

Can it be ethically acceptable to put users at risk, for example by
intentionally (?) not setting any limits to what extent installer
scripts are allowed to collect sensitive user and system data and
disclose them to interested third parties?

This should imho be discussed in public, leading to the formulation of
rules which might help enabling users to trust FreeBSD.


[ Just to note: the porter of the package in question wrote me that it
never was the intention to run the scripts without user content. There
must have happened something/some action by someone, which led to this
behaviour. What actually happened, this can be analyzed.
For me, what actually matters is not this particular incident, but the
finding that spyware behavior of pre/postinstaller scripts is
apparently generally deemed acceptable and not actionable, according
to FreeBSD rules. So the problem are these rules, and not this last
incident. ]

On 4/6/21, Gordon Tetlow <gordon at tetlows.org>
wrote:
> On Apr 6, 2021, at 7:42 AM, Shawn Webb <shawn.webb at
hardenedbsd.org> wrote:
>>
>> On Tue, Apr 06, 2021 at 04:39:40PM +0200, Miroslav Lachman wrote:
>>> On 06/04/2021 16:27, Shawn Webb wrote:
>>>
>>>> 1. BSDStats isn't run/maintained by the FreeBSD project.
File the
>>>>    report with the BSDStats project, not FreeBSD.
>>>> 2. You install a package that is made to submit statistical
data.
>>>> 3. You're upset that it submits statistical data?
>>>
>>> The problem here is that it collects and sends data right at the
install
>>> time. It is really unexpected to run installed package without user
>>> consent.
>>> If you install Apache, MySQL or any other package the command /
daemon is
>>> no
>>> run by "pkg install" command.
>>> This must be avoided.
>>
>> It's probably easier to submit a patch than it is to write a
>> lolwut-type email. All you gotta do is rm the post-install script.
>> Also `pkg install` has the -I option. But whatever, let the lolwut
>> mentality prevail!
>
> I had a conversation on the side with the requestor. In short, there is
> already a patch to address this issue in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251152
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251152>. Not sure
why it
> hasn't been committed yet, but hopefully it gets picked up shortly.
>
> Gordon
>

> On Apr 7, 2021, at 7:50 PM, Stefan Blachmann <sblachmann at
gmail.com> wrote:
> 
<snip>
> 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?.
> Just because they trustingly installed software from the package repo
> hosted by FreeBSD, without religiously-carefully auditing every and
> each packages' pre- and postinstallation script before actual install,
> using the ?pkg -I? option.
I do not consider it acceptable that this behavior is occurring. I'll quote
to you what I said in my private email to you:

Running scripts at pre/post-install is a foundational design of packages. These
scripts can do anything a shell script can do. If you are concerned packages
running scripts, I recommend changing the pkg setting:

RUN_SCRIPTS: boolean
                Run pre-/post-installation action scripts.  Default: YES.

Change this in your /usr/local/etc/pkg.conf and you will not have pre/post
install scripts running for your packages.

Another option, instead of changing the global default is to use the pkg install
-I switch, which will not run scripts for that installation.

As for the behavior of this specific package, I agree it is poor that it runs
without user consent. Reading the pkg-install script, it appears it should ask
consent, perhaps it is broken. I recommend taking it up with the port/package
maintainer, scrappy at hub.org <mailto:scrappy at hub.org>, whom I have
added to this email.

I agree this should be fixed and is undesirable. Even the pkg maintainer who is
the person running the bsdstats website is in agreement here. The difference is:
I don't assume the maintainer has ill-will and it is the result of an
oversight that will be fixed. There is a process to be followed and I am not
comfortable wielding the security-officer hammer unless I see visible evidence
the process is broken and requires me to intercede. We aren't there.

<snip>
> Can it be ethically acceptable to put users at risk, for example by
> intentionally (?) not setting any limits to what extent installer
> scripts are allowed to collect sensitive user and system data and
> disclose them to interested third parties?
This is an interesting point. Unfortunately, the technology we have gives
unfettered access to the system. I'm having a hard time thinking how we
could achieve the goal of installing software (which in our model requires root
privileges) while also limiting what it is allowed to do on said system. I'm
not aware of any other package system (rpm, deb, etc) that has technical limits
on pre/post installation scripts. If you are aware of any examples, I'd love
to see it to see if there is something we can incorporate. Patches, as always,
are welcome to improve the system.
> This should imho be discussed in public, leading to the formulation of
> rules which might help enabling users to trust FreeBSD.
> 
> [ Just to note: the porter of the package in question wrote me that it
> never was the intention to run the scripts without user content. There
> must have happened something/some action by someone, which led to this
> behaviour. What actually happened, this can be analyzed.
> For me, what actually matters is not this particular incident, but the
> finding that spyware behavior of pre/postinstaller scripts is
> apparently generally deemed acceptable and not actionable, according
> to FreeBSD rules. So the problem are these rules, and not this last
> incident. ]
I disagree with your premise. For the record, I did take action, which was to
escalate the problem to the port/pkg maintainer. It is their software and their
responsibility. Please do not take my unwillingness to violate the
maintainer's ownership of their port/pkg as unwillingness to deal with the
issue. I'm would like the process to have a chance to work.

Lastly, your combative tone in reporting this issue is far from anything I would
consider professional. I would ask that you give some consideration to your
words in the hopes that you will understand that flaming me on the mailing list
is unlikely to make me want to advocate for you.

Thanks,
Gordon