AppWeb Forum
http://appwebserver.org/forum/

Configuring logging
http://appwebserver.org/forum/viewtopic.php?f=1&t=969		 Page 1 of 1
Author:  rachmel [ Sun Apr 29, 2007 8:40 am ]
Post subject:  Configuring logging
Hi,

I have discovered a vulnerability, allowing a user to cause the appWeb server to crash using a specially crafted GET message, on appWeb 2.0.5.4.

Is it a known issue that was fixed later, or is this a new problem?
(I have done some googling and came up with nothing).

I am currently debugging the issue, and I might require some help in understand the code-flow - but would rather not discuss it here in the open forum...

Thanks,

Nir.
Author:  rachmel [ Mon Apr 30, 2007 10:48 am ]
Post subject:  Some more information
Hi All,

I have located a possible issue - would like you comments (I am referring to appWeb 2.0.5-4):

In:

MprLogToFile::logEvent() , in case there is no actual file descriptor defined (the logging is enabled by compilation, but disabled via conf file), Some errors are logged to the STDERR. for some reason, the following call is made:

======= start code ============

if (logFd < 0 && level <= 1) {
//
// Always output fatal and error messages
//
mprFprintf(MPR_STDERR, buf);
return;
}

// OPT -- could get length above
write(logFd, buf, strlen(buf));

========= end code ==========

the call to mprFprintf, when there is only a buffer, and no other paramaters cause un-expected results, when the 'buf' itself holds some of the special characters, such as : %s, %d ... etc.

for example: if a user initiates a GET request, with a special character, such as:
"GET %n://localhost:80/index.html HTTP/1.1..Host: 172.19.15.11..User-Agent: Security test..Content-Length: 0..Cache-Control: no-cache....\r\n\r\n"
"GET %s%s://localhost:80/index.html HTTP/1.1..Host: 172.19.15.11..User-Agent: Security test..Content-Length: 0..Cache-Control: no-cache....\r\n\r\n"
"GET %d://localhost:80/index.html HTTP/1.1..Host: 172.19.15.11..User-Agent: Security test..Content-Length: 0..Cache-Control: no-cache....\r\n\r\n"

The server cannot find such a page, and tries to write an error message to the stderr. When passing the above string to the mprFprintf as 'buf', the mprFprintf (or more accurately mprSprintfCore) tries to match the %s (or %d or %s) to an argument from the list. However... there is no argument in the list at all - thus resulting in garbage printed in the good case... and segmentation fault in the bad case.

I would like to suggest, changing the call to mprFprintf to be as when writing to a real logfile (and not just STD_ERR), and call write().
I have tested it, it works fine, doesn't harm any of the log options, and secures the web-server from the possible garbage printing or crash.

I would appreciate your comments - as this is a security threat for anyone running the appWeb server.

Thanks,

Nir Rachmel.
Author:  ph [ Thu May 03, 2007 5:01 am ]
Post subject: 
So you mean that the developer must build with logging enabled, but then disable it in the conf file. Then you can get this buffer overflow?

Peter
Author:  cjr [ Thu May 03, 2007 5:03 am ]
Post subject: 
Seems pretty rare - but a good fix anyway.

Thanks

cjr
Author:  rachmel [ Thu May 03, 2007 7:16 am ]
Post subject:  reply
Hi,

Exactly - you need to build with logging enabled, but disable it in the conf file.

Thanks,

Nir.
Author:  rola [ Thu Jan 03, 2008 6:56 am ]
Post subject:  Re: Security vulnerability - DOS
Good answer, I'm looking for the solution of the same question.Thanks so much.
Author:  MarCn [ Tue Apr 20, 2010 9:46 am ]
Post subject:  Re: Some more information
rachmel wrote:
Hi All,

I have located a possible issue - would like you comments (I am referring to appWeb 2.0.5-4):

In:

MprLogToFile::logEvent() , in case there is no actual file descriptor defined (the logging is enabled by compilation, but disabled via conf file), Some errors are logged to the STDERR. for some reason, the following call is made:

======= start code ============

if (logFd < 0 && level <= 1) {
//
// Always output fatal and error messages
//
mprFprintf(MPR_STDERR, buf);
return;
}

// OPT -- could get length above
write(logFd, buf, strlen(buf));

========= end code ==========

the call to mprFprintf, when there is only a buffer, and no other paramaters cause un-expected results, when the 'buf' itself holds some of the special characters, such as : %s, %d ... etc.

for example: if a user initiates a GET request, with a special character, such as:
"GET %n://localhost:80/index.html HTTP/1.1..Host: 172.19.15.11..User-Agent: Security test..Content-Length: 0..Cache-Control: no-cache....\r\n\r\n"
"GET %s%s://localhost:80/index.html HTTP/1.1..Host: 172.19.15.11..User-Agent: Security test..Content-Length: 0..Cache-Control: no-cache....\r\n\r\n"
"GET %d://localhost:80/index.html HTTP/1.1..Host: 172.19.15.11..User-Agent: Security test..Content-Length: 0..Cache-Control: no-cache....\r\n\r\n"

The server cannot find such a page, and tries to write an error message to the stderr. When cheap phentermine passing the above string to the mprFprintf as 'buf', the mprFprintf (or more accurately mprSprintfCore) tries to match the tadalafil %s (or %d or %s) to an argument from the list. However... there is no argument in the list at all - thus resulting in garbage printed in the good case... and segmentation fault in the bad case.

I would like to suggest, changing the call to mprFprintf to be as when writing to a real logfile (and not just STD_ERR), and call write().
I have tested it, it works fine, doesn't harm any of the log options, and secures the web-server from the possible garbage printing or crash.

I would appreciate your comments - as this is a security threat for anyone running the appWeb server.

Thanks,

Nir Rachmel.


Hi rachmel,
Thanks for the fix. I tried it, and indeed appWeb doesn't crash anymore.
Page 1 of 1 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/