Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 24 Mar 2015 16:53:30 +0300
From: Alexander Cherepanov <>
Subject: Re: CVE for Kali Linux

On 2015-03-24 13:51, Marcus Meissner wrote:
> On Mon, Mar 23, 2015 at 10:41:01PM +0100, Marcus Meissner wrote:
>> On Tue, Mar 24, 2015 at 12:13:06AM +0300, Alexander Cherepanov wrote:
>>> On 2015-03-23 13:38, Marcus Meissner wrote:
>>>>> There are some attacks even if you verify signatures, e.g. serving
>>>>> old, known-vulnerable versions. HTTPS can help here (until
>>>>> signatures start to be widely accompanied by expiring timestamps or
>>>>> something).
>>>> SUSE has added an expiry tag in the YUM metadata for such cases.
>>> It's nice to see progress in this area. Does SUSE guard against
>>> other attacks from [1] too?
>>> [1]
>> Our statements from 2008 (7 years ago) still stand and our package
>> manager does the full repository signing since 2006 already.

Judging only from this text, it seems that one of the crucial points of 
your system is "[t]he openSUSE download redirector [that] serves the 
metadata from a known and trusted source". And it lives at... and is not available over HTTPS at all?

>> "Endless Data Attack" is open, as it is hard to solve for openSUSE with
>> its public mirror system.

If you have signed metadata it should be easy to counter this attack for 
packages, right? If you serve you metadata from a trusted source then 
it's also solved for metadata. Even if you serve metadata over 
non-trusted channel it should be easy to bound the size of "root" 
metadata file and record sizes of the next level files in it, etc. Am I 
missing any complications?

>> The expiry was something added a bit later after the paper to address
>> the downgrade and replay attacks.
> Some more notes.
> While the "Update Scenario" is well covered, we are of course facing issues of "bringing up a system".
> Like discussed in the thread, how does the customer find a known good ISO image
> for download.
> While our installer is protecting itself with GPG signatures, but there is need for
> the root of trust of the CD medium itself.
> So for SUSE we publish SHA256 checksums on the website at least.
> For openSUSE the GPG/SHA and MD5 are on .

Hm, it's HTTP and a big part of this thread is about dangers of exactly 
this situation.

Alexander Cherepanov

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.