Debian Bug report logs - #804299
smartmontools: update-smart-drivedb downloads unauthenticated data from the web

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: smartmontools: update-smart-drivedb downloads unauthenticated data from the web

Date: Sat, 07 Nov 2015 05:29:05 +0100

Package: smartmontools
Version: 6.3+svn4002-2+b3
Severity: important
Tags: security


Hi.

The update-smart-drivedb downloads unauthenticated data
from the web (drive.h).

Put apart, that the it wouldn't be the first time, that
the corresponding parser has problems which may lead to
exploits, even if it correctly parses everything and just
the right syntax would be accepted, then this could be
still used to cause damage, namely when the respective
SMART command mustn't be used with a specific drive.
(There are apparently some which cause damage.)


I think update-smart-drivedb should be removed alltogether
from Debian, as it circumvents the package management system
and thereby and security support, which is generally bad.

Instead, if there's a new drivedb.h, then a package update
should be made.


But as long as there's no proper authentication (and I'm
not talking about https), this should definitely go away.


Cheers,
Chris.

Message #10 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 804299@bugs.debian.org

Subject: smartmontools: update-smart-drivedb currently risky

Date: Mon, 16 Nov 2015 18:36:29 -0800

Hi,

I was the one that originally proposed the update-smart-drivedb idea 
upstream (in 2010!).

  https://www.smartmontools.org/ticket/59

At the time I was trying to solve the problem of the drivedb getting out of 
date in debian releases very quickly and thus having to use backports or 
stable release updates to get it updated.

I now agree with Christoph that this is a risky thing to do. I think it 
should be enhanced to support authenticated copies of the database (GPG 
sigs? HSTS to a particular https site?). Until then I think it should be 
disabled or at least prompt the user to manually verify a checksum or 
something.

This bug can probably be forwarded upstream.

Thanks,

-- 
Matt Taggart
taggart@debian.org

Message #15 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: submit@bugs.debian.org

Cc: 804299@bugs.debian.org

Subject: pciutils: update-pciids downloads unauthenticated data from the web

Date: Mon, 16 Nov 2015 18:49:24 -0800

Package: pciutils
Version: 1:3.3.1-1
Severity: important

Debian bug #804299 made me realize that update-pciids also has the same 
problem of downloading unauthenticated data from the web and then parsing 
it, potentially being open to potential exploits in the parser. The risk is 
probably less than update-smart-drivedb, which might potentially take 
action based on the data that could result in drive damage, I suppose it's 
possible there is something that is taking action based on pciids data.

In the short term it should probably be disabled or at least prompt the 
user to manually verify a checksum or something. Longer term maybe both 
utils can use a similar solution.

Thanks,

-- 
Matt Taggart
taggart@debian.org

Message #20 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Matt Taggart <taggart@debian.org>, 804299@bugs.debian.org

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Tue, 17 Nov 2015 03:54:38 +0100

[Message part 1 (text/plain, inline)]

Hey.


On Mon, 2015-11-16 at 18:36 -0800, Matt Taggart wrote:
> At the time I was trying to solve the problem of the drivedb getting
> out of 
> date in debian releases very quickly and thus having to use backports
> or 
> stable release updates to get it updated.
IMHO, we'd have backports for this nowadays... plus, if just the
drivedb has changed (as it would do with the update command),.. it
shouldn't be to difficult for the maintainers to regularly update this,
I guess.


> I now agree with Christoph that this is a risky thing to do. I think
> it 
> should be enhanced to support authenticated copies of the database
> (GPG 
> sigs? HSTS to a particular https site?).
Nah... I don't think that's good...
Let's not even talk about https/HSTS which is both quite questionable
from a security PoV.

But even the GPG idea would just duplicate functionality of package
management (i.e. updating) inside the program.
Circumventing the package management system should IMHO never be
done,... and securing it properly is actually more tricky than just
signing (thinking of downgrade and blocking attacks).

Even if it would be properly secured with some key that upstream has,
it would allow them to selectively inject code into Debian systems.


>  Until then I think it should be 
> disabled or at least prompt the user to manually verify a checksum or
> something.
Yes, good idea.


> This bug can probably be forwarded upstream.
Well, the proper solution would be to drop that functionality
altogether. For these kind of tasks we have package management systems
in the *nix world.... and they already secure everything quite well -
at least APT does.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #25 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: submit@bugs.debian.org

Cc: 804299@bugs.debian.org, 805328@bugs.debian.org

Subject: usbutils: update-usbids downloads unauthenticated data from the web

Date: Mon, 16 Nov 2015 19:01:54 -0800

Package: usbutils
Version: 1:007-4
Severity: important

Debian bugs #804299 and #805328 made me realize that update-usbids also has 
the same problem of downloading unauthenticated data from the web and then 
parsing it, potentially being open to potential exploits in the parser. The 
risk is probably less than update-smart-drivedb, which might potentially 
take action based on the data that could result in drive damage, I suppose 
it's possible there is something that is taking action based on usbids data.

In the short term it should probably be disabled or at least prompt the 
user to manually verify a checksum or something. Longer term maybe both 
utils can use a similar solution.

Thanks,

