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

Geoff Keating geoffk at apple.com
Tue Mar 17 00:18:54 UTC 2009


On Mar 16, 2009, at 9:05 AM, 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?

As far as I can tell, the only use of this code is to print the  
reachability bits, which should be limited by the ntp server to a  
maximum of 0377.

>> 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.

Theoretical.

>> 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.

Yes, I agree with your logic.

> 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?

In at least one case, I've seen that the issue was not exploitable  
because the space overwritten was not used; but this is architecture-  
and compiler-dependent.  A compiler is certainly permitted to generate  
an exploitable stack layout.

> Anyway, is this issue public or embargoed?  If embargoed, what is the
> embargo date?

It's not public, as far as I know.  How about an embargo until April  
7, 2009?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2462 bytes
Desc: not available
Url : https://lists.ntp.org/mailman/private/security/attachments/20090316/8da62bdc/attachment.bin 


More information about the security mailing list