I happened to be a little careless when setting up my box. /etc/env.d/01hostname contained the FQDN instead of the hostname only. basc-1.4 and 1.5 exported the FQDN to gentoo-stats w/o warning. I'd appreciate it, if the script checks for FQDN and refuses to export the system data. Reproducible: Always Steps to Reproduce: 1. 2. 3. See http://article.gmane.org/gmane.linux.gentoo.security/2015/match=+security+vulnerability+stats for more the discussion around it.
BASC should not export any information helping to identify the host *and* the gentoo-stats server should not store any such information (like FQDN, source IP or else). The gentoo-stats pages should not provide any means of accessing per-system information, but only provide statistical data. These fixes are already being worked on.
The website no longer exports host information and client-side basc-1.5.1 should be fixed up to give users more warning of what is being transmitted. Proposing removal from package.mask.
Daniel two comments: basc still sends the full hostname if configured redhat style: basc --pretend PCNAME=myhost.example.net more importantly it adds the stats user without without a shell and without user instructions which probably results in most users running this as root.
Okay, here are the things I've fixed/changed yesterday: - The hostname is stripped *server-side*, if it contains a dot (all after the dot is stripped) or some numbers more than 3. To pretend having the FQDN or an ip-adress in the database. This is tested and works fine! - There is no possibility on the page any more, to see the details of other systems than my own system. - The client asks on the first run if he is allowed to generally send data over the net to the gentoo-stats server. - The client asks on every run, if he is allowed to collect *and* send wether the kernel-config, the x11-config or the USE-flags. For running it in a cronjob, there are two new options: -y/--yes, to answer yes to all question or -n/--no, to answer no to all questions. - The client has a new Option -p/--pretend, which does'nt send any data! It only shows the collected data on stdout to show off, what would be sent, if the client runs without the -p/--pretend option. Okay, that was it all I can remember... You see, I've fixed all of your security issues. There is definitly no ability anymore to assign any data to an hostname or to assign a hostname and it's data to a FQDN/ip-adress. No chance. It's all really anonymous. Ah, btw. the server-side code is opensource since yesterday. So you all can see, that it is all correct and serious.
Created attachment 47269 [details] basc-1.5.2.ebuild Okay, in addition to jaervosz` issues, I've now added the hostname-stripping also to the client too. It should work on nearly all hostnames with fqdn or ip-adress in it. If there should be one case, that the client-side stripping does'nt work, the server-side stripping does the rest. There is also now a bit more descriptive text in the pkg_postinstall() of the ebuild to tell the user how to start the client as user and not as root. I'm *really* hoping, that this is now all. Please take the attached ebuild, unmask it again and put it into the tree.
Heh, security is an ongoing process, so it's never finished. But it's now secure enough (and full-with-warnings enough) to get out of package-mask. pvdabeel : your call. Alexander: I'm sorry if you think we're nitpicking, but since the project was advertised on GWN and is called "gentoo-stats" we (the security team) have to be extra careful that it meets Gentoo-standard level of security. The security team can benefit from the stats you gather (we classify GLSA priority based on package commonality, your stats help make it a little more objective), so we would like to be able to advise all users to make use of the stats. And for that we need to clear out all security hurdles so that it's really safe to use by anyone. I appreciate your efforts and reactivity on this subject.
koon, I really dont think that you're "nitpicking", whatever this should be... *fg* (ahh, "pingelig", I see... ) No, that were all important security related points which needs to get fixed. But this project is now half a year old and at the beginning of this project, and the followed month, there were absolutly no interests from the devs to help me or to get it into the tree or something else. They only said: "...you only want to get dev, to show off...". But fact is/was, that I never wanted to get dev. It was suggested to me, because it was needed to be dev to get the subdomain stats.gentoo.org. Suddenly now, since *one* dev was judiciousness and helped me, to bring the client into the tree, suddenly all other devs had to tell something about it and how insecure and not anonymous it is... But well, that's all past now and I'm not resentful. Now I'm really glad to have the client in the official tree. The project is still not official and it also still don't have the subdomain stats.gentoo.org, but that does'nt matter. I want to thank the three devs who had talked with me directly, without flames or really not nice mails over a *public* mailinglist. Thanks to you pvdabeel, dsd and jaervosz.
I'll put the new ebuild in the tree, ask a few people to test and remove the mask. Thanks for the input and the good work getting this security bug fixed asap!
Thx Pieter. This is a normal security bug so please commit the fixed ebuild with appropriate arch markings and Security will call other needed arches for testing. For further information on how Security bugs are handled please consult the Vulnerability Policy: http://www.gentoo.org/security/en/vulnerability-policy.xml and the GLSA Coordinator Guide: http://www.gentoo.org/security/en/coordinator_guide.xml
I am still acting on developer feedback, please do not unmask yet.
New 1.5.2 ebuild committed and removed from package.mask. Older versions pruned from portage. Tested on x86, ppc Mips, hppa, ppc64, sparc, amd64 please test.
Installs and seems to run correctly for sparc. Sparc done.
I've added the ~ppc64 keyword before I saw this bug. I'll leave it for a few day/weeks as it is. If no problems are reported I will mark it stable.
I get this error when running the program(it still completes sucessfully, just a cosmetic error): > Getting CPU SMP/HT... sh: line 1: /usr/bin/smt-detect: No such file or directory also, I elected not to send my xorg.conf file, however it still recorded my windowmanager. I know that wm isn't a part of xorg.conf, but that might be confusing to some users. stable on amd64
#14 is fixed in version 1.5.3
Removing mips from list
Thx everyone closing without GLSA. hppa please remember to mark stable.
basc no longer in portage.
