[VIM] lpr overflow - multiple cve/osvdb?
Steven M. Christey
coley at linus.mitre.org
Wed Jun 8 00:53:47 EDT 2005
On Sun, 5 Jun 2005, security curmudgeon wrote:
> Buffer overflow in BSD and linux lpr command allows local users to execute
> commands as root through the classification option.
> Buffer overflow in BSD-based lpr package allows local users to gain root
The problem here is twofold:
- I can't see information from any of the authoritative references in
CVE-1999-0032 that indicates that it's specifically the -C classification
option that's affected
- the lpr-bsd-lprbo reference for CVE-1999-0335 no longer exists
Let's look at the timelines here...
1996-10-25 Bugtraq: Linux & BSD's lpr exploit
1999-11-26 AusCERT: AA-96.12
Part of the AusCERT advisory says:
Due to insufficient bounds checking on arguments which are supplied
by users, it is possible to overwrite the internal stack space of the
lpr program while it is executing. This can allow an intruder to
cause lpr to execute arbitrary commands by supplying a carefully
designed argument to lpr.
AUSCERT:AA-96.12 includes a wrapper program to use as a workaround - this
wrapper exits if *any* command line argument is too long. Obviously this
would be relevant with respect to a long -C option, but the (mostly
academic I suspect) question is whether there were other overflows in lpr
at around the same time.
AUSCERT:AA-96.12 includes several references to advisories, which don't
reference the original Bugtraq post or give specific details. There's
hope for a FreeBSD advisory FreeBSD-SA-96:18.lpr.asc, since it mentions
some patches, but I can't find the patches.
But then the AusCERT advisory also mentions a Linux update,
"Update-11-25-1996.vulnerability-lpr-0.06-v1.2", which gets us to a
November 22, 1996 post archived here:
which says: "lpr utility from the lpr 0.06 suffers from the buffer overrun
problem" as well as "The exploits that exercise this vulnerability were
Curiously, Alexander O. Yuriev responds to a Bugtraq post on 1996-08-14,
titled "Re: Possible bufferoverflow condition in lpr, xterm and xload,"
but is talking about the xterm/xload overflow (in a -display argument,
probably a library problem):
but no mention of lpr.
However, this leads us to a Bugtraq post by bloodmask on
1996-08-13: Possible bufferoverflow condition in lpr, xterm and xload
and says: "suspicious behavior in lpr [hoho, this is a quite common suid
root binary, in many commercail and non-commercail versions of unix], lpr
exhibited the same behavior as mount, by segmenting when supplied with an
argument above 1024 bytes."
There's no specific mention of the -C argument, but at least we have some
mention of command line arguments in general.
Followups to this post immediately concentrate on the xterm/xload issues
and I can't find another mention of lpr at all.
So, probably what happened is this:
- 1996-08-13, bloodmask says there are command line overflows in lpr
- 1996-10-25, Vadim Kolontsov posts an exploit that uses the -C option
- 1996-10-25, we have a forwarded post from Bugtraq to freebsd-security:
- 1996-10-27, FreeBSD fixes an overflow in lpr - only one day after the
exploit is published, thus establishing an extremely close proximity to
the -C option exploit, especially given the freebsd-security list post.
(This fix date was obtained from FreeBSD-SA-96:18)
- 1999-11-26, AusCERT releases their advisory, mentioning
FreeBSD-SA-96:18 and others
If only there were some common identifier that everybody could have used
to avoid this whole confusing mess...
> bsd-lprbo (409)
> refs to: CVE-1999-0032 and CVE-1999-0335
The disclosure date hear appears to be wrong - the earliest mention seems
to be Bugtraq 1996-08-13.
> This is currently OSVDB 1105 and 11499 (one for each cve), both NEW
Since CVE-1999-0032 is far more authoritative than CVE-1999-0335,
reference-wise anyway, I will deprecate CVE-1999-0335 in the next CVE
version, and modify CVE-1999-0032 to have all the additional references
and specifically discuss the -C option.
*phew* that was a whole lotta work... probably a well-placed email to one
or two gurus from that time period would have been a lot faster!
More information about the VIM