Bugzilla Bug 74703

The following advisory from securesoftware@list.cr.yp.to is for NapShare 1.2.
I've _not_ checked whether net-p2p/napshare-1.3 is still vulnerable.

Date: 15 Dec 2004 08:24:39 -0000
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: [remote] [control] NapShare 1.2 auto_filter_extern overflows filename
buffer
To: securesoftware@list.cr.yp.to, napshare-developer@lists.sourceforge.net
X-HELOcheck: OK: FQDN
Mailing-List: contact securesoftware-help@list.cr.yp.to; run by ezmlm
Mail-Followup-To: securesoftware@list.cr.yp.to,
        napshare-developer@lists.sourceforge.net
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.

[-- Attachment #1 [details] --]
[-- Type: text/plain, Encoding: 7bit, Size: 1.1K --]

Bartlomiej Sieka, a student in my Fall 2004 UNIX Security Holes course,
has discovered a remotely exploitable security hole in NapShare, at
least version 1.2 (the current version in FreeBSD ports). I'm publishing
this notice, but all the discovery credits should be assigned to Sieka.

You are at risk if you you use NapShare with an ``extern'' filter.
Anyone who provides a gnutella response to NapShare (not necessarily the
legitimate server administrator; an attacker can modify responses
passing through the network) then has complete control over your
account: he can read and modify your files, watch the programs you're
running, etc.

The attached files 40-1.c and 40-2.c are two different proof-of-concept
servers that will convince NapShare under FreeBSD 5 to create
unauthorized files in the current directory.

Here's the bug: In auto.c, auto_filter_extern() uses strcpy() to copy
any amount of data into a 5200-byte filename[] array.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Created an attachment (id=46177) [details]
File 40-1.c from advisory

Created an attachment (id=46178) [details]
File 40-2.c from advisory

======================================================
Candidate: CAN-2004-1286
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1286
Reference: MISC:http://tigger.uic.edu/~jlongs2/holes/napshare.txt

Buffer overflow in the auto_filter_extern function in auto.c for
NapShare 1.2, with the extern filter enabled, allows remote attackers
to execute arbitrary code via a crafted gnutella response.
======================================================

Upstream looks quite dead too.
net-p2p: opinion ? Would you like to fix it, or do you prefer that we mask it ?

I suppose noone in net-p2p cares about this one... Upstream is dead, requesting
a mask for napshare.

Masked per request of Koon.

NapShare V2.1 is out, as of 2005-02-05. 

net-p2p please bump if the new release fixes this issue.

I'm so confused.

The code in napshare's CVS is still vulnerable... and NapShare v2.1 is written in C++ (as opposed to C), and has a completely different source tree.

Someone please fill me in.

I would say napshare-2 is a rewrite in C++, that is not in the SF CVS
repository, for which we still have to verify if it's affected or not by the
flaw.

If it's not vulnerable, net-p2p should bump to it
If it is, maybe we should inform upsatream of the bug beacuse they must have
missed it.

Auditors/someone: care to have a look ?

2+ is a complete rewrite and does not use the old code. This specific
vulnerability does not exist in 2+.

net-p2p: you can bump to napshare-2, remove affected versions and unmask.

sekretarz will bump it

I can't even build napshare-2.1 on my computer.

If someone manages to build and can provide an ebuild... otherwise we'll keep
it masked for some time before getting rid of it.

NapShare 2.2.3 is based on MUTE 0.4 with some improvements. Until version 1.9
it was a Gnutella client.

For installation instructions see my HOWTO for MUTE:
http://forums.gentoo.org/viewtopic-t-331919.html

Unfortunately I don't know how to make ebuilds but bug #37609 and bug #60392
could also help with NapShare.

Removing the old vulnerable napshare package, since it has nothing to do with
the current one anyway.