FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-09-2010, 01:21 PM
Peter Samuelson
 
Default Bug#540215: Introduce dh_checksums

> On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
> > If we take option 2, SHA256 offers no benefits over MD5 and just takes
> > longer to compute.

[Frank Lin PIAT]
> Why is that everyone seems to move away from MD5?

That's the $64000 question, isn't it? There seems to be this knee-jerk
reaction to all things md5, "OH NOES, MD5 is broken! Therefore it must
be replaced in every possible use, never mind whether any particular
use has anything to do with malicious attackers."

Strange that rsync seems to have escaped this madness, nobody has been
frantically calling for it to migrate to something more "up to date"
than MD4. Which, IIRC, is just as "broken". I guess the masses must
have realized, in a way they usually do not, that sometimes an
integrity check is just an integrity check.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100309142149.GP18278@p12n.org">http://lists.debian.org/20100309142149.GP18278@p12n.org
 
Old 03-09-2010, 02:25 PM
Jakub Wilk
 
Default Bug#540215: Introduce dh_checksums

* Peter Samuelson <peter@p12n.org>, 2010-03-09, 08:21:

[Frank Lin PIAT]

Why is that everyone seems to move away from MD5?


That's the $64000 question, isn't it? There seems to be this knee-jerk
reaction to all things md5, "OH NOES, MD5 is broken! Therefore it must
be replaced in every possible use, never mind whether any particular
use has anything to do with malicious attackers."

Strange that rsync seems to have escaped this madness, nobody has been
frantically calling for it to migrate to something more "up to date"
than MD4. Which, IIRC, is just as "broken". I guess the masses must
have realized, in a way they usually do not, that sometimes an
integrity check is just an integrity check.


FYI:
$ zgrep MD5 /usr/share/doc/rsync/changelog.gz
- Protocol 30 now uses MD5 checksums instead of MD4.

That said, I totally agree with you.

--
Jakub Wilk
 
Old 03-09-2010, 02:56 PM
Manoj Srivastava
 
Default Bug#540215: Introduce dh_checksums

On Tue, Mar 09 2010, Jean-Christophe Dubacq wrote:

> On 09/03/2010 14:24, Bernhard R. Link wrote:
>
>>
>> It it's that straight forward, please help with the cruft package.
>> Last time I looked (several years ago) it was severly limited by that
>> problem (there not being a way to know which files should be there and
>> which not).
>>
>> I personally think without something in this direction, intrusion
>> detection based on file lists is not really possible.
>
> I for one pledge the addition of a dpkg-register (or dpkg --register or
> anything), bound with dpkg, that would allow maintainers to specify that
> a file belongs to their package (it could be managed through postinsts,
> via ucf...) The number of files under /etc that belong to no package (in
> the sense of dpkg -S) makes it very hard to keep a clean system.

For what it is worth, ucf can also tell dpkg about the files and
hashes that it manages (it already stores the data, all that has to be
added is calls to the hypothetical dpkg-register).

manoj
--
Oliver's Law: Experience is something you don't get until just after you
need it.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pr3dbib2.fsf@anzu.internal.golden-gryphon.com">http://lists.debian.org/87pr3dbib2.fsf@anzu.internal.golden-gryphon.com
 
Old 03-09-2010, 03:50 PM
Peter Samuelson
 
Default Bug#540215: Introduce dh_checksums

[Frank Lin PIAT]
> Please, let's do the easy move *now* for Squeeze, using shasums, and
> go ahead later with an even better solution.

Drawbacks: more CPU time on build daemons, slightly larger binary
packages to download, and some disruption when we're trying to get a
release out the door.

Advantages: ... umm ... warm fuzzy feeling that we aren't relying on
that old stupid broken MD5 thing that is so out of fashion these days
among the cognoscenti?

If you really want to use /var/lib/dpkg/info/pkg.*sums files for any
purpose other than detecting non-malicious corruption, obviously you
need _either_ some form of package signatures, _or_ a server akin to
http://packages.debian.org/changelogs/ for serving checksums from a
more trusted source. And of course if you have that sort of server
support anyway - why not just calculate those sha16384 sums on the
server, with no change to the debs at all?

Peter


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100309165059.GR18278@p12n.org">http://lists.debian.org/20100309165059.GR18278@p12n.org
 
Old 03-09-2010, 03:55 PM
Joey Hess
 
Default Bug#540215: Introduce dh_checksums

Harald Braumann wrote:
> On Mon, Mar 08, 2010 at 10:49:54PM -0500, Joey Hess wrote:
> > It's stupid and straightforward to install /usr/local/bin/ls. debsums
> > will not detect it.
>
> And it's as straightforward to find files which don't belong to any
> package and have some other means in place to check locally generated
> files.

