[ntp:security] monlist reflective DDoS

Christian Rossow christian.rossow at gmail.com
Tue Aug 27 16:21:58 UTC 2013


Hi all,

I'm still in contact with MITRE regarding the CVE for the `monlist`
amplification attack. They asked me to provide public resources for such
kind of attack (as my research paper is still not public). We agreed
that I write a (non-public) article on my web site with details of the
`monlist` so that they can include a reference to the CVE.

After that, and with your OK, I'd like to communicate the issue to the
CERT community and give suggestions regarding remedy. Harlan, you
mentioned that 4.2.7p26 solved the issue. Can we thus safely recommend
to upgrade to this version?

Also, in my email from August 12th (see below) I outlined a few other
message types that allow for amplification. Did you have the chance to
look at them and did you decide what to do about these issues? If it's
still unclear what to do about these cases, I'd still prefer to alert
the CERTs and add a paragraph that -- next to `monlist` -- there are
other amplification vectors that we currently look at.

Cheers,
Christian



-------- Original Message  --------
Subject: Re: [ntp:security] monlist reflective DDoS
From: Christian Rossow <christian.rossow at gmail.com>
To: Harlan Stenn <stenn at ntp.org>
Cc: mayer at ntp.org, security at ntp.org
Date: 12.08.2013 14:22

>>>  * The amplification vulnerability does not only affect `monlist`, but
>>> also other message types. How to proceed? Separate CVEs for those?
>> Not sure yet.  Do you have a list of these other message types?
> Here are my test results for the other message types:
> 
> REQ_PEER_LIST       type  0: rcvd 168 bytes (1 packets, factor 21)
> REQ_PEER_LIST_SUM   type  1: rcvd 368 bytes (1 packets, factor 46)
> REQ_SYS_INFO        type  4: rcvd  88 bytes (1 packets, factor 11)
> REQ_SYS_STATS       type  5: rcvd  52 bytes (1 packets, factor 6.5)
> REQ_IO_STATS        type  6: rcvd  48 bytes (1 packets, factor 6)
> REQ_MEM_STATS       type  7: rcvd 156 bytes (1 packets, factor 19.5)
> REQ_LOOP_INFO       type  8: rcvd  32 bytes (1 packets, factor 4)
> REQ_TIMER_STATS     type  9: rcvd  24 bytes (1 packets, factor 3)
> REQ_GET_RESTRICT    type 16: rcvd 456 bytes (1 packets, factor 57)
> REQ_MON_GETLIST     type 20: rcvd 29280 bytes (60 packets, 3660)
> REQ_RESET_STATS     type 21: rcvd  16 bytes (2 packets, factor 2)
> REQ_REREAD_KEYS     type 23: rcvd  16 bytes (2 packets, factor 2)
> REQ_AUTHINFO        type 28: rcvd  44 bytes (1 packets, factor 5.5)
> REQ_GET_CTLSTATS    type 34: rcvd  68 bytes (1 packets, factor 8.5)
> REQ_GET_KERNEL      type 38: rcvd  68 bytes (1 packets, factor 8.5)
> REQ_MON_GETLIST_1   type 42: rcvd 44000 bytes (100 packets, factor 5500)
> 
> REQ_MON_GETLIST_1 and REQ_MON_GETLIST are most effective, but also four
> other message types (REQ_PEER_LIST, REQ_PEER_LIST_SUM, REQ_SYS_INFO,
> REQ_MEM_STATS, REQ_GET_RESTRICT) amplify traffic by factor 10+.
> 
> I left out all commands that need additional arguments/parameters, such
> as showpeer/pstats (didn't know how to form requests for them). Maybe
> you can do some quick tests for these?
> 
> Christian
> 



More information about the security mailing list