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-08-2010, 11:14 PM
Russell Coker
 
Default Bug#540215: Introduce dh_checksums

On Tue, 9 Mar 2010, Joey Hess <joeyh@debian.org> wrote:
> Russ Allbery wrote:
> > The missing link, in this validation scenario, is how to get a signed
> > copy of the MD5 checksums of the files in the package.
>
> That's one missing link. The other one is that there are innumerable
> ways for an attacker to inject bad behavior/backdoors onto a system
> without touching binaries originating from dpkg. Expecting debsums to
> protect against any form of attack is bound to result in a false sense
> of security; and AFAIK aide makes a credible[1] attempt at solving the
> same problem.

> [1] Though my SWAG is that it's still not complete when you consider
> * * the boodloader, permissions of files in /dev, or subtly corrupted
> * * partitions.

http://etbe.coker.com.au/2010/03/08/designing-secure-linux/

I blogged about some of these things yesterday.

--
russell@coker.com.au
http://etbe.coker.com.au/ My Main Blog
http://doc.coker.com.au/ My Documents Blog


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201003091114.23871.russell@coker.com.au">http://lists.debian.org/201003091114.23871.russell@coker.com.au
 
Old 03-09-2010, 02:31 AM
Harald Braumann
 
Default Bug#540215: Introduce dh_checksums

On Mon, Mar 08, 2010 at 11:04:24PM +0100, Frank Lin PIAT wrote:
> On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
> > 1. Strengthen the integrity check so that it could potentially be useful
> > for security purposes as well as for simple integrity checking.
>
> It would be much easier if a signed list of check-sums for current
> packages in our archive were published (basically, when we create
> Packages.gpg, we would need to extract the checksums contained in those
> packages, then sign it. This list could also included the recently
> updated packages, which is useful for point-releases, and unstable).

I'm a bit confused here. I think that here is a mix of package
signatures and file signatures. These serve different purposes and are
completely separate. A package signature lets you verfy the package
before it is decompressed and, more importantly, maintainer scripts
are run as root. File signatures let you check the installed files.

Both should be part of the shipped package. Package signature as files
in the arch archive, file signatures should be installed along with
the files so you can always directly check installed files, without
the need of any repository or original packages lying around.

>
> The benefit is that you can quickly audit if installed binaries are
> pristine AND current.
>
> > If we take option 1, going to a stronger hash is strictly less useful in
> > every respect than going to embedded PGP signatures

Assuming file hashes here: create stronger hashes and then sign the
hash file. This has 2 advantages:
- hashes can be used to check file integrity even without the key
- it can be implemented incrementally (1st: stonger hashes, 2nd:
signature)

> > which apparently only require active maintenance and a plan to be
> > acceptable in the archive and which would need a different format
> > anyway.

Assuming package hashes here: a view additional files in the arch archive.

>
> I see some problems with signed packages:
>
> 1. Software developers and vendors will start distributing standalone
> binary packages, and pretend they are "safe" because they are signed.
> This is not safe: only an APT-like mechanism provides security
> updates.

Yes, there seems to be a common misconception about what a signature
means. But that's no argument to deny informed people the advantages
of signatures.

> 2. You still need an infrastructure to publish valid packages version.

Isn't that the Release file?

> 3. What do we do when we want to change a GPG key? we re-sign all
> the packages, probably breaking existing packages checksums?

No, the signature has a timestamp and is still valid, if the
revocation date of key is later.

> Last but not least:
>
> 4. How long is it going to implement it? Does it seems realistic to
> implement your proposal before Squeeze +1 (or event Squeeze +2)?
> What do we do in-between?
>
> > If we take option 2, SHA256 offers no benefits over MD5 and just takes
> > longer to compute.
>
> Why is that everyone seems to move away from MD5?

Because it's broken?

>
> > There is essentially zero chance that random file corruption or
> > typical local modification will result in a successful MD5 preimage
> > attack.
>
> An attacker has plenty of time to pre-compute a valid replacement for,
> let say, a library in Debian Stable.
>
> > I therefore have to question what utility there is in switching to SHA256.
> > It doesn't seem to achieve either possible goal, unless I'm missing some
> > way in which it's a step towards option 1?

See above.

> As a bottom line:
> 1. A package is not safe because it is signed, but because it is
> up-to-date.

A signature hasn't got anything to do with how safe a package is.

harry


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100309033126.GA15017@nn.nn">http://lists.debian.org/20100309033126.GA15017@nn.nn
 
Old 03-09-2010, 02:38 AM
Harald Braumann
 
Default Bug#540215: Introduce dh_checksums

On Mon, Mar 08, 2010 at 05:59:13PM -0500, Joey Hess wrote:
> Russ Allbery wrote:
> > The missing link, in this validation scenario, is how to get a signed copy
> > of the MD5 checksums of the files in the package.
>
> That's one missing link. The other one is that there are innumerable
> ways for an attacker to inject bad behavior/backdoors onto a system
> without touching binaries originating from dpkg.

Signatures don't prevent bugs, they don't prevent trojans, they don't
prevent attacks on SSH. But they let you *detect* attacks. It's not
that easy to install a root kit that hides all changes and you can
always boot from a trusted medium to check your files. Without
signatures, you can't, or at least it a lot harder.

