[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun Mar 6 11:01:47 UTC 2016
From: me@...fdog.net
To: oss-security@...ts.openwall.com
Subject: Re: Concerns about CVE coverage shrinking - direct impact to researchers/companies
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In my opinion, most of the points brought up in discussion are valid
topics to be addressed, I just believe, that another method might be
more suitable.
As an example, I use the topics from Tim's e-mail ....
Tim wrote:
>
>> Of course, the information will need to be available to those
>> third-party databases from somewhere - but this can be the
>> researcher's or the vendor's disclosure, as you say. Until such
>> disclosure, a customer would not even be aware of the ID, let
>> alone want to look it up.
>
> The trouble with third-party databases is that they aren't a reliable
> archive of information. I can't tell you how many times I've found a
> vulnerability scanner detecting an issue, and I go back to get more
> details to understand the risk, only to find all the technical
> details have been taken offline.
See g)
> It is a major gap in the security community's (and IT industry's)
> tool set that we don't have a reliable, single archive of
> vulnerability information.
See RFC
> It is a huge waste of time looking up every bug.
Copy the whole database
> And when I say "reliable" I merely mean the information won't go
> away tomorrow (like the old FD did so suddenly).
See b)
> I don't mean the information must always be true or validated, just
> available.
At least the origin and changes should be validated, see c, e.
> Providing something like this is clearly a significant undertaking
> and isn't something most security companies can make any real money
> at. *Maybe* a well-thought-out non-profit could accomplish this and
> still make ends meet by providing bulk feeds for a small
> subscription fee.
Well, if software would behave as below, I would have no problem hosting
a mirror, slow lines should not matter. I think quite some researchers
would contribute a little of their computational resources.
> Obviously a government has the resources to do this, if not always
> the competence. Currently my government is just "letting the
> Internet burn", as they say, so I'm not optimistic that DHS or
> whatever is going to step up.
I do not want to trust a single government to much, see h) how to handle
sensitive material without central trust.
>> A drawback is that such requests become somewhat
>> security-sensitive, if for yet unpublished issues. This is
>> already a major concern with CVE, where information may be subject
>> to unjustified risk for the purpose of merely getting an ID
>> assigned.
Also h)
> That's a good point. As a researcher, I want an ID very early in the
> process (before going public) so I can refer to it when interacting
> with a vendor and draft my advisory in advance. One *could* accept
> submissions "to be released on date ...", but then any database like
> that will become a target.
See e, h.
> So instead, this hypothetical web app could require only basic
> information about the products affected up front, and then allow
> arbitrary additions of content later. (Note I said additions, not
> changes).
See e, f. For first round, we could use a simple template for reporting,
but do not enforce its use. Let k) mark out good contributors, valuable
information.
> I think it should also allow anonymous submission, perhaps only with
> validation of email addresses (which could be burners).
Use c), the key does not need to contain any valid mail address or name,
it has only to be signed properly.
> It's all too easy for researchers to become victim of idiotic libel
> lawsuits. (Which then leads one to wonder what legal defenses the
> hosting org needs...)
Those caring about that, use h+j to give access only to trusted parties.
With the signed access request, they also sign a "contract" taking away
the risk from the contributor - e.g. the reader is legally allowed in
his jurisdiction to read the vulnerability information without any legal
consequences for him or the creator of the content. Also contributor is
not responsible for damages caused by leaks via reader. With j) going to
court would mean going not only against the contributor but all readers
(usually some major players within them) reducing the risk for the
contributor.
... to make following proposal
RFC: "Distributed Cryptoenhanced Vulnerability Enumeration (DCVE)":
To address the points mentioned before, assume we would take the a
blockchain database [0] approach to handle most of the issues for us.
a) Chain layout: Start a chain every year, so it will not grow arbitrary
large. The root entry is the PGP key of chain manager (some group, board
- - does not be the ones running the data systems)
b) Chain hosting: as the information is easy to distribute,
cryptographically secured, redundant, any number of volunteers can host
them.
c) Entry: A "permitted contributor" signature is made using one of the
previous keys already recorded onto the key of the new contributor.
d) Proof of work: To add elements perform calculation (1
non-parallelizable CPU-h? - this is also the minimal delay for updates),
thus limiting the amount of garbage to be added by adversaries.
e) Unique IDs: The unique ID for a DCVE entry is the SHA256-hash of the
first element dealing with that issue.
f) Updates: The entry may be updated by anyone, but usually one may want
to filter out all entries not from the creator. The creator may later on
approve foreign entry by adding a linking the record (or the key of the
contributor) to the chain by himself.
g) Related material: To keep chain entries small (16kb?), they may
reference external material via http(s)-URLs. If it is a single file,
checksum information can be added. When important material is found,
anyone feeling the need to mirror it can create an update to that entry
and add the reference to the mirrored data.
h) Sensitive information: Each DVCE chain may contain also encrypted
messages. The key can be added later on to the chain, thus making the
previously recorded information public.
i) Non-repudiation (create): Each added entry has to be signed with the
key of the creator)
j) Non-repudiation (read): When important for the creator, giving read
access to one encrypted DCVE-chain should only happen after receiving a
signed access-request.
k) Prioritizing: to ease sifting through the important entries, any
contributor can add a rating entry to DVCE chains to give opinion to
their risk but also the quality of the chain (thus contributors may
build a reputation, making it easier to get heard).
Any thoughts on the idea itself?
How to realize: summer of code?
hd
[0] https://en.wikipedia.org/wiki/Block_chain_(database)
- --
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlbb590ACgkQxFmThv7tq+4PTgCfRcFhPC3+BkTdmH46QwkCQDmO
/xgAmwauaNknTNgZEuSTtMXNEcFXSa9t
=//Ac
-----END PGP SIGNATURE-----
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.
