Forum OpenACS Q&A: Bugtraq - AOLserver nspd/log.c buffer overflow vulnerability

Matt Underwood of TechSquare, Inc. pointed this out to me:

An AOLserver buffer overflow vulnerability in nspd/log.c was reported to Bugtraq on April 16 - you can read the full text here and see more tracking info. Looks like the AOL folks (Kriston) patched this on the nsd_v3_r3_p0 branch - here's the diff and the nspd/log.c CVS log comment.

It's obviously a very simple patch. My question is, do we have to worry abou this? I'm not really clear on just when the nspd stuff gets used at all...

nspd implements "the proxy-side library for external drivers" (nspd/main.c).  So, if you're using AOLserver in conjunction with Oracle and/or PostgreSQL, you don't have to worry at all as those are internal (more tightly coupled) drivers that don't go through nspd.

If you are using the nspd driver for your database, then you don't have to worry much.  The problem was that Ns_PdLog allocated a 4096 buffer on the stack and then called vsprintf to print into it.  Vsprintf places on the developer the requirement that the buffer be big enough on pain of buffer overflow.

In reality, my inspection of the calls to Ns_PdLog in nspd/main.c, nspd/listen.c, and nspd/log.c shows maybe one or two places that I can't instantly tell that a 4K buffer isn't way too large.

That said, it's a good bug to fix, and my real concern is if Ns_PdLog does things this way, is it possible that Ns_Log is doing things this way?  And the answer to that is no, nsd/log.c/Log calls vfprintf to write to the log file directly without first using a stack based buffer.