-- 
Matt Taggart
taggart@debian.org

Message #30 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christian Franke <Christian.Franke@t-online.de>

To: 804299@bugs.debian.org

Subject: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Fri, 27 Nov 2015 08:01:56 +0100

Christoph Anton Mitterer wrote:
> Even if it would be properly secured with some key that upstream has,
> it would allow them to selectively inject code into Debian systems.

Then anything we could do upstream (e.g. provide a drivedb.h.asc file, 
check it in update-smart-drivedb) won't help.

Some volunteer maintainer might provide drivedb.h (below /usr, not /var) 
as a separate arch independent package and update it more frequently 
than smartmontools. Such a package only needs a "suggests" dependency 
because the built-in database is used if the external file is missing.


> In the short term it should probably be disabled or at least prompt the
> user to manually verify a checksum or something.

  ./configure --without-drivedbdir

This keeps the built-in database and optional /etc/smartd_drivedb.h intact.

If done, please add a dummy update-smart-drivedb script which explains 
why this functionality was removed.


Possible risks from a bogus drivedb.h:

- The typical worst case: A hidden bug in the parser allows to run 
arbitrary code as root.
(BTW: Thanks for any review of the parser in knowndrives.cpp)

- Removing "-F nologdir" option from Intel 320/710 SSD entries may 
result in drive a firmware crash if Log Directory is read.

- Setting a bogus USB "-d TYPE" option may result in disconnected USB 
devices or more serious problems.

- More ? (IMO no).


Thanks,
Christian
smartmontools.org

Message #35 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Christian Franke <Christian.Franke@t-online.de>, 804299@bugs.debian.org

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Fri, 27 Nov 2015 17:22:03 +0100

[Message part 1 (text/plain, inline)]

On Fri, 2015-11-27 at 08:01 +0100, Christian Franke wrote:
> Christoph Anton Mitterer wrote:
> > Even if it would be properly secured with some key that upstream
> > has,
> > it would allow them to selectively inject code into Debian systems.
> 
> Then anything we could do upstream (e.g. provide a drivedb.h.asc
> file, 
> check it in update-smart-drivedb) won't help.
Well there's a tiny difference here:

Of course, Debian takes the code from upstream, and probably doesn't
have the manpower to fully security audit it... but...

... the code for all users would be the same, so if it includes a
(maliciously introduced) security hole, it's much more likely that it
gets noted.

To the contrary, when code is directly pulled from upstream somehow, a
malicious upstream (or perhaps their hoster, if upstream doesn't sign)
may selectively (based on the end-user just downloading) attack users,
which makes it far more difficult to detect anything like that.


I think I do have quite some experience in terms of security... and
from my PoV the general rule of thumb is: don't avoid the package
management system, unless there are extremely strong reasons, because
really securing software deployment is actually much more tricky than
it may seem.. and the package management system already does it right.


> Some volunteer maintainer might provide drivedb.h (below /usr, not
> /var) 
> as a separate arch independent package and update it more frequently 
> than smartmontools. Such a package only needs a "suggests" dependency
> because the built-in database is used if the external file is
> missing.
That could be a solution,... and perhaps


> > In the short term it should probably be disabled or at least prompt
> > the
> > user to manually verify a checksum or something.
> 
>    ./configure --without-drivedbdir
> 
> This keeps the built-in database and optional /etc/smartd_drivedb.h
> intact.
> 
> If done, please add a dummy update-smart-drivedb script which
> explains 
> why this functionality was removed.
I think that sounds good.
Another solution I'd accept would be to remove update-smart-drivedb
from the general path, allow it's execution only with some --i-know-it-
is-probably-insecure parameter while explaining why this is done.


> Possible risks from a bogus drivedb.h:
> 
> - The typical worst case: A hidden bug in the parser allows to run 
> arbitrary code as root.
> (BTW: Thanks for any review of the parser in knowndrives.cpp)
> 
> - Removing "-F nologdir" option from Intel 320/710 SSD entries may 
> result in drive a firmware crash if Log Directory is read.
> 
> - Setting a bogus USB "-d TYPE" option may result in disconnected USB
> devices or more serious problems.
I think in the past there were several reports of hardware including
disks, that, when you queried something wrong, may have ended up
severely damaged.

> - More ? (IMO no).
Typically, in security, the worst attacks are those which one cannot
even think of... not the ones one can already imagine ;)

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #40 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christian Franke <Christian.Franke@t-online.de>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 804299@bugs.debian.org

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Fri, 27 Nov 2015 20:30:37 +0100

Christoph Anton Mitterer wrote:
>> - Removing "-F nologdir" option from Intel 320/710 SSD entries may
>> result in drive a firmware crash if Log Directory is read.
>>
>> - Setting a bogus USB "-d TYPE" option may result in disconnected USB
>> devices or more serious problems.
> I think in the past there were several reports of hardware including
> disks, that, when you queried something wrong, may have ended up
> severely damaged.

Most of these problems were unrelated to any influence the drive 
database file has on smartmontools operation.

For example: Buggy RAID controller firmware doing interesting things if 
specific (SAT) pass-through commands are issued.
Or my favorite: Samsung F4 disks discarding write cache if ATA IDENTIFY 
is issued.

