You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Ron Mann (JIRA)" <ji...@apache.org> on 2007/08/10 16:31:42 UTC
[jira] Created: (RIVER-205) LookupDiscovery can give untrusted code
access to privileged threads
LookupDiscovery can give untrusted code access to privileged threads
--------------------------------------------------------------------
Key: RIVER-205
URL: https://issues.apache.org/jira/browse/RIVER-205
Project: River
Issue Type: Bug
Components: net_jini_discovery
Reporter: Ron Mann
Priority: Minor
Bugtraq ID [6357961|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6357961]
LookupDiscovery uses a TaskManager and WakeupManager instance which it may retrieve from a Configuration object that is passed to it at construction time. Some tasks that it generates using these utilities (DecodeAnnouncementTask, UnicastDiscoveryTask) are done within a thread with raised privileges. If the TaskManager and WakeupManager needs to spawn threads to dispatch the task, they will be spawned with the same security context as the privileged thread. Untrusted code can construct a LookupDiscovery instance with a Configuration object that returns TaskManager and WakeupManager instances that it has a handle to. It can then add new tasks (using say dynamic proxy or other trusted code) to its TaskManager and WakeupManager instances, which get executed with the security context of the privileged LookupDiscovery thread.
Also note that the LookupDiscovery thread which generates the tasks retains the DomainCombiner that was present at the time of instantiation, so there is the theoretical possibility of exploiting, say the JAAS Subject if the combiner were a SubjectDomainCombiner.
Suggested Fix:
LookupDiscovery should restore the security context (that it snap shots at instantiation time) before it adds tasks to TaskManager and WakeupManager. We need to ensure that existing operations within those tasks do not need elevated privilege. If they do, those operations may be performed in doPrivileged blocks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-205) LookupDiscovery can give untrusted code
access to privileged threads
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Vinod Johnson updated RIVER-205:
---------------------------------------
Security: Security risk, visible to anyone
Changed the security level field. I set it to visible to anyone at this point, given that it has been in the public eye for so long.
> LookupDiscovery can give untrusted code access to privileged threads
> --------------------------------------------------------------------
>
> Key: RIVER-205
> URL: https://issues.apache.org/jira/browse/RIVER-205
> Project: River
> Issue Type: Bug
> Security Level: Security risk, visible to anyone(Issues identified as security risk but for which a patch is available)
> Components: net_jini_discovery
> Reporter: Ron Mann
> Assignee: Thomas Vinod Johnson
> Priority: Minor
> Fix For: AR2
>
>
> Bugtraq ID [6357961|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6357961]
> LookupDiscovery uses a TaskManager and WakeupManager instance which it may retrieve from a Configuration object that is passed to it at construction time. Some tasks that it generates using these utilities (DecodeAnnouncementTask, UnicastDiscoveryTask) are done within a thread with raised privileges. If the TaskManager and WakeupManager needs to spawn threads to dispatch the task, they will be spawned with the same security context as the privileged thread. Untrusted code can construct a LookupDiscovery instance with a Configuration object that returns TaskManager and WakeupManager instances that it has a handle to. It can then add new tasks (using say dynamic proxy or other trusted code) to its TaskManager and WakeupManager instances, which get executed with the security context of the privileged LookupDiscovery thread.
> Also note that the LookupDiscovery thread which generates the tasks retains the DomainCombiner that was present at the time of instantiation, so there is the theoretical possibility of exploiting, say the JAAS Subject if the combiner were a SubjectDomainCombiner.
> Suggested Fix:
> LookupDiscovery should restore the security context (that it snap shots at instantiation time) before it adds tasks to TaskManager and WakeupManager. We need to ensure that existing operations within those tasks do not need elevated privilege. If they do, those operations may be performed in doPrivileged blocks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (RIVER-205) LookupDiscovery can give untrusted code
access to privileged threads
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone closed RIVER-205.
---------------------------------
> LookupDiscovery can give untrusted code access to privileged threads
> --------------------------------------------------------------------
>
> Key: RIVER-205
> URL: https://issues.apache.org/jira/browse/RIVER-205
> Project: River
> Issue Type: Bug
> Security Level: Security risk, visible to anyone(Issues identified as security risk but for which a patch is available)
> Components: net_jini_discovery
> Reporter: Ron Mann
> Assignee: Thomas Vinod Johnson
> Priority: Minor
> Fix For: AR2
>
> Attachments: RIVER-205-215.patch
>
>
> Bugtraq ID [6357961|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6357961]
> LookupDiscovery uses a TaskManager and WakeupManager instance which it may retrieve from a Configuration object that is passed to it at construction time. Some tasks that it generates using these utilities (DecodeAnnouncementTask, UnicastDiscoveryTask) are done within a thread with raised privileges. If the TaskManager and WakeupManager needs to spawn threads to dispatch the task, they will be spawned with the same security context as the privileged thread. Untrusted code can construct a LookupDiscovery instance with a Configuration object that returns TaskManager and WakeupManager instances that it has a handle to. It can then add new tasks (using say dynamic proxy or other trusted code) to its TaskManager and WakeupManager instances, which get executed with the security context of the privileged LookupDiscovery thread.
> Also note that the LookupDiscovery thread which generates the tasks retains the DomainCombiner that was present at the time of instantiation, so there is the theoretical possibility of exploiting, say the JAAS Subject if the combiner were a SubjectDomainCombiner.
> Suggested Fix:
> LookupDiscovery should restore the security context (that it snap shots at instantiation time) before it adds tasks to TaskManager and WakeupManager. We need to ensure that existing operations within those tasks do not need elevated privilege. If they do, those operations may be performed in doPrivileged blocks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (RIVER-205) LookupDiscovery can give untrusted
code access to privileged threads
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Vinod Johnson reopened RIVER-205:
----------------------------------------
Shouldn't have 'resolved', just set the Fix version to AR2.
> LookupDiscovery can give untrusted code access to privileged threads
> --------------------------------------------------------------------
>
> Key: RIVER-205
> URL: https://issues.apache.org/jira/browse/RIVER-205
> Project: River
> Issue Type: Bug
> Components: net_jini_discovery
> Reporter: Ron Mann
> Assignee: Thomas Vinod Johnson
> Priority: Minor
> Fix For: AR2
>
>
> Bugtraq ID [6357961|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6357961]
> LookupDiscovery uses a TaskManager and WakeupManager instance which it may retrieve from a Configuration object that is passed to it at construction time. Some tasks that it generates using these utilities (DecodeAnnouncementTask, UnicastDiscoveryTask) are done within a thread with raised privileges. If the TaskManager and WakeupManager needs to spawn threads to dispatch the task, they will be spawned with the same security context as the privileged thread. Untrusted code can construct a LookupDiscovery instance with a Configuration object that returns TaskManager and WakeupManager instances that it has a handle to. It can then add new tasks (using say dynamic proxy or other trusted code) to its TaskManager and WakeupManager instances, which get executed with the security context of the privileged LookupDiscovery thread.
> Also note that the LookupDiscovery thread which generates the tasks retains the DomainCombiner that was present at the time of instantiation, so there is the theoretical possibility of exploiting, say the JAAS Subject if the combiner were a SubjectDomainCombiner.
> Suggested Fix:
> LookupDiscovery should restore the security context (that it snap shots at instantiation time) before it adds tasks to TaskManager and WakeupManager. We need to ensure that existing operations within those tasks do not need elevated privilege. If they do, those operations may be performed in doPrivileged blocks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (RIVER-205) LookupDiscovery can give untrusted
code access to privileged threads
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on RIVER-205 started by Thomas Vinod Johnson.
> LookupDiscovery can give untrusted code access to privileged threads
> --------------------------------------------------------------------
>
> Key: RIVER-205
> URL: https://issues.apache.org/jira/browse/RIVER-205
> Project: River
> Issue Type: Bug
> Security Level: Security risk, visible to anyone(Issues identified as security risk but for which a patch is available)
> Components: net_jini_discovery
> Reporter: Ron Mann
> Assignee: Thomas Vinod Johnson
> Priority: Minor
> Fix For: AR2
>
>
> Bugtraq ID [6357961|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6357961]
> LookupDiscovery uses a TaskManager and WakeupManager instance which it may retrieve from a Configuration object that is passed to it at construction time. Some tasks that it generates using these utilities (DecodeAnnouncementTask, UnicastDiscoveryTask) are done within a thread with raised privileges. If the TaskManager and WakeupManager needs to spawn threads to dispatch the task, they will be spawned with the same security context as the privileged thread. Untrusted code can construct a LookupDiscovery instance with a Configuration object that returns TaskManager and WakeupManager instances that it has a handle to. It can then add new tasks (using say dynamic proxy or other trusted code) to its TaskManager and WakeupManager instances, which get executed with the security context of the privileged LookupDiscovery thread.
> Also note that the LookupDiscovery thread which generates the tasks retains the DomainCombiner that was present at the time of instantiation, so there is the theoretical possibility of exploiting, say the JAAS Subject if the combiner were a SubjectDomainCombiner.
> Suggested Fix:
> LookupDiscovery should restore the security context (that it snap shots at instantiation time) before it adds tasks to TaskManager and WakeupManager. We need to ensure that existing operations within those tasks do not need elevated privilege. If they do, those operations may be performed in doPrivileged blocks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (RIVER-205) LookupDiscovery can give untrusted
code access to privileged threads
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Vinod Johnson reassigned RIVER-205:
------------------------------------------
Assignee: Thomas Vinod Johnson
> LookupDiscovery can give untrusted code access to privileged threads
> --------------------------------------------------------------------
>
> Key: RIVER-205
> URL: https://issues.apache.org/jira/browse/RIVER-205
> Project: River
> Issue Type: Bug
> Components: net_jini_discovery
> Reporter: Ron Mann
> Assignee: Thomas Vinod Johnson
> Priority: Minor
> Fix For: AR2
>
>
> Bugtraq ID [6357961|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6357961]
> LookupDiscovery uses a TaskManager and WakeupManager instance which it may retrieve from a Configuration object that is passed to it at construction time. Some tasks that it generates using these utilities (DecodeAnnouncementTask, UnicastDiscoveryTask) are done within a thread with raised privileges. If the TaskManager and WakeupManager needs to spawn threads to dispatch the task, they will be spawned with the same security context as the privileged thread. Untrusted code can construct a LookupDiscovery instance with a Configuration object that returns TaskManager and WakeupManager instances that it has a handle to. It can then add new tasks (using say dynamic proxy or other trusted code) to its TaskManager and WakeupManager instances, which get executed with the security context of the privileged LookupDiscovery thread.
> Also note that the LookupDiscovery thread which generates the tasks retains the DomainCombiner that was present at the time of instantiation, so there is the theoretical possibility of exploiting, say the JAAS Subject if the combiner were a SubjectDomainCombiner.
> Suggested Fix:
> LookupDiscovery should restore the security context (that it snap shots at instantiation time) before it adds tasks to TaskManager and WakeupManager. We need to ensure that existing operations within those tasks do not need elevated privilege. If they do, those operations may be performed in doPrivileged blocks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-205) LookupDiscovery can give untrusted code
access to privileged threads
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Vinod Johnson updated RIVER-205:
---------------------------------------
Attachment: RIVER-205-215.patch
This patch also contains the trivial fix for RIVER-215 (see hunk @@ -1199,7 +1199,6 @@)
> LookupDiscovery can give untrusted code access to privileged threads
> --------------------------------------------------------------------
>
> Key: RIVER-205
> URL: https://issues.apache.org/jira/browse/RIVER-205
> Project: River
> Issue Type: Bug
> Security Level: Security risk, visible to anyone(Issues identified as security risk but for which a patch is available)
> Components: net_jini_discovery
> Reporter: Ron Mann
> Assignee: Thomas Vinod Johnson
> Priority: Minor
> Fix For: AR2
>
> Attachments: RIVER-205-215.patch
>
>
> Bugtraq ID [6357961|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6357961]
> LookupDiscovery uses a TaskManager and WakeupManager instance which it may retrieve from a Configuration object that is passed to it at construction time. Some tasks that it generates using these utilities (DecodeAnnouncementTask, UnicastDiscoveryTask) are done within a thread with raised privileges. If the TaskManager and WakeupManager needs to spawn threads to dispatch the task, they will be spawned with the same security context as the privileged thread. Untrusted code can construct a LookupDiscovery instance with a Configuration object that returns TaskManager and WakeupManager instances that it has a handle to. It can then add new tasks (using say dynamic proxy or other trusted code) to its TaskManager and WakeupManager instances, which get executed with the security context of the privileged LookupDiscovery thread.
> Also note that the LookupDiscovery thread which generates the tasks retains the DomainCombiner that was present at the time of instantiation, so there is the theoretical possibility of exploiting, say the JAAS Subject if the combiner were a SubjectDomainCombiner.
> Suggested Fix:
> LookupDiscovery should restore the security context (that it snap shots at instantiation time) before it adds tasks to TaskManager and WakeupManager. We need to ensure that existing operations within those tasks do not need elevated privilege. If they do, those operations may be performed in doPrivileged blocks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (RIVER-205) LookupDiscovery can give untrusted
code access to privileged threads
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Vinod Johnson resolved RIVER-205.
----------------------------------------
Resolution: Fixed
Assuming lack of comment means the change is OK.
> LookupDiscovery can give untrusted code access to privileged threads
> --------------------------------------------------------------------
>
> Key: RIVER-205
> URL: https://issues.apache.org/jira/browse/RIVER-205
> Project: River
> Issue Type: Bug
> Security Level: Security risk, visible to anyone(Issues identified as security risk but for which a patch is available)
> Components: net_jini_discovery
> Reporter: Ron Mann
> Assignee: Thomas Vinod Johnson
> Priority: Minor
> Fix For: AR2
>
> Attachments: RIVER-205-215.patch
>
>
> Bugtraq ID [6357961|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6357961]
> LookupDiscovery uses a TaskManager and WakeupManager instance which it may retrieve from a Configuration object that is passed to it at construction time. Some tasks that it generates using these utilities (DecodeAnnouncementTask, UnicastDiscoveryTask) are done within a thread with raised privileges. If the TaskManager and WakeupManager needs to spawn threads to dispatch the task, they will be spawned with the same security context as the privileged thread. Untrusted code can construct a LookupDiscovery instance with a Configuration object that returns TaskManager and WakeupManager instances that it has a handle to. It can then add new tasks (using say dynamic proxy or other trusted code) to its TaskManager and WakeupManager instances, which get executed with the security context of the privileged LookupDiscovery thread.
> Also note that the LookupDiscovery thread which generates the tasks retains the DomainCombiner that was present at the time of instantiation, so there is the theoretical possibility of exploiting, say the JAAS Subject if the combiner were a SubjectDomainCombiner.
> Suggested Fix:
> LookupDiscovery should restore the security context (that it snap shots at instantiation time) before it adds tasks to TaskManager and WakeupManager. We need to ensure that existing operations within those tasks do not need elevated privilege. If they do, those operations may be performed in doPrivileged blocks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (RIVER-205) LookupDiscovery can give untrusted
code access to privileged threads
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Vinod Johnson resolved RIVER-205.
----------------------------------------
Resolution: Fixed
Fix Version/s: AR2
> LookupDiscovery can give untrusted code access to privileged threads
> --------------------------------------------------------------------
>
> Key: RIVER-205
> URL: https://issues.apache.org/jira/browse/RIVER-205
> Project: River
> Issue Type: Bug
> Components: net_jini_discovery
> Reporter: Ron Mann
> Assignee: Thomas Vinod Johnson
> Priority: Minor
> Fix For: AR2
>
>
> Bugtraq ID [6357961|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6357961]
> LookupDiscovery uses a TaskManager and WakeupManager instance which it may retrieve from a Configuration object that is passed to it at construction time. Some tasks that it generates using these utilities (DecodeAnnouncementTask, UnicastDiscoveryTask) are done within a thread with raised privileges. If the TaskManager and WakeupManager needs to spawn threads to dispatch the task, they will be spawned with the same security context as the privileged thread. Untrusted code can construct a LookupDiscovery instance with a Configuration object that returns TaskManager and WakeupManager instances that it has a handle to. It can then add new tasks (using say dynamic proxy or other trusted code) to its TaskManager and WakeupManager instances, which get executed with the security context of the privileged LookupDiscovery thread.
> Also note that the LookupDiscovery thread which generates the tasks retains the DomainCombiner that was present at the time of instantiation, so there is the theoretical possibility of exploiting, say the JAAS Subject if the combiner were a SubjectDomainCombiner.
> Suggested Fix:
> LookupDiscovery should restore the security context (that it snap shots at instantiation time) before it adds tasks to TaskManager and WakeupManager. We need to ensure that existing operations within those tasks do not need elevated privilege. If they do, those operations may be performed in doPrivileged blocks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.