Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Jun 2013 11:16:34 +0100
From: Dave Walker <>
Subject: Re: Thoughts on a vuln/CVE?

On 18 June 2013 07:44, Kurt Seifried <> wrote:
> Hash: SHA1
> On 06/18/2013 12:24 AM, Moritz Muehlenhoff wrote:
>> On Tue, Jun 18, 2013 at 12:04:30AM -0600, Kurt Seifried wrote:
>> [..]
>>> We have software with a now insecure configuration as it points
>>> to a site that may or may not be under attacker control. It seems
>>> to me like this might be a candidate for a CVE. Thoughts and
>>> comments for and against are welcome (I'm on the fence myself).
>> No way. This is not an insecure configuration: This was never a
>> Debian service and people are free to put whatever they want in
>> /etc/apt/sources.list. There are hundreds of external apt sources
>> and everyone of them could have their owner changed at some point.
>> Also there's no security issue: If a domain is grabbed and someone
>> configures an apt repository on the site, he/she would lack the
>> repository key previously used to sign the repo.
>> Cheers, Moritz
> Ah thanks, I forgot about that (I don't use Debian that often). So
> with the signing key requirement in mind this is not a vuln.
> However my original question still stands, can/should we consider a
> common configuration of software that goes from being secure to
> insecure to be worthy of a CVE? A lot of things that used to be common
> practice (like shipping every service/server enabled, all accounts
> active, all access enabled, anonymous uploads allowed, etc.) are now
> seen as security vulnerabilities/exposures.
> As for the security of the repo key proving that it it is safe/not
> compromised would be hard, I'm guessing it wasn't held on an HSM, and
> was it securely destroyed, or?
> Also part of my thought process is that (for example) this would be a
> good configuration to check for and ensure is disabled, something for
> SCAP for example or the Debian security guide (e.g. a generic "make
> sure all enabled repos are actually working as expected").


If a weakness in Debian's package management system signature
verification was identified recently, then this specific issue of
debian-multimedia deserves dedicated attention as it would be a useful
contributing vector; but until then - this isn't an documentable
exposure risk IMO.

Comparing to the definition we use for 'Exposure', a "system
configuration issue" certainly fits the grounds to be assigned a CVE
identifier, but arbitrary package archives which are signed are not
tied to a specific host (re-mirroring is often encouraged), as the
assurance is provided by the signature - not by any means of

I think the direction Kurt is moving towards is making sure every
distro is thinking what would happen if a popular update domain
changes ownership, is this case considered?  If a CVE identifier helps
make this co-ordinated, then - well, there have been worse uses for
identifiers. :).

Kind Regards,
Dave Walker

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.