Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code
16 views
Skip to first unread message
Christoph Anton Mitterer
Nov 25, 2023, 1:10:06 PM11/25/23
to
Package: smartmontools
Version: 7.4-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team <te...@security.debian.org>
Hey.
The most recent upgrade forces people to use
update-smart-drivedb by doing it already in the postinst and not leaving it
up to the user whether he wants to use such a tool.
Security-wise this is really a bad idea.
Downloader packages (i.e. packages that install further code from
outside Debian) - and this effectively just that - are generally questionable.
Even if the downloader tool does everything right (which is actually quite
difficult if one assumes things like replay or blocking attacks), there's still
code introduced which is not in the control of Debian and especially also
outside security support.
Now you may argue that Debian doesn't audit the drivedb.h it ships either and
that thus security wouldn't be any better if Debian would just ship the
upstream file.
But there's still a difference:
If Debian ships the package, then all installations are guaranteed to get the
same file. So an attacker would need to attack all installation at the same
time and thus be far more likely to be detected.
If however the package is downloaded from some remote server, an attacker can
choose based on IP whether the "good" or the "evil" file is delivered.
And this is not to say that I'd assume smartmontools upstream would be evil.
But even their GPG keys or systemd can be compromised.
The package already has the update-smart-drivedb tool, if people are confident
with using it, they can do so.
But please don't force it on everyone by unconditionally calling it from
postinst (or from anywhere else).
Cheers,
Chris.
Version: 7.4-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team <te...@security.debian.org>
Hey.
The most recent upgrade forces people to use
update-smart-drivedb by doing it already in the postinst and not leaving it
up to the user whether he wants to use such a tool.
Security-wise this is really a bad idea.
Downloader packages (i.e. packages that install further code from
outside Debian) - and this effectively just that - are generally questionable.
Even if the downloader tool does everything right (which is actually quite
difficult if one assumes things like replay or blocking attacks), there's still
code introduced which is not in the control of Debian and especially also
outside security support.
Now you may argue that Debian doesn't audit the drivedb.h it ships either and
that thus security wouldn't be any better if Debian would just ship the
upstream file.
But there's still a difference:
If Debian ships the package, then all installations are guaranteed to get the
same file. So an attacker would need to attack all installation at the same
time and thus be far more likely to be detected.
If however the package is downloaded from some remote server, an attacker can
choose based on IP whether the "good" or the "evil" file is delivered.
And this is not to say that I'd assume smartmontools upstream would be evil.
But even their GPG keys or systemd can be compromised.
The package already has the update-smart-drivedb tool, if people are confident
with using it, they can do so.
But please don't force it on everyone by unconditionally calling it from
postinst (or from anywhere else).
Cheers,
Chris.
Dmitry Smirnov
Nov 25, 2023, 8:30:06 PM11/25/23
to
On Sunday, 26 November 2023 4:56:03 AM AEDT Christoph Anton Mitterer wrote:
> The most recent upgrade forces people to use
> update-smart-drivedb by doing it already in the postinst and not leaving it
> up to the user whether he wants to use such a tool.
>
> Security-wise this is really a bad idea.
I think you misunderstood that invocation of `update-smart-drivedb`
> The most recent upgrade forces people to use
> update-smart-drivedb by doing it already in the postinst and not leaving it
> up to the user whether he wants to use such a tool.
>
> Security-wise this is really a bad idea.
in postinst is an equivalent of
```
cp -f /usr/share/smartmontools/drivedb.h /var/lib/smartmontools/drivedb/
```
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006019#17
as well as
https://salsa.debian.org/debian/smartmontools/-/commit/5b1fd114a
Of course I would not recommend to download drivedb from postinst
and this is not what's happening.
> Even if the downloader tool does everything right (which is actually quite
> difficult if one assumes things like replay or blocking attacks), there's
> still code introduced which is not in the control of Debian and especially
> also outside security support.
in postinst.
What do you think, Paul?
> Now you may argue that Debian doesn't audit the drivedb.h it ships either
> and that thus security wouldn't be any better if Debian would just ship
> the upstream file.
> But there's still a difference:
> If Debian ships the package, then all installations are guaranteed to get
> the same file.
> If however the package is downloaded from some remote server, an attacker
> can choose based on IP whether the "good" or the "evil" file is delivered.
> And this is not to say that I'd assume smartmontools upstream would be
> evil. But even their GPG keys or systemd can be compromised.
make the case stronger.
> But please don't force it on everyone by unconditionally calling it from
> postinst (or from anywhere else).
actually happening.
--
Kind regards,
Dmitry Smirnov
GPG key : 4096R/52B6BBD953968D1B
---
It is strange that many believe they cannot control themselves, but they
can control others.
-- Robert LeFevre, "A Way to Be Free: The Autobiography of Robert LeFevre, Volume I" (1999)
Christoph Anton Mitterer
Nov 25, 2023, 8:50:05 PM11/25/23
to
Control: severity -1 normal
Control: tags - security
Hey.
On Sun, 2023-11-26 at 12:23 +1100, Dmitry Smirnov wrote:
> I think you misunderstood that invocation of `update-smart-drivedb`
> in postinst is an equivalent of
>
> ```
> cp -f /usr/share/smartmontools/drivedb.h
> /var/lib/smartmontools/drivedb/
> ```
Indeed. At least from the documentation (only had a short glance now
what it actually does if file= is set... but seems you're right).
Sorry for that, I had wrongly in mind that --install would also
download.
Nevertheless, do you think it would possible to adapt it to check
whether update-smart-drivedb is executable and if not fall back to the
old code?
Background is that at the university cluster I administrate we have set
dpkg-statoverrides for various "code downloader" commands like update-
smart-drivedb, update-ieee-data or update-pciids, which removes their
executeable bit, so that they're at least not accidentally run.
Would be nice if it could be kept that way.
Thanks,
Chris.
Control: tags - security
Hey.
On Sun, 2023-11-26 at 12:23 +1100, Dmitry Smirnov wrote:
> I think you misunderstood that invocation of `update-smart-drivedb`
> in postinst is an equivalent of
>
> ```
> cp -f /usr/share/smartmontools/drivedb.h
> /var/lib/smartmontools/drivedb/
> ```
what it actually does if file= is set... but seems you're right).
Sorry for that, I had wrongly in mind that --install would also
download.
Nevertheless, do you think it would possible to adapt it to check
whether update-smart-drivedb is executable and if not fall back to the
old code?
Background is that at the university cluster I administrate we have set
dpkg-statoverrides for various "code downloader" commands like update-
smart-drivedb, update-ieee-data or update-pciids, which removes their
executeable bit, so that they're at least not accidentally run.
Would be nice if it could be kept that way.
Thanks,
Chris.
Dmitry Smirnov
Nov 26, 2023, 12:00:06 AM11/26/23
to
On Sunday, 26 November 2023 12:39:09 PM AEDT Christoph Anton Mitterer wrote:
> Nevertheless, do you think it would possible to adapt it to check
> whether update-smart-drivedb is executable and if not fall back to the
> old code?
>
> Background is that at the university cluster I administrate we have set
> dpkg-statoverrides for various "code downloader" commands like update-
> smart-drivedb, update-ieee-data or update-pciids, which removes their
> executeable bit, so that they're at least not accidentally run.
>
> Would be nice if it could be kept that way.
Done:
> Nevertheless, do you think it would possible to adapt it to check
> whether update-smart-drivedb is executable and if not fall back to the
> old code?
>
> Background is that at the university cluster I administrate we have set
> dpkg-statoverrides for various "code downloader" commands like update-
> smart-drivedb, update-ieee-data or update-pciids, which removes their
> executeable bit, so that they're at least not accidentally run.
>
> Would be nice if it could be kept that way.
https://salsa.debian.org/debian/smartmontools/-/commit/625f38bc
Thanks for suggestion and feedback.
--
Best wishes,
Dmitry Smirnov
GPG key : 4096R/52B6BBD953968D1B
---
Just as everyone in a tribe praying to a volcano god would reinforce the
GPG key : 4096R/52B6BBD953968D1B
---
idea that there is a volcano god, so begging politicians for favors
reinforces the idea that there is a rightful ruling class, that their
commands are "law," and that obedience to such "laws" is a moral
imperative.
-- Larken Rose, The Most Dangerous Superstition
Christoph Anton Mitterer
Nov 27, 2023, 8:50:06 AM11/27/23
to
Hey Paul.
On Sun, 2023-11-26 at 11:01 +0800, Paul Wise wrote:
> BTW Chris, I imagine you might have some issues for this page:
>
> https://wiki.debian.org/PrivacyIssues
In which respect?
AFAICS that page is mainly about privacy (in the sense of calling
home).
My main concern is rather security, in terms of packages which download
code or similar from remote (e.g. like Firefox used to download the
binary-only OpenH264 stuff).
And we do unfortunately have quite some "downloader" packages in Debian
and no general handling of how this is done.
Some packages do it in a secure manner (IMO the best way is still to
have a fresh version of the downloader package for every new upstream
version, and the downloader package contains a hash sum of the
downloaded content - that should prevent all things like
downgrade/blocking attacks... but of course requires the package to be
kept up2date).
Now if you meant that I would want to add something to the above wiki,
because of update-smart-drivedb "calling home", then from my PoV this
isn't really necessary:
I think the purpose of update-smart-drivedb is pretty clear from its
documentation: fetching current data from upstream
(Actually I'd rather think that the --install functionality should be
outside of the tool.)
It should be obvious to anyone, that upstream will at least know your
IP from that.
IMO, that's not really a privacy issue, as its obvious.
What are rather issues is, if e.g. Firefox silently sends all kinds of
data to Mozilla (the whole "healthreport" and telemetry stuff) and too
Google ("Safe Browsing") and possibly even more.
Or when a tool like gitg contacts gravatar[0] with all emails it
encounters in a git repo, from which others could rather easily deduce
*which* repo one is working on.
Cheers,
Chris.
[0] There's an option now in it to disable it (after I've lobbied for
quite a while for it ^^), not sure whether it's on/off per default,
though.
On Sun, 2023-11-26 at 11:01 +0800, Paul Wise wrote:
> BTW Chris, I imagine you might have some issues for this page:
>
> https://wiki.debian.org/PrivacyIssues
In which respect?
AFAICS that page is mainly about privacy (in the sense of calling
home).
My main concern is rather security, in terms of packages which download
code or similar from remote (e.g. like Firefox used to download the
binary-only OpenH264 stuff).
And we do unfortunately have quite some "downloader" packages in Debian
and no general handling of how this is done.
Some packages do it in a secure manner (IMO the best way is still to
have a fresh version of the downloader package for every new upstream
version, and the downloader package contains a hash sum of the
downloaded content - that should prevent all things like
downgrade/blocking attacks... but of course requires the package to be
kept up2date).
Now if you meant that I would want to add something to the above wiki,
because of update-smart-drivedb "calling home", then from my PoV this
isn't really necessary:
I think the purpose of update-smart-drivedb is pretty clear from its
documentation: fetching current data from upstream
(Actually I'd rather think that the --install functionality should be
outside of the tool.)
It should be obvious to anyone, that upstream will at least know your
IP from that.
IMO, that's not really a privacy issue, as its obvious.
What are rather issues is, if e.g. Firefox silently sends all kinds of
data to Mozilla (the whole "healthreport" and telemetry stuff) and too
Google ("Safe Browsing") and possibly even more.
Or when a tool like gitg contacts gravatar[0] with all emails it
encounters in a git repo, from which others could rather easily deduce
*which* repo one is working on.
Cheers,
Chris.
[0] There's an option now in it to disable it (after I've lobbied for
quite a while for it ^^), not sure whether it's on/off per default,
though.
Christoph Anton Mitterer
Nov 27, 2023, 9:20:06 AM11/27/23
to
On Sun, 2023-11-26 at 15:52 +1100, Dmitry Smirnov wrote:
> https://salsa.debian.org/debian/smartmontools/-/commit/625f38bc
Thanks :-)
And sorry again for the noise and not having checked --install in
detail before reporting.
Cheers,
Chris
> https://salsa.debian.org/debian/smartmontools/-/commit/625f38bc
Thanks :-)
And sorry again for the noise and not having checked --install in
detail before reporting.
Cheers,
Chris
0 new messages