On Tue, Jan 21, 2014 at 5:22 PM, Mark Kirkwood
<mark.kirkwood@catalyst.net.nz> wrote:
> On 22/01/14 13:32, Harold Giménez wrote:
>>
>> On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>>
>>> On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote:
>>>>
>>>> I don't know of a client where it can't be overridden. The friction
>>>> occurs when by default it sets it to something useful to a developer
>>>> (useful eg: to find what process is holding a lock), but is not
>>>> possible to conceal from other users on the same cluster. If this were
>>>> an in-premise or private cluster the point is moot.
>>>>
>>>> Furthermore consider when even using application_name for it's
>>>> original intended use. On a shared environment as I'm describing here,
>>>> that makes it possible for an attacker to identify what apps connect
>>>> to a given server, or on the other hand is a way to find out where a
>>>> given application stores its data, which can be used for a more
>>>> targeted attack.
>>>
>>>
>>> So security through obscurity? Why wouldn't the attacker just try all
>>> the app methods at once and not even bother looking at the application
>>> name?
>>
>>
>> A malicious attacker may want to attack or harm `app1`. They write a
>> script that provisions databases and check in pg_stat_activity until
>> they find an application_name of `app1`. Having found the database
>> holding app1's data, they then use a targeted attack on postgres, say
>> a privilege escalation attack or any other vulnerability we don't know
>> exists yet. Without application_name, the attacker would be unable to
>> find the target database host to attack.
>>
>
> If said malicious attacker can log into postgres and issue its own queries,
> and connect to other database then you are in serious trouble already.
They can connect to their database, but not other databases in the cluster.
>
> I also wonder that if such an attacker knows the application name, that
> would suggest that they have access to the application server and are able
> to read its config files...which would probably also contain the host and db
> name too (and possibly the password in some unfortunate cases)!
No, I am considering something along the lines of www.foobar.com would
have an application_name =~ '%foobar%'
>
> In addition people normally name app users and app dbs in a fairly
> predictable way (e.g 'finance' app uses 'finance' user to connect to
> 'finance' db), so I'm not seeing much value in trying to hide application
> name.
Some database service providers like Heroku Postgres generate role
names and passwords, which are not predictable and users cannot
change.
Regards,
-Harold