Mike Frysinger wrote:
> i havent seen any mention on glibc or gnulib lists of CVE-2010-2632. the
> report claims glibc is affected, and since the gnulib/glibc implementations
> are pretty similar, gnulib would be as well. i dont suppose there is a bug
> report somewhere i could follow for status on this ?
>
> http://securityreason.com/exploitalert/9223
It is indeed surprising that you can can bring down many systems simply through
$ echo */{..,..}/*/{..,..}/*/{..,..}/*/{..,..}/*
CAUTION: Don't try this on a machine on which you are doing real work!
But why should this be a bug in libc? There are many functions in libc that
can allocate an arbitrary amount of memory. If allocating a lot of memory is
considered a DoS attack, the server administrator can defend itself against
it by limiting the memory size of the process:
"ulimit -m 50000; ulimit -v 50000"
If you think this is not a viable approach because the glob() call occurs
in the ftp server process itself, which is at the same time also serving
many clients, then revisit the design of your ftp server. Put the execution
of dangerous tasks into subprocesses.
In summary, you can't blame libc for security-unaware design of application
programs.
Just my 0.02 €. Feel free to open a bug in glibc bugzilla if you want to hear
Ulrich Drepper's opinion.
Regarding gnulib: gnulib takes glob(), fnmatch(), regex from glibc. Bug fixes
done in glibc will be copied to gnulib sometime later.
Bruno
