The problem with the Signal service implementation.

[ivan.bludov]

Hi,
we have an idea that can flow Genode security system, correct me if we 
are wrong. It also can hack signal service. The ideas of  
kernel-protected capabilities are interesting, but we think the 
implementation of Genode capabilities has some features. Although we 
consider only Genode on Fiasco.OC. The Genode::Native_capability could 
be considered as two values : the badge(the local_name) and the dst 
("the pointer" to the kernel's object). Thus we can use simple structure 
Native_capability(valid_dst, any_number_as_badge) as 
Signal_context_capability (using static_cap_cast), where valid_dst could 
be env()->ram_session_cap().dst(). Then we can pass this obtained 
capability as parameter to the Signal_session_client::submit() RPC and 
call any arbitrary signal_contexts. Furthermore as we known the 
env()->ram_session_cap().dst() points to the Genode main entrypoint then 
we can create dummy_client of 
Native_capability(env()->ram_session_cap().dst(), any_number_as_badge) 
that will call any_rpc. And we think these activities will crush all 
Genode system.

addr_t genode_ep = env()->ram_session_cap().dst();
for(long badge = 0;; badge++)
{
     Dummy_client client(Native_capability(genode_ep, badge));
     client.call_dummy_rpc_1();
     ...
     client.call_dummy_rpc_k(); // say k>10
}

May be we don't understand Genode and Fiasco.OC completely and you can 
explain this behaviour.

Best,
Ivan Bludov.

On 10/02/12 15:49, Norman Feske wrote:
> Hello again,
>
>> Unfortunately, a real solution for the problem is not as simple as that.
>> You are right that the badge is used as a key for looking up the
>> signal-context within core. But by passing the badge as plain data
>> instead of a capability, the referred signal context could be forged by
>> the client. This way, a malicious client would be able to submit signals
>> to all signal receivers in the system. The use of capabilities prevents
>> that.
> replying to myself now... .-)
>
> I just had the following idea for a fix: When unmarshalling a capability
> (in 'Ipc_istream::_unmarshal_capability') we need to distinguish the
> case of having got a new capability from the case of getting a reference
> to an already known capability. We receive the 'unique_id' as hint (it
> is just plain data - hence untrusted information) about which capability
> selector the argument refers to. Using this 'unique_id', we could look
> up the core-local capability selector at the cap-selector allocator.
> Currently, we do not store the unique ID at this allocator. So we would
> need to add a way to register the unique IDs that correspond to cap
> selectors and a way to perform a lookup from cap selector to unique ID.
>
> If the lookup fails, we know that we received a new capability (for the
> signal service, this should never happen because all signal contexts are
> allocated at core). If the lookup succeeds, we obtained a capability
> selector that can now be tested via the kernel's 'l4_task_cap_equal'
> kernel function. If the just received capability selector refers to the
> same kernel capability as the looked up selector, we just keep using the
> one returned by the lookup and do not allocate a new selector.
>
> Of course there is still the other part of the problem: keeping a
> reference count for each capability selector (similarly to how shared
> pointers work). But the fix above should actually solve the
> capability-selector leak in the packet-stream case without introducing a
> security problem.
>
> Cheers
> Norman
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main