Bugzilla Bug 211491

A classic:

in the function 'searchwn()', called from 'main()', there is a static 'char
tmpbuf[256]' into which an invalid command line option is copied using
sprintf():

            } else {
                sprintf(tmpbuf, "wn: invalid search option: %s\n", av[j]);
                display_message(tmpbuf);
                errcount++;
            }

So pass your favourite long string to wn with an invalid command line option,
yielding a segfault. All versions (2.0, 2.1 and 3.0) in Portage are affected.

I filed this under security since I have seen that Wordnet is sometimes used as
a backend in e.g. web applications. Please judge yourself and move to an
appropriate category if needed.

Patching should be trivial.

app-dicts please advise.

(In reply to comment #0)
> A classic:
> 
> in the function 'searchwn()', called from 'main()', there is a static 'char
> tmpbuf[256]' into which an invalid command line option is copied using
> sprintf():
[...]
> I filed this under security since I have seen that Wordnet is sometimes used as
> a backend in e.g. web applications. Please judge yourself and move to an
> appropriate category if needed.

Thanks for the report.

> Patching should be trivial. 

Unfortunately, I don't think so. I just took a quick look to the code, and
given the number of strcpy()/strcat()/... I'm pretty sure other are exploitable
as well. e.g this one:

lib/search.c:2126:    strcpy(wdbuf, synptr->words[wdnum]);

with wdbuf being a 256 chars static buffer... I'd say this stuff would need a
full security audit.

> (In reply to comment #0)
> Unfortunately, I don't think so. I just took a quick look to the code, and
> given the number of strcpy()/strcat()/... I'm pretty sure other are exploitable

With my ten seconds with the code, I did not even dare to look that far.
Indeed: e.g. from do_search() through findtheinfo() to wngrep() (in
../lib/search.c) and therein an user-controlled strcpy with static 256 buffer.
A simple test:

wn [long string here] -grepn

which results an obvious segfault again. As you said, the code is full of
these.

> with wdbuf being a 256 chars static buffer... I'd say this stuff would need a
> full security audit.

Hopefully Princeton-upstream is interested -- after all, Wordnet is an
award-winning piece of software with academic publications and research grants. 

A recommendation from an user: if no one is going to take the big task of a
almost complete rewrite, mask the packages, at least for the time being.

py did you contact upstream?

(In reply to comment #4)
> py did you contact upstream?
> 
Upstream contacted with a link to this bug.

oCERT has covered more bugs in their #2008-014 advisory. Rob has also prepared
a patch, which we should apply.
http://www.ocert.org/advisories/ocert-2008-014.html

Patch was added in wordnet-3.0-r1. x86 team, please, stabilize it.

going back to [ebuild]. The oCert patch does not address CVE-2008-2149, the
first issue in this bug. Please also apply this patch:
http://svn.debian.org/wsvn/debian-science/packages/wordnet/trunk/debian/patches/50_CVE-2008-2149_buffer_overflows.patch?op=file&rev=0&sc=0

Thank you Robert. Done in wordnet-3.0-r2.

x86 stable, all arches done.

GLSA request filed

GLSA 200810-01.