[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