[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM2Hf5nRKv93VLTagiz2Uz=-ympJ5Qj2sFz3NjU2Nu00rMVsmw@mail.gmail.com>
Date: Tue, 13 Mar 2012 16:06:37 -0800
From: Gage Bystrom <themadichib0d@...il.com>
To: noloader@...il.com,
"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: [iputils] Integer overflow in iputils
ping/ping6 tools
Shoulda gotten a lawyer o.O professor sex scandals can rake in decent money
On Mar 13, 2012 4:32 PM, "Jeffrey Walton" <noloader@...il.com> wrote:
> On Tue, Mar 13, 2012 at 6:17 PM, Marcus Meissner <meissner@...e.de> 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/
Content of type "text/html" skipped
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists