Bug 152787

John Buswell discovered a flaw in redhat-config-nfs that could lead to
incorrect permissions on exported shares when exporting to multiple
hosts. This could cause an option such as "all_squash" to not be
applied to all of the listed hosts. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-0750 to
this issue.

Additionally, a bug was found that prevented redhat-config-nfs from being
run if hosts didn't have options set in /etc/exports.

Info:
https://rhn.redhat.com/errata/RHSA-2004-434.html
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107997



------- Additional Comments From marcdeslauriers 2004-09-22 13:56:24 ----

Need to check if rh9 and fc1 are vulnerable to this.



------- Additional Comments From marcdeslauriers 2004-09-22 17:44:26 ----

They are indeed vulnerable, must patch.



------- Additional Comments From marcdeslauriers 2004-09-22 18:33:46 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are updated packages to QA for rh9 and fc1.
They fix CAN-2004-0750 and a few major functionality bugs.

rh9 Changelog:
* Thu Sep 23 2004 Marc Deslauriers <marcdeslauriers> 1.0.13-5.legacy
- - rebuilt as Fedora Legacy security update to fix CAN-2004-0750
- - revert desktop file to rh9 format

fc1 Changelog:
* Thu Sep 23 2004 Marc Deslauriers <marcdeslauriers> 1.1.3-2.legacy 
- - close properties dialog when clicking OK button
- - handle /etc/exports missing gracefully
- - fix incorrect syntax for multiple hosts with a single mount point
  CAN-2004-0750 (patch by Shannon Mitchell)
- - don't barf on optionless hosts
- - readonly is default

rh9:
0f7a70f06c62a187573e3894ae8fff214779ec92 
redhat-config-nfs-1.0.13-5.legacy.noarch.rpm
d87293932391ab05d23910f3a0babad3190d8485  redhat-config-nfs-1.0.13-5.legacy.src.rpm

fc1:
6cfebc18e601bdf90b5d4eb90747affd5fd3808c 
redhat-config-nfs-1.1.3-2.legacy.noarch.rpm
1f0816df60b01039c6bcbafa3b331abf30d420ce  redhat-config-nfs-1.1.3-2.legacy.src.rpm

http://www.infostrategique.com/linuxrpms/legacy/9/redhat-config-nfs-1.0.13-5.legacy.noarch.rpm
http://www.infostrategique.com/linuxrpms/legacy/9/redhat-config-nfs-1.0.13-5.legacy.src.rpm
http://www.infostrategique.com/linuxrpms/legacy/1/redhat-config-nfs-1.1.3-2.legacy.noarch.rpm
http://www.infostrategique.com/linuxrpms/legacy/1/redhat-config-nfs-1.1.3-2.legacy.src.rpm




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBUlIPLMAs/0C4zNoRApLmAKCSkfKgOfICo5NcF6SsLGfGIwiAnwCfX2kK
0dDtJxiRaya0kJUV7AODAa8=
=9bcQ
-----END PGP SIGNATURE-----




------- Additional Comments From rob.myers.edu 2004-09-23 04:31:12 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
I did QA on the FC1 package:
 
1f0816df60b01039c6bcbafa3b331abf30d420ce  redhat-config-nfs-1.1.3-2.legacy.src.rpm
 
- - spec file looks good
- - builds ok
- - installs ok
- - works ok
- - source file identical to FC1 release
- - i'm no python expert, but patches look ok
 
i tried to follow the rules at http://www.fedoralegacy.org/wiki/index.php/QaTesting
but its my first time so please let me know if i missed anything!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
 
iD8DBQFBUt3TtU2XAt1OWnsRAlNjAKD4V3IGWcfqQCyE+wb8HpS7Yv8hOgCgq3kG
6pyS28aG63/esk1nk/n04WU=
=23F4
-----END PGP SIGNATURE-----




------- Additional Comments From josh.kayse.edu 2004-10-08 03:11:00 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I did QA on the FC1 package:

