Date: Fri, 2 Mar 2018 21:42:30 -0700 From: Kurt Seifried <kseifried@...hat.com> To: oss-security <oss-security@...ts.openwall.com> Subject: Re: memcached UDP amplification attacks So long story short: A CVE is assigned when a security vulnerability "crosses a trust boundary", so for something that is easy, e.g. remote RCE, or "ping of death" (a single ICMP packet that crashes the remote system, that was a fun week). For a lot of things like encryption and denial of service the line in the sand is somewhat arbitrary. For example a traffic amplification attack that is 1:1 is probably not going to get a CVE today, but for example a 1:50000 traffic amplification (so 1 megabit/sec turns into ~= 50 gigabits/second) is clearly a problem, especially if it's via UDP which can 1) be spoofed and 2) can result in the remote end just firing the traffic off blindly. I am told this memcached attack is causing traffic reflection well past 1:5 (an arbitrary line I've drawn in the sand, 1:2 isn't enough to really worry about with some exceptions, and 1:10 is clearly a problem, so because of how many fingers we mostly have, 1:5 seems fair), in fact this attack is seeing amplification by several orders of magnitude past 1:5. Also memached has fixed this in release 1.5.6 by disabling UDP by default (one metric for CVE is "can this be fixed", if yes that's a good sign we didn't want the previous behavior). I have assigned CVE-2018-1000115 to this issue: Memcached version 1.5.5 contains an Insufficient Control of Network Message Volume (Network Amplification, CWE-406) vulnerability in the UDP support of the memcached server that can result in denial of service via network flood (traffic amplification of 1:50,000 has been reported by reliable sources). This attack appear to be exploitable via network connectivity to port 11211 UDP. This vulnerability appears to have been fixed in 1.5.6 due to the disabling of the UDP protocol by default. References: "url": "https://github.com/memcached/memcached/wiki/ReleaseNotes156" "url": " https://blogs.akamai.com/2018/03/memcached-fueled-13-tbps-attacks.html" "url": "https://twitter.com/dormando/status/968579781729009664" "url": " https://github.com/memcached/memcached/commit/dbb7a8af90054bf4ef51f5814ef7ceb17d83d974 " On Fri, Mar 2, 2018 at 4:58 AM, Kurt Seifried <kseifried@...hat.com> wrote: > > > On Fri, Mar 2, 2018 at 4:44 AM, Hanno Böck <hanno@...eck.de> wrote: > >> Hi, >> >> In the past days there have been reports about some DDoS attacks >> abusing the memcached UDP protocol: >> https://blog.cloudflare.com/memcrashed-major-amplification- >> attacks-from-port-11211/ >> https://www.wired.com/story/github-ddos-memcached/ >> >> >> The issue: memcached has an UDP protocol that allows getting a much >> larger reply than the query sent, thus allowing amplification attacks >> with forged sender IPs. >> >> >> Upstream memcached reacted by disabling the UDP-based protocol by >> default: >> https://github.com/memcached/memcached/wiki/ReleaseNotes156 >> This is good, however one could argue that they should also default to >> localhost only. >> >> >> Most distros I checked right now default to enabling UDP, but >> restricting connections to 127.0.0.1. While this is not directly >> vulnerable it's only a minor change away from being so. The memcached >> announcement sounds like the UDP protocol is rarely used and should be >> considered deprecated and replaced by the TCP-based one. >> >> I recommend all distributions consider changing their defaults to >> disabling the UDP-based memcached protocol by default. >> >> > I think in general ALL network applications that support UDP need to think > about hardening their default configurations due to the potential for > amplification attacks. > > While it is not yet CVE worthy I can see the bar moving (much like it has > for default passwords, and crypto) in the near future as this is clearly > becoming a problem. Please note that this problem is already covered by > CWE-406 (to some degree) which makes the case for CVE assignment stronger. > > >> -- >> Hanno Böck >> https://hboeck.de/ >> >> mail/jabber: hanno@...eck.de >> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 >> > > > > -- > > Kurt Seifried -- Red Hat -- Product Security -- Cloud > PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > Red Hat Product Security contact: secalert@...hat.com > -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact: secalert@...hat.com
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.