Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Oct 2016 20:57:32 -0400 (EDT)
Subject: Re: CVE Request: IKEv1 protocol is vulnerable to DoS amplification attack

Hash: SHA256

> I think it's safe to say an amplification of 1:10 or more qualifies as a
> problem, I'm not sure what the exact amplification ratio to qualify for a
> CVE is (1:3, 1:7?) but I think 1:10 or more should definitely qualify.

The MITRE CVE Team has commented on this in the past in the post. Although
there have been relevant changes since then (such as expansion of the
CVE CNA program), we're still not sure that it generally makes sense
to define magic numbers (such as a magic minimum number for the
amplification ratio) that everyone always must use to decide whether a
CVE is useful.

For example, if an organization is a CNA for its own products and sees
an amplification ratio of 1:1.1, but this violates the intended
security policy of a product and was supposed to be 1:0.9, then they
can assign a CVE ID. If they're recommending that their customers
install a patch, then it could make a lot of sense to have a CVE ID,
so that their customers can use the ID in patch management.

However, some CNA organizations assign CVE IDs to arbitrary vendors'
products based on claims of demonstrated negative impact: this is
where amplification may pose more difficulty for CVE. As it stands
today, a CVE ID requester can claim that 1:1.1 has a demonstrated
negative impact, and (at least in theory) they will get a CVE ID. This
type of CNA currently can't make up their own arbitrary rules, such as
"1:10 is a negative impact but 1:9 isn't."

There are at least three different scenarios:

 1. Amplification only exists because of a server-side coding error,
    and fixing that error has no adverse impact on clients and
    requires no client-side changes. For example: for the protocol in
    question, the client simply never needs an unauthenticated UDP
    request to result in a larger UDP reply.

 2. Amplification is not caused by a coding error, but it is possible
    to reduce the amplification ratio without completely breaking the
    ability of clients to communicate with servers.

 3. Amplification is not caused by a coding error, and it is not
    possible to reduce the amplification ratio without completely
    breaking the ability of clients to communicate with servers. The
    only options are to mitigate attacks (as in or to change
    the protocol.

If someone can request a CVE ID for any of these three scenarios,
should we encourage them to be most liberal with CVE ID requests in
scenario 1, and most conservative with CVE ID requests in scenario 3?
Or do we ideally want to enumerate everything, even a 1:1.1 ratio
that's baked into a protocol design, and can't be fixed without
changing every client and server?

Finally, do we want CVEs for all types of amplification, or only
amplification that can be used for DoS attacks against unrelated third
parties? For example, there's a class of amplification issues
affecting automated error reporting. This can exist in server-side
code in which exception handlers (something like "constraint
violation: length_a > length_b") are able to send outbound network
traffic to a vendor's server. Here, there can be cases where an
attacker sends an unauthenticated hundred-byte packet to a customer's
server, and the customer's server then immediately sends a
million-byte system-health report to the vendor. The attacker
generally can repeat this, although there might be a rate limit.
Suppose that the customer wants to send these reports, and the vendor
wants to receive these reports, and (maybe?) the intervening ISPs can
handle the load. Would this be a CVE because of the huge amplification
ratio, or is amplification a CVE only in certain special cases?

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