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.
