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

[Gordon Tetlow]

> 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