netdev - Possible integer overflow in ping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Mar 2012 17:33:00 +0100
From:	Christophe Alladoum <Christophe.Alladoum@....fr>
To:	netdev@...r.kernel.org
Cc:	Romain Coltel <Romain.Coltel@....fr>
Subject: Possible integer overflow in ping_common.c 

Hi list,

A collegue and I found a possible integer overflow in ping_common.c that could
lead to excessive CPU usage when triggered.

PoC :
{{{
$ 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
[...]
(check your CPU usage)
}}}

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

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
ping_common.c functions.

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) {
}}}

Can you confirm this bug?

Thanks
-- 
Christophe Alladoum - <christophe.alladoum@....fr>
Hervé Schauer Consultants - <http://www.hsc.fr>

View attachment "ping_interger_overflow.patch" of type "text/plain" (527 bytes)