[
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.
