|Summary:||sys-libs/glibc: glob ressouce exhaustion possibly affecting FTP servers (CVE-2010-2632)|
|Product:||Gentoo Security||Reporter:||Hanno Böck <hanno>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Severity:||normal||CC:||aholler, jackdachef, kfm, ole+gentoo|
|Package list:||Runtime testing required:||---|
Description Hanno Böck 2010-10-07 11:43:35 UTC
See: http://securityreason.com/securityalert/7822 I'm not sure if this is mainly an issue of glibc or the affected ftp-servers and I'm unsure about the possible impact, see also in german: http://www.heise.de/security/meldung/Fehler-in-libc-Implementierung-gefaehrdet-FTP-Server-1103258.html same article translated: http://www.h-online.com/open/news/item/Flaw-in-libc-implementation-threatens-FTP-servers-1103319.html
Comment 1 Alexander Holler 2010-10-08 18:18:52 UTC
This is mainly a problem of the (g)libc. The problem is that ftp-server (as anything else) can't limit how much memory is used by the affected functions. So be sure you have set limits (see ulimit -a) set for ftp-servers, so that only the ftp-server dies, otherwise you might get an oom.
Comment 2 Alex Legler (RETIRED) 2010-10-11 17:08:38 UTC
*** Bug 340555 has been marked as a duplicate of this bug. ***
Comment 3 SpanKY 2010-10-13 23:51:16 UTC
http://lists.gnu.org/archive/html/bug-gnulib/2010-10/msg00328.html the original advisory talks about bugs in GLOB_LIMIT handling which is a BSD-specific option. the gnulib maintainers also agree with the sentiment that you should use the existing resource controls to "fix" this. i.e. you should be ulimiting all server processes anyways. nothing to change in glibc/gnulib -> CLOSED:WORKSFORME
Comment 4 Stefan Behte (RETIRED) 2010-10-14 00:16:40 UTC
Please never ever close security bugs by yourself; IMHO this still needs attention and the security team will decide what to do with this. My opinion on the issue: if I can remotely crash an ftp from our stable tree with a default configuration we provide, it's a valid security bug and we need to do something about it. Even if it's not regarded as a valid security problem, we might want to keep it open to track fixing of GLOB_LIMIT.
Comment 5 Alexander Holler 2010-10-14 10:55:13 UTC
It is definitively a design problem of the API in glibc. If you don't know and can't control how much time and memory a function will need, the function renders usesless. Having read the sentence "There are many functions in libc that can allocate an arbitrary amount of memory." on the ml of glibc, I wonder what other functions are having such problematic use cases through which they might allocate gigabytes of memory (through a valid call). In my humble opinion, all those functions should get marked with a '#pragma warning' or something similiar to warn developers. Argumenting that a developer should use a subprocess, setting limits for them and then handle a possible kill of the subprocess, as done on the ml for glibc, is like saying, go away and don't use that function.
Comment 6 Alexander Holler 2010-10-14 11:33:10 UTC
Just to clarify my critics on that API. I don't talk about stuff like malloc or qsort where one could at least estimate how much memory or time is needed when the function is called with a specific set of arguments. The special problem with glob is, that it is almost impossible (for a human or a machine) to see or estimate how many time and resources will be used when evaluating a given pattern. So I see that GLOB_LIMIT as a reasonable approach to solve that problem.
Comment 7 SpanKY 2010-10-26 06:49:51 UTC
there is no such thing as "GLOB_LIMIT" which means there is nothing to be fixed. if you have an ftp system which is overloaded and takes down a system, your system is misconfigured. you need to be setting correct usage limits on your exposed daemons. as for adding such features/changes to sys-libs/glibc, it isnt going to happen. if you want to make glibc more "security conscience", then do so on your own time with the upstream developers on their development mailing lists.
Comment 8 Alexander Holler 2010-10-26 11:36:32 UTC
As I said, "go away and don't use that function". At least not in something which could be used by someone you don't want to give the right to kill the process which uses that function and can feed input to glob(). And by the way, don't forget to limit resources of users too. FTP-servers aren't the only applications which are using glob(). And don't forget to restart services if they are getting killed. If I was the objective of the last comment: I never talked about that this is needed to get fixed. The solution is simple to not use that function. I've just posted some thoughts to warn others and offer some light about the problems which may arise when glob() is/was used.
Comment 9 SpanKY 2012-04-13 23:32:48 UTC
1.5 years on and still no plans to do anything about this. let's close it out and be done already ...