[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