[ntp:security] memory leak

Danny Mayer mayer at ntp.isc.org
Sun Jan 20 18:22:37 UTC 2008

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 used
> 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, const
> char * fmt=0x0053601c, int errval=234)  Line 103 + 0x9 bytes      C
>       ntpd.exe!msyslog(int level=3, const char * fmt=0x0053601c, ...)  Line
> 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 do
> 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