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 00:44:09 -0600
From: Kurt Seifried <>
CC: Moritz Muehlenhoff <>
Subject: Re: Thoughts on a vuln/CVE?

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").

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Version: GnuPG v1.4.13 (GNU/Linux)


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.