I don't want to get dragged into continuing to provide counterexamples,
but it's also fairly easy to modify a file in /etc to provide a
backdoor, such that neither debsums nor cruft will notice it.

--
see shy jo
 
Old 03-09-2010, 05:35 PM
Harald Braumann
 
Default Bug#540215: Introduce dh_checksums

On Tue, Mar 09, 2010 at 10:50:59AM -0600, Peter Samuelson wrote:
>
> [Frank Lin PIAT]
> > Please, let's do the easy move *now* for Squeeze, using shasums, and
> > go ahead later with an even better solution.
>
> Drawbacks: more CPU time on build daemons, slightly larger binary
> packages to download, and some disruption when we're trying to get a
> release out the door.
>
> Advantages: ... umm ... warm fuzzy feeling that we aren't relying on
> that old stupid broken MD5 thing that is so out of fashion these days
> among the cognoscenti?
>
> If you really want to use /var/lib/dpkg/info/pkg.*sums files for any
> purpose other than detecting non-malicious corruption, obviously you
> need _either_ some form of package signatures, _or_ a server akin to
> http://packages.debian.org/changelogs/ for serving checksums from a
> more trusted source. And of course if you have that sort of server
> support anyway - why not just calculate those sha16384 sums on the
> server, with no change to the debs at all?

See, you don't need a server. You just ship a signature over the hash
files. Easy as that. Of course the hashes would neet to be something more
secure than md5, for that warm fuzzy feeling that in two years time
not every script kiddy can mount hash attacks on their home computer.

harry


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100309183541.GA25679@nn.nn">http://lists.debian.org/20100309183541.GA25679@nn.nn
 
Old 03-09-2010, 06:45 PM
Anthony Towns
 
Default Bug#540215: Introduce dh_checksums

Hey Russ,

On Tue, Mar 9, 2010 at 13:57, Russ Allbery <rra@debian.org> wrote:
> Joey Hess <joeyh@debian.org> writes:
>> Russ Allbery wrote:
>>> It's also always worth bearing in mind that while a really good
>>> attacker can do all sorts of complex things that make them very hard to
>>> find, most attackers are stupid and straightforward.
>> It's stupid and straightforward to install /usr/local/bin/ls. debsums
>> will not detect it.
> True. *Adding new binaries is, in my experience, more common than
> modifying binaries already on the system.
> I don't really mean to be arguing for debsums as a security mechanism,
> more just commenting on the general question.

So what's the goal here? Basic integrity checking by defending against
random corruption due to occassional hardware, software or admin
errors? Or an additional security layer verifying that the installed
system software is still exactly what it was intended to be?

(Or, I guess, a third option would be that it's just some security
theatre to make people feel more comfortable about their system's
integrity, without actually adding any technical guarantees.)

For basic integrity checking, I'm finding the dpkg patch I posted the
other day works fairly nicely -- I've reinstalled the handful of
packages that don't provide md5sums files so dpkg would generate the
hashes file for me, and now I've got hashes for every package on my
system, without having to worry about policy getting changed or
packages getting reuploaded, or having to worry about bugs like any
random packages I might use not following the new policy.

And now that I actually look at debsums, rather than just checking
with md5sum -c directly, I see debsums already gets invoked by apt by
default to ensure that there's an md5sums file for every package. And
that's been there for a fair while, based on Bug#132767.

If the idea is just to catch a wide swathe of accidental errors,
doesn't it make sense to stick with md5 as being cheap and unlikely to
have accidental collisions, do the md5sum generation in either apt or
dpkg to guarantee it's done for all installed packages, and leave it
at that? That means we could get rid of a bunch of policy and code
from package build scripts, which seems like it could only be a good
thing; and it also seems pretty easy to do for squeeze (since it's
already done as far as apt is concerned, and there's a patch for dpkg
if desired, and no other packages need to be changed).

The only drawback seems to be that you end up verifying what was
actually installed, and that might differ from verifying what was
meant to be installed in the event that the deb you're installing gets
corrupted while you're reading it, despite having previously passing
its own secure hash check.

OTOH, if the idea is to do more than just basic integrity checking of
dpkg-installed files, to aid in detection of and recovery from
malicious/deliberate changes, it seems like there's a lot of things
that ought to be done differently to how debsums/pkg.md5sums work
(secure hash, checking conffiles, stuff in /var, checking added files,
checking additional diversions, preventing
addition/deletion/modification of the md5sums files...).

(Well, better handling of the md5sums files themselves could be useful
for basic integrity checking too -- a disk/fs error that trashes files
in /var/lib/dpkg/info/ can be inconvenient too)

Cheers,
aj

