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

Reply via email to