[ntp:security] memory leak

geir.guldstein at no.abb.com geir.guldstein at no.abb.com
Thu Jan 31 09:44:24 UTC 2008

Hi Danny,

Thank you for working on our problem.

We are happy to test your fix. You can send the changed code me.
Alternatively, please indicate when the fix will be available as a
"development" download at www.ntp.org.

Best regards

             Danny Mayer                                                   
             <mayer at ntp.isc.or                                             
             g>                                                         To 
                                       Geir Guldstein/NOINA/ABB at ABB        
             20.01.2008 19:23                                           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      

I am testing a fix for this. While it will increase memory requirements
slightly, it will be almost unnoticeable. I'm basically saving the
messages and their codes so once it's been looked up it's there in
memory and it won't allocate more memory.

I will probably make it available on Tuesday. If you want the source
please let me know as there are a number of delays in getting the code
into the repository right now.


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

More information about the security mailing list