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

[Mike Kelly]

On Wed, Apr 7, 2021 at 11:37 PM Gordon Tetlow via freebsd-security
 wrote:

> 
> > 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.

For what it's worth, there is some "prior art" in other package
management systems for various levels of technical restrictions:

* Gentoo's Portage uses a library called "Sandbox"[1], which uses the
LD_PRELOAD mechanism to put it self "first in line", and it intercepts
various lower level calls that way to mitigate risk.
* Exherbo's Exheres packaging format (derived from Gentoo's) has their
own sandboxing mechanisms[2] which are pretty broad in scope; I think
under the hood it's using sydbox[3], which says it's using ptrace and
seccomp to implement it (so it may be more resilient than an
LD_PRELOAD approach).
* Debian's FakeRoot[4], which seems to use a similar mechanism, but I
think this is only applied during the binary package building.
LD_PRELOAD based as well
* InstallWatch[5] for RPM; seems like this isn't as maintained, so I
can't find as many details, but again, I think this is only used
during binary package builds

That said, I think all these just help protect against accidental
missteps, not malicious intent. There's obviously a lot of implicit
trust when you're running someone else's software.

[1] https://wiki.gentoo.org/wiki/Sandbox_(Portage)
[2] https://exherbo.org/docs/eapi/exheres-for-smarties.html#sandboxing
[3] https://github.com/sydbox/sydbox-1
[4] https://wiki.debian.org/FakeRoot
[5] https://asic-linux.com.mx/~izto/checkinstall/installwatch.html

-- 
Mike Kelly
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

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

[Roger Marquis]

Whatever the fix I hope we all agree that a policy is needed allowing or
requiring the ports and security teams to reject ports and patches which
exfiltrate (i.e, upload) _any_ local information without an explicit,
detailed and robust opt-in.

Roger Marquis




On 08/04/2021 18:24, Shawn Webb wrote:

[..]


1. Ad hominem much? I understand the underlying problem very well.
2. Your hostility is incredibly annoying.
3. You attribute malice where there is none.
4. This is volunteer work, where volunteers have everyones well-being
in mind.
5. Threatening to go to journalists accomplishes... what? What makes
you think journalists are NOT paying attention to this list? What
makes you think journalists care about you?
6. I really, really, really, really, really hate the "Karen" meme. But
it fits incredibly well here.
7. Where can I review your patches that fix the problem?


To be honest, the original post contained link to PR 251152 where Steve Wills 
posted patch 2020-12-07. What more patch is needed? The same patch again?

The fix was not committed for a 5 months
The sending of the data is not unintentional as the maintainer stated in his 
comment #13 from 2020-12-29


Even the code in periodic/monthly/300.statistics is written in "very unusual 
way". There are cases with 3 switches:

if YES = run it
if NO = tell user to enable it
if anything else = run it

Is this how all periodic scripts should behave? I don't think so. It should 
run if _enable="YES" and be silent in any other case.


Again - the first patch was provided 5 months ago by Steve Wills and the 
problem was not fixed to this day because maintainer thinks there is nothing 
to fix.


Your first jump in this thread with "lolwut" reaction was very far from 
expected. Trying to neglect the problem, trying to say that FreeBSD is not 
responsible for how packages behave in install time and nobody should be 
upset that something sends data on install time...


Kind reagards
Miroslav Lachman


8. Entitlement mentality much?

Sure, the bsdstats package shouldn't submit just on "pkg install."
Instead of fixing the problem, you went the hostile route.

I'm sure you won't learn anything from this, but I hope you do. To me,
it reinforces how random people feel entitled to force their will on
others.

Thanks,



___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"


___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

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

[Miroslav Lachman]

On 08/04/2021 18:24, Shawn Webb wrote:

[..]


1. Ad hominem much? I understand the underlying problem very well.
2. Your hostility is incredibly annoying.
3. You attribute malice where there is none.
4. This is volunteer work, where volunteers have everyones well-being
in mind.
5. Threatening to go to journalists accomplishes... what? What makes
you think journalists are NOT paying attention to this list? What
makes you think journalists care about you?
6. I really, really, really, really, really hate the "Karen" meme. But
it fits incredibly well here.
7. Where can I review your patches that fix the problem?


To be honest, the original post contained link to PR 251152 where Steve 
Wills posted patch 2020-12-07. What more patch is needed? The same patch 
again?

The fix was not committed for a 5 months
The sending of the data is not unintentional as the maintainer stated in 
his comment #13 from 2020-12-29


Even the code in periodic/monthly/300.statistics is written in "very 
unusual way". There are cases with 3 switches:

if YES = run it
if NO = tell user to enable it
if anything else = run it

Is this how all periodic scripts should behave? I don't think so. It 
should run if _enable="YES" and be silent in any other case.


Again - the first patch was provided 5 months ago by Steve Wills and the 
problem was not fixed to this day because maintainer thinks there is 
nothing to fix.


Your first jump in this thread with "lolwut" reaction was very far from 
expected. Trying to neglect the problem, trying to say that FreeBSD is 
not responsible for how packages behave in install time and nobody 
should be upset that something sends data on install time...


Kind reagards
Miroslav Lachman


8. Entitlement mentality much?

Sure, the bsdstats package shouldn't submit just on "pkg install."
Instead of fixing the problem, you went the hostile route.

I'm sure you won't learn anything from this, but I hope you do. To me,
it reinforces how random people feel entitled to force their will on
others.

Thanks,



___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

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

[Shawn Webb]

On Thu, Apr 08, 2021 at 04:50:17AM +0200, Stefan Blachmann 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”.
> 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!

1. Ad hominem much? I understand the underlying problem very well.
2. Your hostility is incredibly annoying.
3. You attribute malice where there is none.
4. This is volunteer work, where volunteers have everyones well-being
   in mind.
5. Threatening to go to journalists accomplishes... what? What makes
   you think journalists are NOT paying attention to this list? What
   makes you think journalists care about you?
6. I really, really, really, really, really hate the "Karen" meme. But
   it fits incredibly well here.
7. Where can I review your patches that fix the problem?
8. Entitlement mentality much?

Sure, the bsdstats package shouldn't submit just on "pkg install."
Instead of fixing the problem, you went the hostile route.

I'm sure you won't learn anything from this, but I hope you do. To me,
it reinforces how random people feel entitled to force their will on
others.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Re: 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  wrote:
>
> On Apr 7, 2021, at 8:50 PM, Stefan Blachmann  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
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

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

[Chris BeHanna]

On Apr 7, 2021, at 8:50 PM, Stefan Blachmann  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.

-- 
Chris BeHanna
ch...@behanna.org

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

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

[Stefan Blachmann]

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  wrote:
> On Apr 6, 2021, at 7:42 AM, Shawn Webb  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
> . Not sure why it
> hasn't been committed yet, but hopefully it gets picked up shortly.
>
> Gordon
>
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"