Cheers,
Christian

Message #45 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Jonathan Dowland <jmtd@debian.org>

To: Paul Wise <pabs@debian.org>, 706909@bugs.debian.org

Cc: 804299@bugs.debian.org

Subject: Re: Bug#706909: fixed in smartmontools 6.1+svn3812-1

Date: Mon, 30 Nov 2015 14:06:20 +0000

On Sat, Oct 03, 2015 at 06:57:31PM +0200, Paul Wise wrote:
> This isn't the way to fix this issue, the current mechanisms still lead to
> drivedb.h from the package being overwritten by downloaded data. Thedrivedb.h
> file should be shipped in the deb in /usr not /var. At package install/update
> time the copy in /var should be updated using the copy in /usr if it is newer
> than the copy in /usr. The update tool should only write to the copy in /var
> but only if the downloaded version is newer than the copy in /var.

I'm thinking that this should probably be resolved (as with #804299) by
removing the drivedb update feature from the Debian package and performing
drivedb updates via update Debian packages. I'm not yet sure whether it's
worth splitting the drivedb out of the main smartmontools package; I need
to think whether that would make backporting easier. I'm interested in any
others opinions on the issue (I guess follow-ups to #804299 would be most
appropriate).

Message #52 received at 804299-close@bugs.debian.org (full text, mbox, reply):

From: Jonathan Dowland <jmtd@debian.org>

To: 804299-close@bugs.debian.org

Subject: Bug#804299: fixed in smartmontools 6.4+svn4214-1

Date: Fri, 05 Feb 2016 17:23:34 +0000

Source: smartmontools
Source-Version: 6.4+svn4214-1

