Re: Entire process's environment attached to bugzillas by ABRT
On Tue, 2014-12-02 at 10:32 +, Richard W.M. Jones wrote: > On Tue, Dec 02, 2014 at 03:36:11AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Nov 30, 2014 at 08:29:27PM -0500, Rahul Sundaram wrote: > > > Hi > > > > > > On Sun, Nov 30, 2014 at 1:36 PM, Lars Seipel wrote: > > > > > > > > > > > > There's also OpenNebula (^ONE_) and Vmware (^VI_) doing the same. Seems > > > > to be pretty common with virt and cloud stuff. Apart from that I can't > > > > think of anything else right now. > > > > > > > > > Rackspace, DigitalOcean, Google Computing Engine etc have API info > > > potentially exported in the environment as well. This is going to be > > > quite > > > tedious to filter out but just in case you want to blacklist them, you > > > want to blacklist the following > > > > > > NOVA_* > > > DO_* > > > APPID_* > > OK, so far we have: > > > > OS_* > > AWS_* > > ONE_* > > VI_* > > NOVA_* > > DO_* > > APPID_* > > Sorry one more :-) > > EC2_* > > Used by older Amazon EC2 client, and by Eucalyptus (a free software > Amazon API client clone). > Thank you all! If you think of something new, please add a new comment to this Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1169760 Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Mon, 2014-12-01 at 16:01 +, Richard W.M. Jones wrote: > On Mon, Dec 01, 2014 at 03:18:36PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Nov 30, 2014 at 01:43:39PM +, Richard W.M. Jones wrote: > > > On Fri, Nov 28, 2014 at 07:39:47AM +0100, Jakub Filak wrote: > > > > The discussion I mentioned above was primarily about OpenStack (but the > > > > participants also expressed concerns about sending 'environ' to Bugzilla > > > > at all), where people are regularly storing their passwords and tokens > > > > as environment variables. > > > > > > Yes unfortunately OpenStack does by default encourage people to source > > > a 'keystonerc_admin' file which contains authentication tokens. The > > > file will look something like this: > > > > > > export OS_USERNAME=admin > > > export OS_TENANT_NAME=admin > > > export OS_PASSWORD=mysecretpassword > > > export OS_AUTH_URL=http://127.0.0.1:35357/v2.0/ > > > > > For Amazon EC2 you'd want to scrub /^AWS_/ > > Would it be enough to scrub OS_PASSWORD? We could filter out *PASSWORD* > > without gathering 50 cases. > > While it might be a good idea to also scrub all *PASSWORD* environment > strings, this isn't sufficient for AWS. AWS has two environment > variables (AWS_ACCESS_KEY and AWS_SECRET_KEY) which are both > sensitive. > > Also OS_USERNAME and OS_TENANT_NAME and even OS_AUTH_URL are somewhat > sensitive (less so than OS_PASSWORD of course) since they reveal that > a service exists, its location, and potential usernames to try > bruteforcing. > ABRT highlights almost all of them: https://github.com/abrt/libreport/blob/master/src/gui-wizard-gtk/forbidden_words.conf /etc/libreport/forbidden_words.conf But apparently the highlighting of sensitive words does not address this issue very well. We already auto-remove 'rootpw' lines from Anaconda reports[1], so there is no argument against implementing the same thing for 'environ' file for all applications: https://bugzilla.redhat.com/show_bug.cgi?id=1169760 Jakub 1: https://bugzilla.redhat.com/show_bug.cgi?id=1041558 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Tue, Dec 02, 2014 at 03:36:11AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Nov 30, 2014 at 08:29:27PM -0500, Rahul Sundaram wrote: > > Hi > > > > On Sun, Nov 30, 2014 at 1:36 PM, Lars Seipel wrote: > > > > > > > > > There's also OpenNebula (^ONE_) and Vmware (^VI_) doing the same. Seems > > > to be pretty common with virt and cloud stuff. Apart from that I can't > > > think of anything else right now. > > > > > > Rackspace, DigitalOcean, Google Computing Engine etc have API info > > potentially exported in the environment as well. This is going to be quite > > tedious to filter out but just in case you want to blacklist them, you > > want to blacklist the following > > > > NOVA_* > > DO_* > > APPID_* > OK, so far we have: > > OS_* > AWS_* > ONE_* > VI_* > NOVA_* > DO_* > APPID_* Sorry one more :-) EC2_* Used by older Amazon EC2 client, and by Eucalyptus (a free software Amazon API client clone). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Sun, Nov 30, 2014 at 08:29:27PM -0500, Rahul Sundaram wrote: > Hi > > On Sun, Nov 30, 2014 at 1:36 PM, Lars Seipel wrote: > > > > > > There's also OpenNebula (^ONE_) and Vmware (^VI_) doing the same. Seems > > to be pretty common with virt and cloud stuff. Apart from that I can't > > think of anything else right now. > > > Rackspace, DigitalOcean, Google Computing Engine etc have API info > potentially exported in the environment as well. This is going to be quite > tedious to filter out but just in case you want to blacklist them, you > want to blacklist the following > > NOVA_* > DO_* > APPID_* OK, so far we have: OS_* AWS_* ONE_* VI_* NOVA_* DO_* APPID_* I'd also add *SECRET* and *PASSWORD*. Let's filter on that. It should covert 95% of cases. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Mon, 2014-12-01 at 08:59 +, Richard W.M. Jones wrote: > On Sun, Nov 30, 2014 at 08:29:27PM -0500, Rahul Sundaram wrote: > > Hi > > > > On Sun, Nov 30, 2014 at 1:36 PM, Lars Seipel wrote: > > > > > > > > > There's also OpenNebula (^ONE_) and Vmware (^VI_) doing the same. Seems > > > to be pretty common with virt and cloud stuff. Apart from that I can't > > > think of anything else right now. > > > > > > Rackspace, DigitalOcean, Google Computing Engine etc have API info > > potentially exported in the environment as well. This is going to be quite > > tedious to filter out but just in case you want to blacklist them, you > > want to blacklist the following > > > > NOVA_* > > DO_* > > APPID_* > > It looks like they inherited this habit from Amazon ... > > For the avoidance of doubt, putting authentication information into > the environment is a bad, insecure practice. Any other local user can > immediately see it using 'ps axe'. No, that's just your processes: $ cat /proc/1/environ cat: /proc/1/environ: Permission denied $ Lubo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Sun, 2014-11-30 at 13:43 +, Richard W.M. Jones wrote:
> On Fri, Nov 28, 2014 at 07:39:47AM +0100, Jakub Filak wrote:
> > The discussion I mentioned above was primarily about OpenStack (but the
> > participants also expressed concerns about sending 'environ' to Bugzilla
> > at all), where people are regularly storing their passwords and tokens
> > as environment variables.
>
> Yes unfortunately OpenStack does by default encourage people to source
> a 'keystonerc_admin' file which contains authentication tokens. The
> file will look something like this:
>
> export OS_USERNAME=admin
> export OS_TENANT_NAME=admin
> export OS_PASSWORD=mysecretpassword
> export OS_AUTH_URL=http://127.0.0.1:35357/v2.0/
>
> For a public cloud, knowing those values could give anyone access to
> the account.
>
> How about having abrt just remove or scrub all variables that start
> with /^OS_/ ? I know it's nasty to have application-specific
> treatment of environment variables like this, but the number of
> applications that pass auth information through environment variables
> is small.
>
> For Amazon EC2 you'd want to scrub /^AWS_/
Some time ago I've run a search against Bugzilla and found a large
numbers of actual EC2 credentials there after I almost fell victim to
this myself.
So, yes, this IS a very actual issue. I find it perfectly possible that
someone else could do the same search and at the same time I find it
naive to assume everyone finds it inappropriate to access the affected
systems.
ABRT itself marked the reports potentially sensitive ("SECRET" in the
environment variable). The reporters did not apparently mind and I know
it's easy to make the mistake.
PS: I contacted everyone affected at the time so that they change their
credentials. Some of the reports were rather old and the credentials
still worked! Rotate your credentials regularly!
Lubo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Mon, Dec 01, 2014 at 03:18:36PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Nov 30, 2014 at 01:43:39PM +, Richard W.M. Jones wrote: > > On Fri, Nov 28, 2014 at 07:39:47AM +0100, Jakub Filak wrote: > > > The discussion I mentioned above was primarily about OpenStack (but the > > > participants also expressed concerns about sending 'environ' to Bugzilla > > > at all), where people are regularly storing their passwords and tokens > > > as environment variables. > > > > Yes unfortunately OpenStack does by default encourage people to source > > a 'keystonerc_admin' file which contains authentication tokens. The > > file will look something like this: > > > > export OS_USERNAME=admin > > export OS_TENANT_NAME=admin > > export OS_PASSWORD=mysecretpassword > > export OS_AUTH_URL=http://127.0.0.1:35357/v2.0/ > > > For Amazon EC2 you'd want to scrub /^AWS_/ > Would it be enough to scrub OS_PASSWORD? We could filter out *PASSWORD* > without gathering 50 cases. While it might be a good idea to also scrub all *PASSWORD* environment strings, this isn't sufficient for AWS. AWS has two environment variables (AWS_ACCESS_KEY and AWS_SECRET_KEY) which are both sensitive. Also OS_USERNAME and OS_TENANT_NAME and even OS_AUTH_URL are somewhat sensitive (less so than OS_PASSWORD of course) since they reveal that a service exists, its location, and potential usernames to try bruteforcing. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Sun, Nov 30, 2014 at 01:43:39PM +, Richard W.M. Jones wrote: > On Fri, Nov 28, 2014 at 07:39:47AM +0100, Jakub Filak wrote: > > The discussion I mentioned above was primarily about OpenStack (but the > > participants also expressed concerns about sending 'environ' to Bugzilla > > at all), where people are regularly storing their passwords and tokens > > as environment variables. > > Yes unfortunately OpenStack does by default encourage people to source > a 'keystonerc_admin' file which contains authentication tokens. The > file will look something like this: > > export OS_USERNAME=admin > export OS_TENANT_NAME=admin > export OS_PASSWORD=mysecretpassword > export OS_AUTH_URL=http://127.0.0.1:35357/v2.0/ > For Amazon EC2 you'd want to scrub /^AWS_/ Would it be enough to scrub OS_PASSWORD? We could filter out *PASSWORD* without gathering 50 cases. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Sun, Nov 30, 2014 at 08:29:27PM -0500, Rahul Sundaram wrote: > Hi > > On Sun, Nov 30, 2014 at 1:36 PM, Lars Seipel wrote: > > > > > > There's also OpenNebula (^ONE_) and Vmware (^VI_) doing the same. Seems > > to be pretty common with virt and cloud stuff. Apart from that I can't > > think of anything else right now. > > > Rackspace, DigitalOcean, Google Computing Engine etc have API info > potentially exported in the environment as well. This is going to be quite > tedious to filter out but just in case you want to blacklist them, you > want to blacklist the following > > NOVA_* > DO_* > APPID_* It looks like they inherited this habit from Amazon ... For the avoidance of doubt, putting authentication information into the environment is a bad, insecure practice. Any other local user can immediately see it using 'ps axe'. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
Hi On Sun, Nov 30, 2014 at 1:36 PM, Lars Seipel wrote: > > > There's also OpenNebula (^ONE_) and Vmware (^VI_) doing the same. Seems > to be pretty common with virt and cloud stuff. Apart from that I can't > think of anything else right now. Rackspace, DigitalOcean, Google Computing Engine etc have API info potentially exported in the environment as well. This is going to be quite tedious to filter out but just in case you want to blacklist them, you want to blacklist the following NOVA_* DO_* APPID_* Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Sun, Nov 30, 2014 at 01:43:39PM +, Richard W.M. Jones wrote: > How about having abrt just remove or scrub all variables that start > with /^OS_/ ? I know it's nasty to have application-specific > treatment of environment variables like this, but the number of > applications that pass auth information through environment variables > is small. > > For Amazon EC2 you'd want to scrub /^AWS_/ There's also OpenNebula (^ONE_) and Vmware (^VI_) doing the same. Seems to be pretty common with virt and cloud stuff. Apart from that I can't think of anything else right now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Fri, Nov 28, 2014 at 07:39:47AM +0100, Jakub Filak wrote: > The discussion I mentioned above was primarily about OpenStack (but the > participants also expressed concerns about sending 'environ' to Bugzilla > at all), where people are regularly storing their passwords and tokens > as environment variables. Yes unfortunately OpenStack does by default encourage people to source a 'keystonerc_admin' file which contains authentication tokens. The file will look something like this: export OS_USERNAME=admin export OS_TENANT_NAME=admin export OS_PASSWORD=mysecretpassword export OS_AUTH_URL=http://127.0.0.1:35357/v2.0/ For a public cloud, knowing those values could give anyone access to the account. How about having abrt just remove or scrub all variables that start with /^OS_/ ? I know it's nasty to have application-specific treatment of environment variables like this, but the number of applications that pass auth information through environment variables is small. For Amazon EC2 you'd want to scrub /^AWS_/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Fri, 2014-11-28 at 00:28 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Nov 27, 2014 at 07:02:00PM +0100, Jan Kratochvil wrote: > > On Thu, 27 Nov 2014 16:23:57 +0100, Jakub Filak wrote: > > > Do you find 'environ' attachment valuable or is ABRT just publishing > > > personal > > > information? > > > > No but I can imagine in some cases it may be useful. > Is this a problem in practice? Unfortunately yes, I started this thread after participating in a discussion about leaking personal information in 'environment'. > I don't recall ever seeing anything > private in the hundreds of abrt traces I looked at. > I checked the enironment of my shell, nothing interesting there, and > I'm not aware of any services using environment variables to pass > authentication data. The discussion I mentioned above was primarily about OpenStack (but the participants also expressed concerns about sending 'environ' to Bugzilla at all), where people are regularly storing their passwords and tokens as environment variables. > If anything, the cwd and open fds reveal the most > information, but they are also one of the most useful parts (in my > experience, that is version strings and backtrace followed by open fds). > > > Couldn't there be a way to send additional information upon bug assignee's > > request? That would be typically useful with the core files but reporters > > always said they cannot find the core file anywhere. > Actually if the scheme that Jakub is working on is adopted and > coredumps are stored by systemd, they will be available for longer, > and it should often be possible to request a coredump after the fact. > > But in general depending on user help after the fact is most often > futile. I wouldn't go there unless actual complaints about exposed > data appear. I opened the following bugzilla bug for those who store private data as environment variables: https://bugzilla.redhat.com/show_bug.cgi?id=1168494 Regards, Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Thu, 2014-11-27 at 19:02 +0100, Jan Kratochvil wrote: > On Thu, 27 Nov 2014 16:23:57 +0100, Jakub Filak wrote: > > Do you find 'environ' attachment valuable or is ABRT just publishing > > personal > > information? > > No but I can imagine in some cases it may be useful. > > Couldn't there be a way to send additional information upon bug assignee's > request? That would be typically useful with the core files but reporters > always said they cannot find the core file anywhere. > Yes, but it is not trivial to implement. I did the first step and opened the following pull request: https://github.com/abrt/gnome-abrt/pull/95 The patch enables users to filter problems by Bugzilla ID in gnome-abrt. So you can ask the report to write Bugzilla ID to the search field in gnome-abrt and it should show him the original ABRT problem. 'coredump' is stored in $DATA_DIRECTORY and the path to $DATA_DIRECTORY can be found under "Details" (bottom-right corner). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Thu, Nov 27, 2014 at 07:02:00PM +0100, Jan Kratochvil wrote: > On Thu, 27 Nov 2014 16:23:57 +0100, Jakub Filak wrote: > > Do you find 'environ' attachment valuable or is ABRT just publishing > > personal > > information? > > No but I can imagine in some cases it may be useful. Is this a problem in practice? I don't recall ever seeing anything private in the hundreds of abrt traces I looked at. I checked the enironment of my shell, nothing interesting there, and I'm not aware of any services using environment variables to pass authentication data. If anything, the cwd and open fds reveal the most information, but they are also one of the most useful parts (in my experience, that is version strings and backtrace followed by open fds). > Couldn't there be a way to send additional information upon bug assignee's > request? That would be typically useful with the core files but reporters > always said they cannot find the core file anywhere. Actually if the scheme that Jakub is working on is adopted and coredumps are stored by systemd, they will be available for longer, and it should often be possible to request a coredump after the fact. But in general depending on user help after the fact is most often futile. I wouldn't go there unless actual complaints about exposed data appear. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Entire process's environment attached to bugzillas by ABRT
On Thu, 27 Nov 2014 16:23:57 +0100, Jakub Filak wrote: > Do you find 'environ' attachment valuable or is ABRT just publishing personal > information? No but I can imagine in some cases it may be useful. Couldn't there be a way to send additional information upon bug assignee's request? That would be typically useful with the core files but reporters always said they cannot find the core file anywhere. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
