Directory traversal vulnerability in svcstatus.c (historylog)
Peoples I've discovered a directory traversal vulnerability in the svcstatus.c file, allowing a remote attacker to view any file on the filesystem that's visible to the web server user. When viewing a specific historical entry, and then setting the parameter for TIMEBUF to "../../../..(etc)/path/to/file" you get to view the file. For example: http://somesite.com/xymon-cgi/historylog.sh?HOST=somehost&SERVICE=conn&TIMEB... Here's a patch to prevent it: ---- web/svcstatus.c.orig 2011-05-06 12:12:45.000000000 +1000 +++ web/svcstatus.c 2011-05-06 13:20:47.000000000 +1000 @@ -83,6 +83,12 @@ else if (strcasecmp(cwalk->name, "TIMEBUF") == 0) { /* Only for the historical logs */ tstamp = strdup(cwalk->value); + char *p = basename(tstamp); + /* Sanity check timestamp to avoid dir traversal attacks */ + if (strcmp(p,tstamp) != 0) { + errormsg("Invalid time specification\n"); + return 1; + }; } else if (strcasecmp(cwalk->name, "CLIENT") == 0) { char *p; I'm not a C coder, so there's an excellent chance someone else can come up with a better patch. It would be nice to log an error into the web server log, but it doesn't work for me, and I'm guessing the xymon CGI process closes stderr when it starts up or something like that. Cheers Jeremy
Hi Jeremy
On 06-05-2011 05:21, Jeremy Laidman wrote:
Peoples
I've discovered a directory traversal vulnerability in the svcstatus.c file, allowing a remote attacker to view any file on the filesystem that's visible to the web server user. When viewing a specific historical entry, and then setting the parameter for TIMEBUF to "../../../..(etc)/path/to/file" you get to view the file.
Definitely not a good feature to have.
Fixed in version 4.3.3 which should be available from Sourceforge now. There were a couple of other places which could potentially have the same type of issue - I've fixed those as well.
4.3.3 also fixes a couple more cross-site scripting vulnerabilities, and has the "normal" bugfixes that have accumulated.
Regards, Henrik
participants (2)
-
henrik@hswn.dk
-
jlaidman@rebel-it.com.au