[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] [iputils] Integer overflow in iputils ping/ping6 tools



On Tue, Mar 13, 2012 at 6:17 PM, Marcus Meissner <meissner@xxxxxxx> wrote:
> Hi,
>
> How is this different from writing a fork bomb?
:)

Fork bombs can be remediated with RLIMIT_NPROC. The runaway ping
program needs to be fixed and then recompiled.

I suppose you could say the same about runaway fork'd programs,
though. I had one accidentally get away from me in college. The
professor who performed the post-mortem was very impressive. He had me
fingered in under an hour.

Jeff

>
> On Tue, Mar 13, 2012 at 09:42:29AM +0100, Christophe Alladoum wrote:
>> ====[ Description ]====
>>
>> An integer overflow was found in iputils/ping_common.c main_loop() function
>> which could lead to excessive CPU usage when triggered (could lead to DoS). 
>> This
>> means that both ping and ping6 are vulnerable.
>>
>>
>> ====[ Proof-Of-Concept ]====
>>
>> Specify "big" interval (-i option) for ping/ping6 tool:
>> {{{
>> $ ping -i 3600 google.com
>> PING google.com (173.194.66.102) 56(84) bytes of data.
>> 64 bytes from we-in-f102.1e100.net (173.194.66.102): icmp_req=1 ttl=50 
>> time=11.4 ms
>> [...]
>> }}}
>>
>> And check your CPU usage (top, htop, etc.)
>>
>>
>> ====[ Explanation ]====
>>
>> Here, ping will loop in main_loop() loop in this section of code :
>> {{{
>> /* from iputils-s20101006 source */
>> /* ping_common.c */
>>
>>     546 void main_loop(int icmp_sock, __u8 *packet, int packlen)
>>     547 {
>> [...]
>>     559         for (;;) {
>> [...]
>>     572                 do {
>>     573                         next = pinger();
>>     574                         next = schedule_exit(next);
>>     575                 } while (next <= 0);
>> [...]
>>     588                 if ((options & (F_ADAPTIVE|F_FLOOD_POLL)) || 
>> next<SCHINT(interval)) {
>> [...]
>>     593                         if (1000*next <= 1000000/(int)HZ) {
>> }}}
>>
>> If interval parameter (-i) is set, then condition L593 will overflow (ie. 
>> value
>> exceeding sizeof(signed integer)), making this statement "always true" for 
>> big
>> values (e.g. -i 3600). As a consequence, ping process will start looping
>> actively as long as condition is true (could be pretty long).
>>
>> As far as looked, this bug is unlikely to be exploitable besides provoking
>> Denial-Of-Service.
>>
>>
>> ====[ Affected versions ]====
>>
>> Tested on Fedora/Debian/Gentoo Linux system (2.6.x x86_32 and x86_64) on 
>> iputils
>> version 20101006. ping6 seems also to be affected since it's relying on same
>> ping_common.c functions.
>>
>> Since iputils is not maintained any longer
>> (http://www.spinics.net/lists/netdev/msg191346.html), patch must be applied 
>> from
>> source.
>>
>>
>> ====[ Patch ]====
>> Quick'n dirty patch (full patch in appendix) is to cast test result as long 
>> long:
>> {{{
>>     593                  if (((long long)1000*next) <= (long 
>> long)1000000/(int)HZ) {
>> }}}
>>
>>
>> ====[ Credits ]====
>> * Christophe Alladoum (HSC)
>> * Romain Coltel (HSC)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/