[ntp:security] memory leak

geir.guldstein at no.abb.com geir.guldstein at no.abb.com
Sun Jan 13 19:47:06 UTC 2008

Hi Danny,

Thank you for responding.

Regarding ISIC: I quote the following text from our original mail. In can
add that I succesfully reproduced the problem by compiling and running ISIC
on Ubuntu within VMware on my Vista laptop.

> The flooding test tool used is the "IP Stack Integrity Checker" (ISIC)
> suite at full speed. The purpose of these tests is to understand the
> impact on the NTP stack to flooding. The ISIC suite is an open source
> tool, which runs on Linux and is available from
> http://isic.sourceforge.net. The ISIC version in use is v0.07. The
> following ISIC syntax can be used to reproduce the above scenario:
> *udpsic -i ethX -r 1 -s rand -d <ip_addr>,123 -F0 -V0 -I0 -p10000000, *


             Danny Mayer                                                   
             <mayer at ntp.isc.or                                             
             g>                                                         To 
                                       Geir Guldstein/NOINA/ABB at ABB        
             13.01.2008 17:52                                           cc 
                                       Heiko Gerstung                      
                                       <heiko.gerstung at meinberg.de>, Kai   
             Please respond to         Hansen/NOCRC/ABB at ABB, Frank Kardel  
             mayer at ntp.isc.org         <kardel at ntp.org>, Kevin             
                                       McGrath/NOABB/ABB at ABB, Martin       
                                       <martin.burnicki at meinberg.de>,      
                                       security at ntp.org                    
                                       Re: [ntp:security] memory leak      

geir.guldstein at no.abb.com wrote:
> Hi and happy new year to all.
> I have now investigated this problem using Rational Purify. I have not
> this tool previously, but found it to be very useful in this case (thanks
> Heiko).
> There is a memory leak bug in ntpd that is triggered when it receives
> random garbage data, e.g. those produced by ISIC.
> Bug explanation, the source code version used is 4.2.4p4:
> When "attacked" by ISIC as described in our previous mail ntpd frequently
> executes the FormatMessage call at line 73 in i ntp-4.2.4
> p4\ports\winnt\libisc\isc_strerror.c. The supplied error number is 234
> ("More data is available"). Call stack:
>>     ntpd.exe!FormatError(int error=234)  Line 85    C
>       ntpd.exe!isc__NTstrerror(int err=234, int * bfreebuf=0x00cef724)
> Line 114 + 0x9 bytes    C
>       ntpd.exe!NTstrerror(int errnum=234)  Line 40 + 0xd bytes    C
>       ntpd.exe!format_errmsg(char * nfmt=0x00cef92c, int lennfmt=256,
> char * fmt=0x0053601c, int errval=234)  Line 103 + 0x9 bytes      C
>       ntpd.exe!msyslog(int level=3, const char * fmt=0x0053601c, ...)
> 162 + 0x1c bytes  C
>       ntpd.exe!iocompletionthread(void * NotUsed=0x00000000)  Line 192 +
> 0x10 bytes  C
>       ntpd.exe!_callthreadstart()  Line 293 + 0xf bytes     C
>       ntpd.exe!_threadstart(void * ptd=0x00ad3578)  Line 277      C
>       kernel32.dll!7c80b683()
> The leak happens because ntpd supplies the FORMAT_MESSAGE_ALLOCATE_BUFFER
> flag to the FormatMessage OS API. The application is then responsible for
> deallocating (LocalFree) the returned buffer when it is no longer needed
> (http://msdn2.microsoft.com/en-us/library/ms679351.aspx). ntpd fails to
> this, there is a "freebuf" flag that is signaled back to the calling
> routines but the flag is thrown away unused in the NTstrerror function
> (line 38 in ntp-4.2.4p4\ports\winnt\libisc\isc_strerror.c).
> Best regards
> Geir

Ah. I remember this now. This is a bug left over from the BIND 9
implementation and was left for later resolution as there is no easy
answer to this. I never got around to dealing with this. It's a BIND9
Windows bug originally and I will need to feed it back in there as well.

I'm not familiar with ISIC. Can you provide a reference?

I'm not really worried about this leak as attacks like this are rare. I
will try and figure out what we can do.


More information about the security mailing list