[ntp:security] memory leak
geir.guldstein at no.abb.com
geir.guldstein at no.abb.com
Sun Jan 13 19:47:06 UTC 2008
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, *
<mayer at ntp.isc.or
Geir Guldstein/NOINA/ABB at ABB
13.01.2008 17:52 cc
<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
> 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
> 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
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