--
Anthony Towns <aj@erisian.com.au>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87b3a4191003091145p26467cag8d2d4cfb9dc20dcb@mail.g mail.com">http://lists.debian.org/87b3a4191003091145p26467cag8d2d4cfb9dc20dcb@mail.g mail.com
 
Old 03-10-2010, 04:11 AM
Peter Samuelson
 
Default Bug#540215: Introduce dh_checksums

[Harald Braumann]
> See, you don't need a server. You just ship a signature over the hash
> files. Easy as that.

And that signature - if you don't have a server - you probably want to
store it in the .deb, right? So you are going to be editing the .deb
after it is built. At which time, you could just as well compute your
SHA16384 hashes, sign those, and store them. That way you can even use
an attached (as opposed to detached) gpg signature, without confusing
downstream tools.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100310051154.GS18278@p12n.org">http://lists.debian.org/20100310051154.GS18278@p12n.org
 
Old 03-10-2010, 01:32 PM
Wouter Verhelst
 
Default Bug#540215: Introduce dh_checksums

On Mon, Mar 08, 2010 at 12:59:00PM -0800, Russ Allbery wrote:
> Frank Lin PIAT <fpiat@klabs.be> writes:
>
> > Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
> > recent checksum.
>
> > The way it is implemented, is that the dh_md5sums is a symlink to the
> > new dh_checksums. The new helper computes both md5sum (for
> > compatibility/transition) and a new checksum (SHA256, which was already
> > chosen by FTP-masters as a remplacement for md5sum for signed files)
>
> If there's a general consensus that we should go this route, I'm okay with
> it, but I'm personally not sure this is the right approach.
>
> I think there are two possible directions we can take with this package
> feature:
>
> 1. Strengthen the integrity check so that it could potentially be useful
> for security purposes as well as for simple integrity checking.
>
> 2. Declare such checksums only useful for corruption and local (benign)
> modification checksumming.
>
> If we take option 1, going to a stronger hash is strictly less useful in
> every respect than going to embedded PGP signatures, which apparently only
> require active maintenance and a plan to be acceptable in the archive and
> which would need a different format anyway.

Maybe, but we're not there yet.

At any rate, a PGP signature takes a lot of data; much more so than a
checksum. It's therefore more economical to produce a signed
package.checksums file than it is to produce a package.pgpsigs.

Having package.checksums be GPG-signed will take a significant change in
our infrastructure (buildd hosts, for instance, would need to have a way
to sign checksums files as well), so it's not going to happen tomorrow.
But changing to a more secure checksum algorithm could be done easily
with current infrastructure.

And since checksum files are generated at build time rather than at
install time, it is possible to download a known-good copy of the .deb
that is installed (using snapshot.debian.org, once it gets live, for
instance, or from a not-compromised host's apt cache), and verify the
files against that copy rather than the copy that is on the disk. Until
signed packages or signed checksums are available, this would of course
be a stopgap measure, but one that would actually work -- provided, of
course, that the used checksum algorithm is cryptographically secure,
which MD5 is no longer.

> If we take option 2, SHA256 offers no benefits over MD5 and just takes
> longer to compute. There is essentially zero chance that random file
> corruption or typical local modification will result in a successful MD5
> preimage attack.

Of course, that much is true.

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100310143214.GE10578@celtic.nixsys.be">http://lists.debian.org/20100310143214.GE10578@celtic.nixsys.be
 
Old 03-10-2010, 04:13 PM
Peter Samuelson
 
Default Bug#540215: Introduce dh_checksums

[Wouter Verhelst]
> At any rate, a PGP signature takes a lot of data; much more so than
> a checksum. It's therefore more economical to produce a signed
> package.checksums file than it is to produce a package.pgpsigs.

Huh? Since asymmetric cryptography is so computationally expensive,
PGP never signs the payload directly. Instead, the payload is hashed
and then the hash is signed. So it is not (noticeably) more economical
to sign foo.md5sums than to sign the whole data.tar.gz.

[Same goes for encrypting: PGP encrypts with a conventional block
cipher like AES and a randomly generated key, then encrypts the _key_
using RSA. Again, this is for efficiency.]

Or is this not what you meant? I'm confused.


> And since checksum files are generated at build time rather than at
> install time, it is possible to download a known-good copy of the
> .deb that is installed (using snapshot.debian.org, once it gets live,
> for instance, or from a not-compromised host's apt cache), and verify
> the files against that copy rather than the copy that is on the disk.

If you're going to the trouble to download a .deb, why bother with
signatures at all? Why not just compare the full text directly?

If you have a .deb on a different host and don't want to transfer the
entire thing over the network, well, no reason you can't do your
SHA16384 on both ends, and transfer only the hashes at that time.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100310171331.GT18278@p12n.org">http://lists.debian.org/20100310171331.GT18278@p12n.org
 

Thread Tools




All times are GMT. The time now is 03:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org