Bug 201726 (CVE-2007-6350) – net-misc/scponly - svn, svnserve, unison and rsync passthrough is unsafe by design (CVE-2007-6350)

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Jakub Moc (RETIRED) 2007-12-08 23:08:30 UTC]

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437148 for details, basically these features can be misused for user to gain an undesired shell access.

- We don't ship this w/ unison support
- subversion support is optional on USE=subversion
- rsync support is enabled by default in the ebuild.

Some of insecure commands have been disabled in CVS, no release yet however, plus it's unlikely it will ever cover all potential bypasses via these features. 

So:

- we can either make rsync support optional as well, change the use flag descriptions in use.local.desc accordingly and point users to http://scponly.cvs.sourceforge.net/scponly/scponly/SECURITY?&view=markup for info on security implications of those options

- or hard-disable the functionality

Opinions?

[Comment 1 Robert Buchholz (RETIRED) 2007-12-09 22:36:22 UTC]

Thanks for finding that one, Jakub.

The rsync&co functionality is broken by design.
I'd say:

1) Disable all of unison, svn and rsync by default, introduce (by default disabled) use-flags and if those are enabled, ewarn about the issues and refer people to the SECURITY file.

2) I'd also vote for the SECURITY file to be included in the ebuild.

3) Patches from the svn or latest release should get into an ebuild that goes stable afterwards. 

Matsuu, please advise.

[Comment 2 MATSUU Takuto (RETIRED) 2007-12-11 16:21:35 UTC]

4.6-r3 in cvs. added rsync USE flag and added files/SECURITY.
I tried unsuccessfully to backport patches.

[Comment 3 MATSUU Takuto (RETIRED) 2008-01-16 17:06:42 UTC]

4.8 in cvs.

[Comment 4 Sune Kloppenborg Jeppesen (RETIRED) 2008-01-16 19:03:21 UTC]

Thx Matsuu. I presume it is fixed in 4.8 (their wiki seems out of date)?

Arches please test and mark stable. Target keywords are:

scponly-4.8.ebuild:KEYWORDS="amd64 ppc sparc x86"

[Comment 5 Christian Faulhammer (RETIRED) 2008-01-17 08:33:55 UTC]

x86 stable

[Comment 6 Tobias Scherbaum (RETIRED) 2008-01-18 20:21:41 UTC]

ppc stable

[Comment 7 Raúl Porcel (RETIRED) 2008-01-21 11:15:22 UTC]

sparc stable

[Comment 8 Peter Weller (RETIRED) 2008-01-22 10:19:01 UTC]

amd64 done.

[Comment 9 Sune Kloppenborg Jeppesen (RETIRED) 2008-01-22 11:06:27 UTC]

This one is ready for GLSA vote. I tend to vote NO.

[Comment 10 Robert Buchholz (RETIRED) 2008-01-22 23:48:25 UTC]

I think we should GLSA this together with 203099, and note the insecurities of svn.

[Comment 11 Sune Kloppenborg Jeppesen (RETIRED) 2008-01-23 09:02:45 UTC]

Sounds like a good idea.

[Comment 12 Pierre-Yves Rofes (RETIRED) 2008-02-12 21:08:41 UTC]

GLSA 200802-06, sorry for the delay.