On Thu, Jan 23, 2014 at 2:01 AM, Greg Stark <st...@mit.edu> wrote: > On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus <j...@agliodbs.com> wrote: > > Probably Heroku has some more specific exploit case to be concerned > > about here; if so, might I suggest taking it up with the -security list? > > I don't think there's a specific vulnerability that needs to be kept > secret here. > > Here's an example. I just created a new "hobby" database which is on a > multi-tenant cluster and ran select * from pg_stat_activity. Here are > two of the more interesting examples: > > 463752 | de5nmf0gbii3u5 | 32250 | 463751 | qspfkgrwgqtbcu | unicorn > worker[1] -p 30390 -c ./config/unicorn.rb | | > | | | > | | > | | | <insufficient privilege> > 463752 | de5nmf0gbii3u5 | 32244 | 463751 | qspfkgrwgqtbcu | unicorn > worker[0] -p 30390 -c ./config/unicorn.rb | | > | | | > | | > | | | <insufficient privilege> > > > Note that the contents of the ARGV array are being set by the > "unicorn" task queuing library. It knows it's making this information > visible to other users with shell access on this machine. But the > decision to stuff the ARGV information into the application_name is > being made by the Pg driver. Neither is under the control of the > application author who may not even be aware this is happening. > Neither component has the complete information to make a competent > decision about whether this information is safe to be in > application_name or not. > > Note that the query is showing as "<insufficient privilege>" even > though it is listed in the ps output -- the same ps output that is > listing the unicorn ARGV that is being shown in the > application_name.... > > You might say that the Pg gem is at fault for making a blanket policy > decision for applications that the ARGV is safe to show to other > database users but realistically it's so useful to see this > information for your own connections that it's probably the right > decision. Without it it's awfully hard to tell which worker is on > which connection. It would just be nice to be able to treat > application_name the same as query.
I would say that yes, this is clearly broken in the Pg gem. I can see it having such a default, but not allowing an override... The application can of course issue a SET application_name, assuming there is a hook somewhere in the system that will run after the connection has been established. I've had customers use that many times in java based systems for example, but I don't know enough about the pg gem, or unicorn, to have a clue if anything like it exists there. This is also a good way to track how connections are used throughout a pooled system where the same connection might be used for different things at different times. What actually happens if you set the application_name in the connection string in that environment? Does it override it to it's own default? If so, the developers there clearly need to be taught about fallback_application_name. And what happens if you set it in PGAPPNAME? Long term I agree we should really have some way of controlling these permissions more fine grained, but I just blanket hiding application name for non-superusers seems like a bad solution that still only fixes a small part of the problem. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