We believe that the bug you reported is fixed in the latest version of
smartmontools, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 804299@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jonathan Dowland <jmtd@debian.org> (supplier of updated smartmontools package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 04 Feb 2016 23:21:58 +0000
Source: smartmontools
Binary: smartmontools
Architecture: source amd64
Version: 6.4+svn4214-1
Distribution: unstable
Urgency: medium
Maintainer: Giuseppe Iuculano <iuculano@debian.org>
Changed-By: Jonathan Dowland <jmtd@debian.org>
Description:
 smartmontools - control and monitor storage systems using S.M.A.R.T.
Closes: 634506 669053 706909 732045 766145 766146 777583 783317 794035 804299 813102
Changes:
 smartmontools (6.4+svn4214-1) unstable; urgency=medium
 .
   [ Helmut Grohne ]
   * Fix FTCBFS. (Closes: #794035)
     + Pass --build and --host to configure
 .
   [ Tobias Frost ]
   * Import patch from Helmut (see above)
   * Remove '/var/lib/smartmontools' on purge (Closes: #766145)
   * Fixed postinst script: Version is only valid when configuring.
     (Closes: #766146)
 .
   [ Jonathan Dowland ]
   * Portability improvements, thanks Robert Millan. Closes: #634506.
   * Update debian/copyright to Format 1.0., resolve GPL-2/GPL-2+
     ambiguity. Closes: #777583.
   * Get rid of update-smart-drivedb. Closes: #783317, #804299, #706909.
   * Bump standards version (no further changes required)
   * Enhance rules clean target to make repeated builds easier
   * Stop installing duplicate/irrelevant docs (COPYING, changelog, INSTALL)
   * add 'set -e' to postrm.
   * Switch to xz for orig.tar compression and update get-orig-source rule.
   * Stop passing explicit runlevels to dh_installinit. Closes: #732045.
   * Remove duplicate use of dh_systemd_enable: The second one should have
     been dh_systemd_start. Closes: #813102.
   * Various manpage improvements. Thanks Bjarni Ingi Gislason.
     Closes: #669053.
Checksums-Sha1:
 38caa63d0ab2e0ef5803d6a11f1203f24943f25c 2240 smartmontools_6.4+svn4214-1.dsc
 2414c5843aafe784a617839e65bd1f480fd3077c 540756 smartmontools_6.4+svn4214.orig.tar.xz
 bfc0b22d34d836d2ba9583b7d0b6a7cffb40d86f 52044 smartmontools_6.4+svn4214-1.debian.tar.xz
 3e6f3603b948bcf17c08b456ddaa0f788d2761c4 473882 smartmontools_6.4+svn4214-1_amd64.deb
Checksums-Sha256:
 190b36dc5d7078f6f8c2c8ad28c4051419f1477224335747770f27f0f303d537 2240 smartmontools_6.4+svn4214-1.dsc
 dc4b280c124b2b99733111034b3debabd0c650b6335250c58e0382e12c0a35d7 540756 smartmontools_6.4+svn4214.orig.tar.xz
 0818809b800b7e1a8c8c47d330353155b55d259a27c732890f2e3b4ae639e12f 52044 smartmontools_6.4+svn4214-1.debian.tar.xz
 3a6ec5ecca7759c01ae8f8d1ffa2dd44bcabc63a8a7bf76120afb3dd391988cf 473882 smartmontools_6.4+svn4214-1_amd64.deb
Files:
 3498378d1ddd42ec8d6cd4d82a4a85ad 2240 utils optional smartmontools_6.4+svn4214-1.dsc
 fd7e5b543368fedd8e952e1e08419fa9 540756 utils optional smartmontools_6.4+svn4214.orig.tar.xz
 23ea53171e7543851dd5c88377c2cf2f 52044 utils optional smartmontools_6.4+svn4214-1.debian.tar.xz
 eec120cb3bf201e613155a6b4376bbac 473882 utils optional smartmontools_6.4+svn4214-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWtNAWAAoJEAkHQJYGqqqq2E0P/0KKrf0t+jzoVfMW9WG/mchD
Upa/GgxHooPXciQ42+lVj2xrY/QPyqUOnkFLdp0JdkqzrYAPIogAvgSKi9CcX4vk
liuxQ+bLDRXn79KxKWeFaBur0VEmoHNqXLkTM8nxGAdZpuktvtfmJIxU9W3AZdRL
1wSEbPFWONc7znRGbL9DP+l1NqgZbm9xOGF/jGauUU1qtq6LL4cVFfvmdQe+lbLk
eAKQntXpPZxUQuEsJYhPJiZcAX2pMeH4gOxVYsgmLdnlfN3bggpFjMiOqO0IIgSl
yK0088ZSL/DuBd7MgzUBbkxzAZQ35vhDTpxbQHiPYIhXZ/VPv2eTfgvEKyPFe0XW
gqeaR26Qkcaf/jLdufHVG7z4UTDcYnCq5RepO9F4gNvtnmGhWW1uYpOSWbAr5L54
4BdE25a54HdF0ZNPzeb5C05kjGLhqgqBSIvknGg3tR++D0efJijuuoFsfLng4J6J
pHA9aZfxHNBj78r2JEVQayXgmYzXkU/lEITWMKsf5+wV1N77Yfz0E807SJJQS7Fy
a97ywfHk1BSA4JS9qB/hy5LpgVOA1C/N3PZ/LH116e2GJDuf+XbGY/KsmhbKmp+9
XNPVYY7Q0W6hiDB5xhYebyLWHUEXmy4E8uHnfYw9OZ2b6N7yVkfVtz0I24QK7i/r
JSfpt/p7gJqOQmD7gxM1
=nL9i
-----END PGP SIGNATURE-----

Message #65 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Jonathan Dowland <jmtd@debian.org>

To: 804299@bugs.debian.org

Subject: Re: Bug#889033: smartmontools: New version (6.6) is available

Date: Mon, 15 Oct 2018 20:36:58 +0100

On Thu, Apr 05, 2018 at 07:13:42AM +0200, Christian Franke wrote:
>For a smartmontools-6.6+ package, please reconsider the decision to 
>remove the update-smart-drivedb script (Bug#804299) as it now 
>validates the downloaded file.

I'll (attempt to) reopen #804299, as *this* bug (#889033) will be closed
by the next package upload, and we won't have deliberated on re-adding
update-smart-drivedb by then.


Thanks

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀

Message #70 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-bugs@zugschlus.de>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 804299@bugs.debian.org

Cc: Matt Taggart <taggart@debian.org>

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Tue, 8 Jan 2019 11:46:17 +0100

On Tue, Nov 17, 2015 at 03:54:38AM +0100, Christoph Anton Mitterer wrote:
> On Mon, 2015-11-16 at 18:36 -0800, Matt Taggart wrote:
> > At the time I was trying to solve the problem of the drivedb getting
> > out of 
> > date in debian releases very quickly and thus having to use backports
> > or 
> > stable release updates to get it updated.
> IMHO, we'd have backports for this nowadays... plus, if just the
> drivedb has changed (as it would do with the update command),.. it
> shouldn't be to difficult for the maintainers to regularly update this,
> I guess.

However, it doesn't get updated as swiftly as it should, not even in
unstable. I have now two notebooks with SSDs that are older than six
months that are not properly handled by smartmontools due to the
outdated drivedb.

By removing the update script altogether, you have deprived me of an
easy way to shoot myself in the foot by using it. I now have to resort
to manually downloading thw unchecked file from the Internet because I
really really want that hole in my foot.

Is that really such a good idea? Please reconsider.

Greetings
Marc

Message #75 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 804299@bugs.debian.org

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Tue, 08 Jan 2019 15:09:16 +0100

Maybe one could put it (non-executable) into /u/s/d/…/examples?

Cheers,
Chris.

Message #80 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Michael Prokop <mika@debian.org>

To: Marc Haber <mh+debian-bugs@zugschlus.de>, 804299@bugs.debian.org, Christoph Anton Mitterer <calestyo@scientia.net>

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Thu, 10 Jan 2019 14:34:45 +0100

[Message part 1 (text/plain, inline)]

* Marc Haber [Tue Jan 08, 2019 at 11:46:17AM +0100]:

> However, it doesn't get updated as swiftly as it should, not even in
> unstable. I have now two notebooks with SSDs that are older than six
> months that are not properly handled by smartmontools due to the
> outdated drivedb.

ACK

> By removing the update script altogether, you have deprived me of an
> easy way to shoot myself in the foot by using it. I now have to resort
> to manually downloading thw unchecked file from the Internet because I
> really really want that hole in my foot.

> Is that really such a good idea? Please reconsider.

+1

Also for live systems like Grml this would allow us to ensure that
the files are as up2date as our release itself. (We have the
invocation of the update-smart-drivedb command within our ISO build
toolchain, but "now" that this script no longer exists in Debian
it's no longer as up2date as it used to be. :-/)

* Christoph Anton Mitterer [Tue Jan 08, 2019 at 03:09:16PM +0100]:
> Maybe one could put it (non-executable) into /u/s/d/…/examples?

I'd appreciate this, if providing it within $PATH isn't considered
an option within Debian.

BTW, the smartmontools package still ships
/usr/share/man/man8/update-smart-drivedb.8.gz, which is even more
confusing for users. :)

regards,
-mika-

[signature.asc (application/pgp-signature, inline)]

Message #85 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Michael Prokop <mika@debian.org>, Marc Haber <mh+debian-bugs@zugschlus.de>, 804299@bugs.debian.org

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Thu, 10 Jan 2019 15:47:24 +0100

On Thu, 2019-01-10 at 14:34 +0100, Michael Prokop wrote:
> * Christoph Anton Mitterer [Tue Jan 08, 2019 at 03:09:16PM +0100]:
> > Maybe one could put it (non-executable) into /u/s/d/…/examples?
> 
> I'd appreciate this, if providing it within $PATH isn't considered
> an option within Debian.

Well it's not upon me to decide it, but to the maintainer.

I've just hat a quick glance at current upstream:
https://svn.code.sf.net/p/smartmontools/code/trunk/smartmontools/update-smart-drivedb.in

It seems it now contains some code verification, both X.509 CA based
and/or OpenPGP based.
I think the X.509 CA / TLS based one can be just tossed (because X.509
PKI is inherently flawed and insecure - just take the ~150 CAs Mozilla
ships, many of them already completely untrustworthy, with even more
sub-CAs (that are even more untrustworthy).

OpenPGP would be in principle ok.
However, I haven't really checked the implementation of it (i.e. how
the code downloading, verification is done... on a first glance, I'd
say it allows at least for replay attacks.
Plus it automatically imports the shipped public key into the keyring
of the executing user… which is IMO also unacceptable.



Generally I think it's good that the tool is gone,… updating code
should *always* be the task of the respective package management
system, cause otherwise it's not just easy that code-downloader-
programs do it wrong (e.g. allowing for replay attacks, etc. pp. [0])
but it also allows for certain types of attacks (e.g. code distributed
by the package management system guarantees more or less that all users
would need to get a hacked version,... while if it's distributed by a
(possibly hacked?) upstream, single users could be targeted
selectively, making it likely much harder to notice an attack).


Having code downloaded/updated by downloader-programs also means that
this basically circumvents Debian security support.
People will only get updates if they invoke the necessary update-*
program... and things like e.g. Icinga checks (check_apt), won't see
that any action needs to be taken.


I think it security-wise it would be best not to ship it at all, or at
least (perhaps even non-executable) in the examples dir.
If there is such a big demand in having that extremely up-to-date by
many people it would be better if they could perhaps help somehow to
keep the package better up-to-date. :-)


Cheers,
Chris.

[0] Some years ago there were still many of such downloader packages in
Debian which did a very bad job in terms of security.

Message #90 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christian Franke <Christian.Franke@t-online.de>

To: Christoph Anton Mitterer <calestyo@scientia.net>

Cc: 804299@bugs.debian.org, Michael Prokop <mika@debian.org>, Marc Haber <mh+debian-bugs@zugschlus.de>

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Wed, 16 Jan 2019 21:05:01 +0100

Christoph Anton Mitterer wrote:
> ...
> I've just hat a quick glance at current upstream:
> https://svn.code.sf.net/p/smartmontools/code/trunk/smartmontools/update-smart-drivedb.in

Comments are welcome.


> It seems it now contains some code verification, both X.509 CA based
> and/or OpenPGP based.
> I think the X.509 CA / TLS based one can be just tossed (because X.509
> PKI is inherently flawed and insecure - just take the ~150 CAs Mozilla
> ships, many of them already completely untrustworthy, with even more
> sub-CAs (that are even more untrustworthy).

Agree.


> OpenPGP would be in principle ok.
> However, I haven't really checked the implementation of it (i.e. how
> the code downloading, verification is done... on a first glance, I'd
> say it allows at least for replay attacks.

Could you possibly describe an attack scenario?


> Plus it automatically imports the shipped public key into the keyring
> of the executing user… which is IMO also unacceptable.

Of course this would be unacceptable. I'm at least somewhat sure that I 
didn't implement it that way :-)

Cheers,
Christian
smartmontools.org

Message #95 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-bugs@zugschlus.de>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 804299@bugs.debian.org

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Fri, 1 Feb 2019 22:09:46 +0100

On Thu, Jan 10, 2019 at 03:47:24PM +0100, Christoph Anton Mitterer wrote:
> OpenPGP would be in principle ok.
> However, I haven't really checked the implementation of it (i.e. how
> the code downloading, verification is done... on a first glance, I'd
> say it allows at least for replay attacks.
> Plus it automatically imports the shipped public key into the keyring
> of the executing user… which is IMO also unacceptable.

Agreed, the script should use its own keyring.

> Generally I think it's good that the tool is gone,… updating code
> should *always* be the task of the respective package management
> system, cause otherwise it's not just easy that code-downloader-

I violently disagree. We only release every two years. SSDs develop
quickly. We should not ship a two year old file.

> Having code downloaded/updated by downloader-programs also means that
> this basically circumvents Debian security support.

If the downloader script replaces the file from the package, it will be
overridden with the next package upgrade, allowing security support to
continue seamlessly.

> I think it security-wise it would be best not to ship it at all,

IMO unacceptable.

> or at
> least (perhaps even non-executable) in the examples dir.

That's a dirty workaround.

> If there is such a big demand in having that extremely up-to-date by
> many people it would be better if they could perhaps help somehow to
> keep the package better up-to-date. :-)

In debian stable? That would basically mean to have this package in each
and every point release.

I would like to remind that we used to have daily build of the clamav
anti-virus database distributed as .deb via debian-volatile, which was
quickly killed off after volatile was taken over by ftpmaster, refering
users to use freshclam, a downloader program, instead. So we have a very
much more prominent case of having a downloader program for volatile
data here.

In this case, we're not executing the download on our own, so we could
even put the load of verifying the file on to the local user executing
the script.

We could think abuot shipping the PCI/USB ID databases together with the
smartmontools database in a volatile-hwdata package that can be part of
every point release, but that would need a coordinated effort, while I'd
really love to have an acceptable solution for this NOW to provide an
acceptable method of having smartmontools giving reasonable output
even for newer hardware during the buster cycle.

If we continue sacrificing functionality for security, we can start
shipping empty packages. Those are surely the most secure.

Greetings
Marc

Message #100 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 804299@bugs.debian.org

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Fri, 01 Feb 2019 23:40:59 +0100

On Fri, 2019-02-01 at 22:09 +0100, Marc Haber wrote:
> Generally I think it's good that the tool is gone,… updating code
> > should *always* be the task of the respective package management
> > system, cause otherwise it's not just easy that code-downloader-
> 
> I violently disagree. We only release every two years. SSDs develop
> quickly. We should not ship a two year old file.

If it's only that .h file that changes… it shouldn't be very difficult
to keep things up2date, or is it?


> > Having code downloaded/updated by downloader-programs also means
> > that
> > this basically circumvents Debian security support.
> 
> If the downloader script replaces the file from the package, it will
> be
> overridden with the next package upgrade, allowing security support
> to
> continue seamlessly.

Things like debsums will break, and often (though I haven't checked the
one from smartmontools) these downloaders have security flaws… e.g.
allowing for a downgrade attack, by only checking for a valid
signature, not for a validity time.

Also by circumventing package-management, one effectively circumvents
tools like check_apt.


> > or at
> > least (perhaps even non-executable) in the examples dir.
> 
> That's a dirty workaround.

But possibly the safest one for many users?


> In debian stable? That would basically mean to have this package in
> each
> and every point release.

There's e.g. stable-updates which could be perfectly used for this...


> I would like to remind that we used to have daily build of the clamav
> anti-virus database distributed as .deb via debian-volatile, which
> was
> quickly killed off after volatile was taken over by ftpmaster,
> refering
> users to use freshclam, a downloader program, instead. So we have a
> very
> much more prominent case of having a downloader program for volatile
> data here.

I think to remember at least 2-3 CVEs in freshclam…


> In this case, we're not executing the download on our own

Which OTOH makes it also worse, as people not manually executing it
won't get updates.


> If we continue sacrificing functionality for security, we can start
> shipping empty packages. Those are surely the most secure.

Sorry, but this is just polemic.

There is no need to sacrifice functionality for security, just use the
means that are already there, e.g. stable-updates (i.e. the debian-
volatile successor)... I'd be surprised if the ftp-masters refuse to
that if there's good reasoning... and if they do, stable-updates could
probably just tossed.

There is no need to sacrifice security, if things can be done just
right :-)


Cheers,
Chris.

Message #105 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christian Franke <Christian.Franke@t-online.de>

To: Marc Haber <mh+debian-bugs@zugschlus.de>, 804299@bugs.debian.org, Christoph Anton Mitterer <calestyo@scientia.net>

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Sat, 2 Feb 2019 22:11:41 +0100

Marc Haber wrote:
> On Thu, Jan 10, 2019 at 03:47:24PM +0100, Christoph Anton Mitterer wrote:
>> ...
>> Plus it automatically imports the shipped public key into the keyring
>> of the executing user… which is IMO also unacceptable.
> Agreed, the script should use its own keyring.

The script creates a temporary gpg homedir, imports the key, verifies 
the file and then removes the gpg homedir. See function gpg_verify().

So it actually uses its own keyring and does not touch user's ~/.gnupg :-)

Cheers,
Christian

Message #110 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 804299@bugs.debian.org

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Sun, 03 Feb 2019 00:27:22 +0100

On Sat, 2019-02-02 at 22:11 +0100, Christian Franke wrote:
> The script creates a temporary gpg homedir, imports the key,
> verifies 
> the file and then removes the gpg homedir. See function gpg_verify().

Seems you're right... as I've said previously I only had a very short
glance over the current version of script :-)


Cheers,
Chris.

Message #115 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 804299@bugs.debian.org, 804299-submitter@bugs.debian.org

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Wed, 13 Feb 2019 09:44:15 +0100

On Fri, Feb 01, 2019 at 11:40:59PM +0100, Christoph Anton Mitterer wrote:
> On Fri, 2019-02-01 at 22:09 +0100, Marc Haber wrote:
> > Generally I think it's good that the tool is gone,… updating code
> > > should *always* be the task of the respective package management
> > > system, cause otherwise it's not just easy that code-downloader-
> > 
> > I violently disagree. We only release every two years. SSDs develop
> > quickly. We should not ship a two year old file.
> 
> If it's only that .h file that changes… it shouldn't be very difficult
> to keep things up2date, or is it?

I don't think that having a new package version per stable point release
just to update the data file is a real elegant way of using package
maintainer and release team time.

That's a classic case of volatile data that should either be in a
dedicated package that can be built automatically and release much more
often, or we could finally get in motion to trust upstream's
distribution mechanism like we do for, for example, clamav.

Greetings
Marc

jftr, clamav used to have an automatically built clamav-data package
that contained daily updates, but that was killed off by the archive
maintainers, refering people to the mechanisms offered by the package
upstream. smartmontools is currently going the opposite direction.

Message #123 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 804299@bugs.debian.org

Subject: Re: Bug#804299: smartmontools: update-smart-drivedb currently risky

Date: Wed, 13 Feb 2019 16:53:28 +0100

On Wed, 2019-02-13 at 09:44 +0100, Marc Haber wrote:
> That's a classic case of volatile data that should either be in a
> dedicated package that can be built automatically and release much
> more
> often
You mean splitting out just the .h file? Well sounds ok to me, but
ultimately all up to the maintainer :-)


> or we could finally get in motion to trust upstream's
> distribution mechanism like we do for, for example, clamav.
Well as I've outlaid several times now before, even it that
distribution mechanism could be trusted (and last time - but again: it
was no thorough check - I didn't see any means to avoid downgrade
attacks),... there's still the inherent point that it circumvents the
package management system and anything depending on it (automatic
update tools, Nagios checks, etc.) will thus not work.


> jftr, clamav used to have an automatically built clamav-data package
> that contained daily updates, but that was killed off by the archive
> maintainers, refering people to the mechanisms offered by the package
> upstream.
Well the may have had their technical reasons, but conceptually and
security wise it think it's not the best decisions...

If every package brings their own updating system, all of them flawed
(like freshclam had been several times), we'd have quite a mess.
So please let's avoid to go in a Windows-world direction, where
everything brings it's own questionable updater with it.


Cheers,
Chris.

Message #128 received at 804299@bugs.debian.org (full text, mbox, reply):

From: Michael Firth <MFirth@nevion.com>

To: "804299@bugs.debian.org" <804299@bugs.debian.org>

Date: Fri, 1 Mar 2019 15:09:38 +0000

[Message part 1 (text/plain, inline)]

Is there any chance of a way forward on this?

It seems that the drivedb.h updates in the 'smartmontools' package aren't just slow, but non-existent - the version that ships with Debian 9.7 dates from a year *before* the release of Debian 9.0

If there is no script to perform an update in the package, and the version available with Debian is ancient, then you end up in a worse situation than what you are trying to avoid - users (like me just now) end up downloading unsigned and unchecked versions of drivedb.h from the Internet by hand, and manually applying them to their systems - I think that is much likely to end up with system breakages than having at least some directions to a (semi-secure) script that will do it correctly.

It also seems that almost 3 years after the problem was first mentioned online(in a Ubuntu bug report comment), the man page for "update-smart-drivedb" is still in Debian, despite the script having been removed. I would personally suggest that rather than removing the manual page completely, it should be replaced with a page describing that the script has been removed from Debian, and what users should do instead.

[Message part 2 (text/html, inline)]

Message #133 received at 804299-close@bugs.debian.org (full text, mbox, reply):

From: Dmitry Smirnov <onlyjob@debian.org>

To: 804299-close@bugs.debian.org

Subject: Bug#804299: fixed in smartmontools 7.0-1

Date: Thu, 10 Oct 2019 03:19:46 +0000

Source: smartmontools
Source-Version: 7.0-1

We believe that the bug you reported is fixed in the latest version of
smartmontools, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 804299@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Dmitry Smirnov <onlyjob@debian.org> (supplier of updated smartmontools package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 10 Oct 2019 12:39:16 +1100
Source: smartmontools
Architecture: source
Version: 7.0-1
Distribution: unstable
Urgency: medium
Maintainer: Dmitry Smirnov <onlyjob@debian.org>
Changed-By: Dmitry Smirnov <onlyjob@debian.org>
Closes: 767569 804299 808987 824149 824795 854043 865202 865912 866838 878752 893646 894534 898121 907736 911280 918535 924892
Changes:
 smartmontools (7.0-1) unstable; urgency=medium
 .
   [ Jean-Michel Vourgère ]
   * Update README.Debian. (Closes: #878752).
 .
   [ Dmitry Smirnov ]
   * New upstream release (Closes: #918535).
     + NVMe devices support (Closes: #911280).
     + no longer fails on nvme/Optane (Closes: #924892).
     + Type=notify for systemd service (Closes: #865912).
   * Re-introduced "update-smart-drivedb", now with GPG validation;
     (Closes: #894534, #824795, #804299, #854043, #824149).
   * Removed obsolete "10powersave-notify" (Closes: #893646).
   * Added note how to disable the service to README.Debian.
     No longer use "start_smartd" in defaults. (Closes: #907736, #767569).
   * Install smartd.service alias (Closes: #808987).
   * DH & compat to version 12; rules to DH sequence.
   * Pre-Depends: ${misc:Pre-Depends}
   * Standards-Version: 4.4.1.
   * In-depth copyright documentation.
   * Build-Depends:
     * automake1.11 --> automake (Closes: #865202).
     + pkg-config
     + libsystemd-dev
   * Demoted MTA from Recommends to Suggests (Closes: #898121).
   * Suggests += "curl | wget | lynx, gpg".
   * Addressed some lintian warnings:
     - maintainer-script-should-not-use-dpkg-maintscript-helper
     - init.d-script-possible-missing-stop
   * Added bug-presubj file with information about upstream bug tracker.
   * watch: fixed and converted to v4; checking upstream signature.
   * Replaced Giuseppe Iuculano as Maintainer by request of the MIA team
     (Closes: #866838).
Checksums-Sha1:
 250d09b42894823847e90d77b1f1ac22449c0e31 2172 smartmontools_7.0-1.dsc
 a79329e249d6a02bbd40518b0d7ed1cd5adc4a96 705808 smartmontools_7.0.orig.tar.xz
 7daa782d0491545caa1b1bd0ed3d251af19c26f5 35904 smartmontools_7.0-1.debian.tar.xz
 9b1ed15e63d7fe0715c0e823f11b2527ee86b9b3 6135 smartmontools_7.0-1_amd64.buildinfo
Checksums-Sha256:
 7a8009c43c2685e2482db93a4fa57fdb8b1c094dc06b39faded38d55fa6ffdf3 2172 smartmontools_7.0-1.dsc
 71e62a5fcf2ac8f2abbbe6df15d483a2d1d8e6d8a9373030f2ab399223d16d18 705808 smartmontools_7.0.orig.tar.xz
 730881001b6d2553da1df14777dc771cc58b6045dc611da0457e93a813ff05c9 35904 smartmontools_7.0-1.debian.tar.xz
 6ad7d929dff90e831d7a81d243a64366d1ad86b7ca949ef5f10ca53f733f84cc 6135 smartmontools_7.0-1_amd64.buildinfo
Files:
 a225c7db1f4e3cb6a9d18ac32d6f502e 2172 utils optional smartmontools_7.0-1.dsc
 c4d6f7228731de329c15ebc067b9a384 705808 utils optional smartmontools_7.0.orig.tar.xz
 1b519b6bcc61e868493db68a712162b5 35904 utils optional smartmontools_7.0-1.debian.tar.xz
 3dd7b759de9fa93a929ee469b8c08093 6135 utils optional smartmontools_7.0-1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEULx8+TnSDCcqawZWUra72VOWjRsFAl2end0ACgkQUra72VOW
jRtLTg/+O8V538BK2YpVWA38lJEiKIJAIh+ShZIcHfkAVFLYs9HudiSbP5Ad0b9R
xB3wlTJqsc2LdAdXW7jZoag2x5a4H59lspy0WRA9VWzF6UpZj4ef9FRf7L8+ydWD
KGJTAsbmTeeQsvx8nHRi+DTfCmUIoNUkxonFeNIdx8FtXpH36vTNjG9htWLjTYRr
k4YB0HtVNf7hX0A9qi76q/A7ZXJMa6eoUza4eEVyEjOMd84O6fvwKa/cRgco+oXc
8p3wd5b/ISLGUF3M3/EN+zOA5ERDIhJ7/kGfZ3GpltyICeC77Gmu+USn39CrYaVh
iTlVGcZ0J8+VndJo+1MpyYImtOkwyvUVtKRP90ErxcWt4iqtdDvql0gAkTx/ixd5
DPFJbgJxnJXKlfqS9q36IgWsBbF+b9D4+4WnRE4Cytobv6ygesUGLDWSPpwy+vmO
TZ7wXE9srlO6vTPVaP4l81AyyPzv3ToOrADQSlB8Ua7oQm+5Oj7UNfbR+guu0/6E
FJeSapibJPAtaB76aPX0msiyqD3PMYuyG6ChQr4Y56IqP3lBGNgVIZMwJncgA3mu
YlR+s0a/gBANxO5nSRuj/1uAPAaMV1+7nYVbxa/bX+mKfWraFmVIx7D9eCU6lJrV
Tg3gpYU8q8WQokbAThkLQLsCmmsxXyjpkYKjCdTYn0vQqm5U4jE=
=faH0
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.