> Expecting debsums to
> protect against any form of attack is bound to result in a false sense
> of security;

I don't expect that.

harry


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100309033842.GB15017@nn.nn">http://lists.debian.org/20100309033842.GB15017@nn.nn
 
Old 03-09-2010, 02:44 AM
Russ Allbery
 
Default Bug#540215: Introduce dh_checksums

Harald Braumann <harry@unheit.net> writes:
> On Mon, Mar 08, 2010 at 05:59:13PM -0500, Joey Hess wrote:

>> That's one missing link. The other one is that there are innumerable
>> ways for an attacker to inject bad behavior/backdoors onto a system
>> without touching binaries originating from dpkg.

> Signatures don't prevent bugs, they don't prevent trojans, they don't
> prevent attacks on SSH. But they let you *detect* attacks. It's not that
> easy to install a root kit that hides all changes and you can always
> boot from a trusted medium to check your files. Without signatures, you
> can't, or at least it a lot harder.

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. We should always be striving
for the best possible security and improving security measures, but along
the way security measures that have weaknesses against a determined
attacker can still be practically useful.

It's a constant balance to not sacrifice real security for expediency, but
at the same time to not discard tools that are already available and
deployable just because they can't catch the most determined attackers.
*Some* checking is better than *no* checking as long as you clearly
understand what the capabilities and tradeoffs of the system you have are
and don't think they're more than what they are.

There are very, very few absolutes in computer security.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k4tmupju.fsf@windlord.stanford.edu">http://lists.debian.org/87k4tmupju.fsf@windlord.stanford.edu
 
Old 03-09-2010, 02:49 AM
Joey Hess
 
Default Bug#540215: Introduce dh_checksums

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.

--
see shy jo
 
Old 03-09-2010, 02:57 AM
Russ Allbery
 
Default Bug#540215: Introduce dh_checksums

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. I'm on the side that thinks
that debsums isn't a horribly useful direction to go for full-blown
intrusion detection, and that for what it's really useful for right now
MD5 remains entirely adequate.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d3zeuoxr.fsf@windlord.stanford.edu">http://lists.debian.org/87d3zeuoxr.fsf@windlord.stanford.edu
 
Old 03-09-2010, 07:28 AM
Frank Lin PIAT
 
Default Bug#540215: Introduce dh_checksums

On Mon, 2010-03-08 at 19:57 -0800, Russ Allbery 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. I'm on the side that thinks
> that debsums isn't a horribly useful direction to go for full-blown
> intrusion detection, and that for what it's really useful for right now
> MD5 remains entirely adequate.

How do people know which binaries are still pristine, so they can keep
looking for issues elsewhere? (like added binaries and modified and
insecure configuration file...)
Not everyone uses aide (popcon: 0.49%).

What solution do we have for Joe user (whom did not install aide)?
What's the agenda for squeeze and squeeze+1?
Who is actually stepping up to do the Job?

Please, let's do the easy move *now* for Squeeze, using shasums, and go
ahead later with an even better solution. This transition can be quick,
it will remain quite unnoticed by people that aren't interested, but it
will be appreciated by people who want to use it.

Regards,

--
Franklin Piat | The better is the enemy of the good. (Voltaire)




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1268123295.21347.12099.camel@solid.paris.klabs.be" >http://lists.debian.org/1268123295.21347.12099.camel@solid.paris.klabs.be
 
Old 03-09-2010, 11:59 AM
Harald Braumann
 
Default Bug#540215: Introduce dh_checksums

On Mon, Mar 08, 2010 at 10:49:54PM -0500, Joey Hess wrote:
> 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.

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.

If I understand you correctly, you argue that one would need some IDS
anyway to cover all files, and that could then be used also to verify
package files. Therefore making file signatures in packages
superfluous. I think I could agree with that. On the other hand, I
tend to keep /usr/local clean and create packages for for home-grown
software. If you do this consistently, you'd get a system where you
could verify all files without additional software (modulo the script
that checks for surplus files).

More important would be package signatures, anyway, because
currently there is no way to verify a package. I work with
testing/unstable a lot and often I have deb files lying around are
not in any Release, so there is no way of verifying them.

harry


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100309125920.GC15017@nn.nn">http://lists.debian.org/20100309125920.GC15017@nn.nn
 
Old 03-09-2010, 12:24 PM
"Bernhard R. Link"
 
Default Bug#540215: Introduce dh_checksums

* Harald Braumann <harry@unheit.net> [100309 13:59]:
> On Mon, Mar 08, 2010 at 10:49:54PM -0500, Joey Hess wrote:
> > 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.
>
> 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.

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.

Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100309132432.GA30790@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20100309132432.GA30790@pcpool00.mathematik.uni-freiburg.de
 
Old 03-09-2010, 12:32 PM
Jean-Christophe Dubacq
 
Default Bug#540215: Introduce dh_checksums

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.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4B964E0B.3060003@free.fr">http://lists.debian.org/4B964E0B.3060003@free.fr
 

Thread Tools




All times are GMT. The time now is 01:24 AM.

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