1f0816df60b01039c6bcbafa3b331abf30d420ce  redhat-config-nfs-1.1.3-2.legacy.src.rpm

- - spec file looked good
- - builds ok
- - installs ok
- - runs ok
- - source file identical to previous FC1 release
- - patch files look ok
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFBZpG4wnUFCSDmt7ERAooKAJ9Jbrvle9tAkSXjTibmM9ItNgXR9wCeODen
EgYgGppUE+5LuW2/cprk1JU=
=ogRz
-----END PGP SIGNATURE-----




------- Additional Comments From byte.my 2004-10-18 02:59:30 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA on the FC1 package performed

1f0816df60b01039c6bcbafa3b331abf30d420ce  redhat-config-nfs-1.1.3-2.legacy.src.rpm

- - spec file looks okay except for
        warning: File listed twice: /usr/share/redhat-config-nfs/pixmaps
        warning: File listed twice:
/usr/share/redhat-config-nfs/pixmaps/redhat-config-nfs.png
- - it buils okay
- - it installs okay
- - runs fine
- - source file is identical to previous in FC1 release
- - patches and python looks okay

Patch below "fixes" spec file warning. One last remainder error, its getting
late to fix...

warning: File listed twice:
/usr/share/redhat-config-nfs/pixmaps/redhat-config-nfs.png

