CVE-2010-0826 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-0826): The Free Software Foundation (FSF) Berkeley DB NSS module (aka libnss-db) 2.2.3pre1 reads the DB_CONFIG file in the current working directory, which allows local users to obtain sensitive information via a symlink attack involving a setgid or setuid application that uses this module.
Patch available at https://bugzilla.redhat.com/attachment.cgi?id=405473
Maintainer timeout. Security bump. Arches, please test and stable: =sys-libs/nss-db-2.2.3_pre1-r4 Target arches: amd64 ppc x86. Thanks!
Change of plans. @base-system: since nss-db blocks on >=glibc-2.15, and since 2.15 is stable, and 2.15 and onwards have incorporated this functionality, how do you all feel about treecleaning? Will lastrite in 30 days if no response given.
<hat type="base-system"> 1. I don't see the nss-db file db-Makefile in my local glibc, and we also need to bring in the custom gentoo bits: remake-all-db, sandbox.d_50nss-db 2. Can somebody please test that glibc nss-db works properly? 3. Is glibc-2.15 still hardmasked on hppa? That's the only blocker I'd consider for tree-cleaning it. 4. Glibc is missing one of the dependencies for nss-db: >=sys-libs/db-4, please add it. Or is the glibc variant using a different backend? If it's using a different backend, there WILL be breakage for users if they try to change from nss-db to glibc, and the nss-db code can't read the db files. </hat>
(In reply to Robin Johnson from comment #4) hppa issues with newer glibc versions have been resolved
creffett: points 1,2,4 of my comment #4 aren't resolved yet; you haven't responded to me for 2 months since asking your questions. point 4 is the most critical one. The glibc version seems to use a custom DB format, while the older sys-libs/nss-db uses BerkDB explicitly. We need to force users to REMOVE their old .db files before upgrading, then run the remake-all-db script afterwards the upgrade. Possibly any app with open linkages to libnss_db might also need to be restarted? vapier: per my comment #4, point 1: 1. Can glibc please get $PORTDIR/sys-libs/nss-db/files/files/sandbox.d_50nss-db (also needs tweaking to include gshadow.db) 2. Can we install the remake-all-db script? (makefile has moved to /var/db/Makefile per glibc)
I haven't responded because I don't know the answers. I only jumped in here with the suggestion to remove because it appeared at first glance that glibc-2.15 had a drop-in replacement. If you would rather stable the version I added the upstream patch to, then we can do that too.
(In reply to Chris Reffett from comment #7) > I haven't responded because I don't know the answers. I only jumped in here > with the suggestion to remove because it appeared at first glance that > glibc-2.15 had a drop-in replacement. If you would rather stable the version > I added the upstream patch to, then we can do that too. creffet, vapier: Ok, I went and tested the glibc nss-db, and it's broken. Hangs infinitely in getservbyname lookups; anybody that uses those lookups will have a hung system. Most notably ssh does one of these lookups by default unless you have an explicit Port set in your configuration or commandline. Test program: ====== #include <netdb.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char** argv) { int i; struct servent *sp; printf("%s:%d:Calling getservbyname\n",__FILE__,__LINE__); sp = getservbyname("ssh", "tcp"); printf("%s:%d:Done getservbyname\n",__FILE__,__LINE__); if(sp == NULL) { printf("No service found\n"); exit(1); } printf("s_name: %s\n", sp->s_name); } ====== nsswitch.conf: services: db files This only occurs when the .db file exists (I created them freshly using the glibc Makefile to generate them).
(In reply to Robin Johnson from comment #6) re-sandbox.d file: why do we need that at all ? files shouldn't be opened for writing arbitrarily. re-remake-all-db script: i don't see the point of this thing, and no other distro installs it. re-hanging: sounds like bug 432020.
Looks like bug 486928 was handled use.masking the USE flag and, then, this could be finally be treecleaned
vulnerable packages still in tree
removed
Package removed per previous comments. GLSA needed?
package has been tree cleaned. No GLSA required
