commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (POOL-372) CallStackUtils mishandles security manager check part 2
Date Thu, 25 Jul 2019 01:33:00 GMT

     [ https://issues.apache.org/jira/browse/POOL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gary Gregory updated POOL-372:
------------------------------
    Description: 
This ticket is for (b).

CallStackUtils determines at initialization time whether it is allowed to create a security
manager, then sticks that info into a static variable and never checks it again, relying on
this check to later try to create a SecurityManager for a SecurityManagerCallStack. This is
doubly wrong:

a) If the code is running in a privileged context at init time, it determines that it can
create a security manager, and then later naively assumes that henceforth all code is privileged
and also can create a security manager. Of course this is not true, otherwise one would not
need a security manager in the first place! This info can never be kept in a static variable,
it's extremely context-dependent. So this leads to AccessControlException from invoking newCallStack()
if abandoned object logging is enabled.

b) The permission to create a security manager must never be granted to any code, unless that
code has AllPermission in the first place, i.e. is already fully privileged. This is because
this permission allows circumventing the security manager completely (simply create one that
lets all checks pass). Therefore even just checking whether you're allowed to create a secmgr
is naive - if a secmgr is installed at all you should assume that you're NOT privileged enough
to do this, simply because for sure some code that calls your code will not be privileged
enough.

 

  was:
This ticket is for (a).
CallStackUtils determines at initialization time whether it is allowed to create a security
manager, then sticks that info into a static variable and never checks it again, relying on
this check to later try to create a SecurityManager for a SecurityManagerCallStack. This is
doubly wrong:

a) If the code is running in a privileged context at init time, it determines that it can
create a security manager, and then later naively assumes that henceforth all code is privileged
and also can create a security manager. Of course this is not true, otherwise one would not
need a security manager in the first place! This info can never be kept in a static variable,
it's extremely context-dependent. So this leads to AccessControlException from invoking newCallStack()
if abandoned object logging is enabled.

b) The permission to create a security manager must never be granted to any code, unless that
code has AllPermission in the first place, i.e. is already fully privileged. This is because
this permission allows circumventing the security manager completely (simply create one that
lets all checks pass). Therefore even just checking whether you're allowed to create a secmgr
is naive - if a secmgr is installed at all you should assume that you're NOT privileged enough
to do this, simply because for sure some code that calls your code will not be privileged
enough.

 


> CallStackUtils mishandles security manager check part 2
> -------------------------------------------------------
>
>                 Key: POOL-372
>                 URL: https://issues.apache.org/jira/browse/POOL-372
>             Project: Commons Pool
>          Issue Type: Bug
>            Reporter: Volker Kleinschmidt
>            Priority: Major
>
> This ticket is for (b).
> CallStackUtils determines at initialization time whether it is allowed to create a security
manager, then sticks that info into a static variable and never checks it again, relying on
this check to later try to create a SecurityManager for a SecurityManagerCallStack. This is
doubly wrong:
> a) If the code is running in a privileged context at init time, it determines that it
can create a security manager, and then later naively assumes that henceforth all code is
privileged and also can create a security manager. Of course this is not true, otherwise one
would not need a security manager in the first place! This info can never be kept in a static
variable, it's extremely context-dependent. So this leads to AccessControlException from invoking
newCallStack() if abandoned object logging is enabled.
> b) The permission to create a security manager must never be granted to any code, unless
that code has AllPermission in the first place, i.e. is already fully privileged. This is
because this permission allows circumventing the security manager completely (simply create
one that lets all checks pass). Therefore even just checking whether you're allowed to create
a secmgr is naive - if a secmgr is installed at all you should assume that you're NOT privileged
enough to do this, simply because for sure some code that calls your code will not be privileged
enough.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Mime
View raw message