Harden dropbear memory allocator

Loganaden Velvindron loganaden at gmail.com
Sun Apr 12 20:52:44 AWST 2015


On Sun, Apr 12, 2015 at 12:34 PM, Matt Johnston <matt at ucc.asn.au> wrote:
> Hi Logan,
>
> Thanks for looking at that - certainly something to be wary
> of. I've actually removed netio.c's malloc altogether a
> couple of weeks ago though had neglected to push it until
> now https://secure.ucc.asn.au/hg/dropbear/rev/cc6116cc0b5c
> (my github mirror isn't updated, the machine that does that is
> offline, should be back next week).

You're welcome !


>
> I think netio.c was OK because *ret_iov_count was limited to
> IOV_MAX which is 1024 or less on most platforms.

I was thinking about importing the m_reallocarray() wrapper into
dropbear. I think that it would be a useful API to have inside
dropbear for future use as well.

It has the advantage of a low overhead compared to calloc() as it
doesn't zero, and you have the integer overflow protection for  free.

For example, in scpmisc.c,

There's also:

        args->list = xrealloc(args->list, nalloc * sizeof(char *));

In OpenBSD, we have replaced those calls in OpenBSD by reallocarray(),
and there are around 800 instances: it ships in libressl, openssh,
opensmtpd, and many other userland software, such as nsd and unbound,
which have also imported a similar API into their memory wrappers.

//Logan
C-x-C-c


More information about the Dropbear mailing list