[ntp:security] [vendor-sec] Limited buffer overflow in ntpq

Danny Mayer mayer at ntp.org
Tue Mar 17 01:57:16 UTC 2009


Tomas Hoger wrote:
> Hi Geoff!
> 
> On Wed, 11 Mar 2009 16:55:13 -0700 Geoff Keating <geoffk at apple.com>
> wrote:
> 
>> CVE-ID: CVE-2009-0159
>> Impact: Requesting peer information from a malicious remote time  
>> server may lead to an unexpected application termination or
>> arbitrary code execution
> 
> Talking to malicious server via ntpq, or to trusted server over
> untrusted network, is the only way to trigger this, right?  There's no
> way to trigger this if talking to trusted ntp server which has some
> malicious peer, correct?

That is correct in as far as you are only likely to query a server you
know about *and* that server responds to mode 6 NTP packets. The user
has to initiate the query.

> 
>> Description: A stack buffer overflow exists in the ntpq program.
>> When the ntpq program is used to request peer information from a
>> remote time server, a maliciously crafted response may lead to an
>> unexpected application termination or arbitrary code execution.
> 
> Is this theoretical, or do you have any test case that can be used to
> crash ntpq?  Mine does not seem to do anything bad to ntpq, even with
> the maximum overflow possible.  Well, except of fortify_source builds,
> where ntpq aborts.
> 
>> This issue is often not exploitable, especially in 32-bit processes  
>> where the overrun can be at most 2 bytes.  Common hardening measures  
>> will also prevent exploitation.
> 
> Looking at the code, the overflow is limited to 2 bytes even on 64bit
> systems.  In ntp-4.2.4p6, uval is read from server's reply using
> decodeuint(), which calls one of hextoint(), octtoint() or atouint().
> All 3 use hard-coded numeric constants to protect against integer
> overflows, and those constants are derived from UINT_MAX / 32-bit
> ULONG_MAX, rather than really taking word size into consideration.
> 
> So as far as I can tell, this is limited to 2-byte overflow, even on
> 64bit systems.  The overflow may well be contained by some other local
> variable, and may to be able to reach control structures at all.  Have
> you checked that?

I agree with your analysis.

Danny
> 
> Anyway, is this issue public or embargoed?  If embargoed, what is the
> embargo date?
> 
> Thank you!
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the security mailing list