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.
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)!
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.
Regards
Mark