Re: memcached UDP amplification attacks

[Kurt Seifried <kseifried () redhat com>]

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 () redhat com> wrote:

> On Fri, Mar 2, 2018 at 4:44 AM, Hanno Böck <hanno () hboeck 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 () hboeck 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 () redhat 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 () redhat com