[VIM] old Squid clientAbortBody issue - NOT an overflow?

[Steven M. Christey]

There's an old Squid clientAbortBody issue that was claimed to be a
buffer overflow, but the original report seems to be erroneous.

Refs:

  MISC:http://www.securitylab.ru/47881.html
  OSVDB:9801
  SECTRACK:1011214

These sources claim a buffer overflow in clientAbortBody() in
client_side.c in Squid before 2.6 STABLE6 (actually, some say STABLE5,
which is understandable because the original researcher claims both.)

The key here is the following Squid bug report:

  MISC:http://www.squid-cache.org/bugs/show_bug.cgi?id=972

Here is my reconstruction of what happened:

(1) Original bug report to vendor shows null dereference in
clientAbortBody; original claim is null deref, and patch shows null
deref.

(2) Separate researcher claims overflow in clientAbortBody() for
STABLE6 (SECTRACK:1011214), saying "I am still experiencing this
problem in STABLE6."

(3) Various vuln DBs reported this issue as an overflow (including
OSVDB:9801).

(4) Later in the bug report, the vendor asks the researcher for more
information about the STABLE6 problem.

(5) The researcher then retracts the original claim, saying "the
release I thought was STABLE6 was a mis-labled version of Stable5..."


I'll be creating a CVE for the issue, calling it a null dereference in
STABLE5.  Not sure where the "overflow" claim even came from, but
there might be some long fields in the stack trace in message 2 of the
bug report (or maybe it's just zeroed memory).

FYI, SECUNIA:12508 is based on the original clientAbortBody null
dereference report.

- Steve

P.S.  Why yes, figuring this out DID kinda suck.