[ntp:security] memory leak

Danny Mayer mayer at ntp.isc.org
Sun Jan 13 16:50:15 UTC 2008

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

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