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
Description: S/MIME cryptographic signature