diff -urN redhat-config-nfs.spec~ redhat-config-nfs.spec
- --- redhat-config-nfs.spec~     2004-09-23 14:24:15.000000000 +1000
+++ redhat-config-nfs.spec      2004-10-18 22:36:49.000000000 +1000
@@ -60,7 +60,6 @@
 %doc doc/*
 %{_bindir}/redhat-config-nfs
 %dir %{_datadir}/redhat-config-nfs
- -%dir %{_datadir}/redhat-config-nfs/pixmaps
 %{_datadir}/redhat-config-nfs/*
 %attr(0644,root,root) %{_datadir}/applications/redhat-config-nfs.desktop
 %attr(0644,root,root) %{_datadir}/%{name}/pixmaps/redhat-config-nfs.png
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBc7xQiktHAE0k2bYRAnTWAJ49eu2VFjXf2z/cX44VTB6dUaqZVgCgg7Fv
w/rMScMbhpT6fPNV+5ofYQo=
=Hg9y
-----END PGP SIGNATURE-----




------- Additional Comments From pekkas 2004-12-15 09:26:22 ----

Where can I find redhat-config-nfs-1.0.13.tar.bz2 to verify that it's integrity
is OK?

I suggest we just either:
 1) stick to security fixes;
 2) functionality fixes if they can be clearly backported with minimal patching; or
 3) if creating a significant functionality increase go to a version the
correctness of which is easily verifiable.



------- Additional Comments From marcdeslauriers 2004-12-15 12:43:33 ----

In response to comment #7:

You can find the original tarball in the update Red Hat released for RHEL3:
https://rhn.redhat.com/errata/RHSA-2004-434.html

By the way, it IS a security fix.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0750

Sorry for not mentioning where the source came from. I didn't think it would be
difficult to find.






------- Additional Comments From pekkas 2004-12-15 20:04:41 ----

I couldn't find it with google, sorry ;-)

Yes, I wasn't refuting this didn't include a security fix, it just included a
lot of other stuff as well.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
                                                                               
                
QA on the SRPM w/ rpm-build-compare.sh
 - sources match the ones provided in RHEL3 update
 - spec file changes are reasonable
        * python-tools buildrequires was removed, but that's OK because it's
          not needed.
 - desktop file patch verified
 - rebuilds OK.
                                                                               
                
+PUBLISH (RH9)
                                                                               
                
d87293932391ab05d23910f3a0babad3190d8485  redhat-config-nfs-1.0.13-5.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
                                                                               
                
iD8DBQFBwSUVGHbTkzxSL7QRAldAAKDEuzTxk1vXkXZriAzgDTFj8840OgCfR/6o
tgMSzAQdPZIlHPSNMQkSr7M=
=lgx7
-----END PGP SIGNATURE-----




------- Additional Comments From dom 2005-02-03 13:30:11 ----

packages pushed to updates-testing



------- Additional Comments From S.J.Thompson.ac.uk 2005-02-08 00:51:32 ----


RPM
0935165a66653b8c546713178b975e55119717fe 
redhat-config-nfs-1.0.13-5.legacy.noarch.rpm

This packages don't appear to fix the security problem (at least under RH9).

i.e. if I start the tool, create a new share which is "Read Only", exported to
"host1 host2" and has the option "Treat all clients as anonymous users" set, I
get the following in my /etc/exports file:

/sample/directory      host1 host2(ro,sync,all_squash)

I would _expect_ to get:
/sample/directory      host1(ro,sync,all_squash) host2(ro,sync,all_squash)

i.e. the options are only being applied to the _last_ host.

Package does NOT appear to resolve security issue in Comment #1.

(The bug where redhat-config-nfs won't run if there are no options is fixed though).



------- Additional Comments From S.J.Thompson.ac.uk 2005-02-08 00:53:00 ----

Actually not Comment #1 but Description



------- Additional Comments From pekkas 2005-02-08 07:18:54 ----

Could you double-check which version of the tool you were running?  The patch is
applied in the RPM, the patch is functionally identical to upstream bugzilla
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107997) and identical to
what was shipped in the RHEL3 update.

If their patch was broken,... well.. that can happen, of course. I'll try to
remember to test this myself.



------- Additional Comments From S.J.Thompson.ac.uk 2005-02-08 08:00:04 ----

% rpm -q redhat-config-nfs
redhat-config-nfs-1.0.13-5.legacy

I'll check on one of our boxes that is actually running RHEL3 and see if its
fixed on that.



------- Additional Comments From marcdeslauriers 2005-02-08 13:30:18 ----

Can someone else try this...I just did and it worked ok for me...




------- Additional Comments From pekkas 2005-02-08 22:20:24 ----

Worked for me as well.  Maybe you accidentally typed something else than space
in the tab or something?

I picked read-only, anonymous, and exported "/" to "host1 host", and the result was:

# more /etc/exports
/                        host1(ro,sync,all_squash)
/                        host2(ro,sync,all_squash)

Did you try removing /etc/exports before doing this?



------- Additional Comments From S.J.Thompson.ac.uk 2005-02-08 23:13:43 ----

OK if you remove /etc/exports then the issue is fixed. i.e. if you create a
*new* exported share however if you edit an existing share and add another host
then the problem still appears to exist.



------- Additional Comments From pekkas 2005-02-09 00:15:28 ----

Yes, I tested this as well.  The patch is IMHO incomplete; it does not handle
'properties' at all.  This is not fixed in the latest CVS version either.

I don't know much of python, but I tried a few ways to fix this, but it wouldn't
work properly.  Maybe the correct fix will be to remove being able to edit the
"hosts" line in 'edit' mode; otherwise the code will have to deduct which subset
of the hosts you added (or removed), and add those to the list and apply the
changes to the all.

I suggest you reopen the Red Hat bug report, and we'll see how that develops.



------- Additional Comments From S.J.Thompson.ac.uk 2005-02-10 23:20:51 ----

I have confirmed that the problem exists in RHEL 3 still - didn't think it
wouldn't as the FL patch is the same, but I had to check. I've attached a note
to the RHEL bugzilla entry.

Is it still worth pushing this updated package out as it partially resolves the
security problem?



------- Bug moved to this database by dkl 2005-03-30 18:27 -------

This bug previously known as bug 2086 at https://bugzilla.fedora.us/
https://bugzilla.fedora.us/show_bug.cgi?id=2086
Originally filed under the Fedora Legacy product and Package request component.

Unknown priority P2. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.