Possible DoS in whois (1.31), caused by memory exhaustion

[Erez Turjeman]

I don't think that the RFC itself defines the any constraints on response
length or maximum count of iterations between client and server. However,
the implementation provided in Debian (
https://git.launchpad.net/ubuntu/+source/whois/tree/whois.c#n780), assumes
the each response from server should be treated as a complete entry (i.e.
not fragmented) and thus avoids using realloc.
Regards,
Erez

On Mon, Dec 2, 2019 at 2:59 PM Tito <farmatito at tiscali.it> wrote:

> On 12/2/19 4:54 PM, Erez Turjeman wrote:
> > The implementation of `whois` in busybox 1.31 calls xrealloc without
> limiting the size argument, which can lead to a memory exhaustion,
> https://git.busybox.net/busybox/tree/networking/whois.c?h=1_31_stable#n63.
> A rogue server can simply reply with an endless response until crashing the
> client.
> > Regards,
> > Erez
> > --
> > Erez Turjeman
> > erezto at gmail.com <mailto:erezto at gmail.com>
> >
>
> Hi,
> shouldn't the app simply exit if memory is exhausted and thus free the
> memory again?
>
> Is there any maximum size for the server reply or do you think an arbitrary
> maximum value should be hardcoded?
>
> // Die if we can't resize previously allocated memory.  (This returns a
> pointer
> // to the new memory, which may or may not be the same as the old memory.
> // It'll copy the contents to a new chunk and free the old one if
> necessary.)
> void* FAST_FUNC xrealloc(void *ptr, size_t size)
> {
>         ptr = realloc(ptr, size);
>         if (ptr == NULL && size != 0)
>                 bb_die_memory_exhausted();
>         return ptr;
> }
>
> Ciao,
> Tito
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20191202/d7ed9417/attachment.html>