Date: Tue, 18 Oct 2016 20:57:32 -0400 (EDT) From: cve-assign@...re.org To: kseifried@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, huzaifas@...hat.com Subject: Re: CVE Request: IKEv1 protocol is vulnerable to DoS amplification attack -----BEGIN PGP SIGNED MESSAGE----- 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 http://www.openwall.com/lists/oss-security/2016/06/10/4 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 https://capec.mitre.org/data/definitions/490.html) 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 http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJYBsQAAAoJEL54rhJi8gl56W0P/jtr8bg19CgitqtWv8GwYdKz KiVIsAqVZqu3IYnnBIpwyFQDvSo+utqAn7/heUU7V18JMxsUttPNJVArwLpZZ57s 71HYDuqlhDtqLL2HkwU7bU2XtCbUiO/LAAlnFuKxsbHMoYlkz+Dgfcd5gtdbJhcG WmLcRRgDSZV3w7yWghBThCGAgjRWU3Pw0qqo1p/a+abR8By3NGI1yRiwhj5Jxc/u NYRQLwqbQIu1qH9OJXcOf8TnB1lytTCwKk0u3hXXyIWNSDdRAYQv4712Af7sSuVh +jYOGu3mhrOBjamtZNDMrJ9riFTRnoIbOSE+mCL/Kp+rTq22NX+rY3pkh/VfvCC2 /jF4aO1HUjxHKEmKauVoTAO10w6FPzlRmOMj7kM22oy568MD6LygWspNc9c/LvJX N/hEazu2NiUX3wNsLsA4z1mLUebtjjBoL/BgAAkJ1S1aoK2JEn9y5rK4wf1vCbia XkwHxoLu0BMznTIOHiP72G1YZs2FJd/pNw9iFvi6GRxPdLRR8Tr9FCRjv4V7mvRg E8rgYe3Vlz8Y9A1SYwmLLTKqqNgB/GnQNU3qKlUjmAfGiK2VGjvHah3BcOY4Gutq xcyb4Hdy/kyvxOQo6iHpabZPxYHGKVIM+CRTClnEqQM2OWiMxmv/pfVv8sL71uTJ VMx2oAIYBoExovJrb2pG =xNIJ -----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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