[m-rev.] for review: compare/unify tuples and handle var arity type-infos in rtti_implementatation

[Fergus Henderson]

On 28-Nov-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> Branches: main
> 
> Implement compare and unify for tuples and handle variable arity
> type_infos in rtti_implementatation.
...
> +:- pred unify_tuple_pos(int::in, int::in,
> +		type_info::in, T::in, T::in) is semidet.
> +
> +unify_tuple_pos(Loc, TupleArity, TypeInfo, TermA, TermB) :-
> +	( Loc > TupleArity ->
> +		true
> +	;
> +		ArgTypeInfo = TypeInfo ^ var_arity_type_info_index(Loc),
> +
> +		SubTermA = get_subterm(ArgTypeInfo, TermA, Loc, 0),
> +		SubTermB = get_subterm(ArgTypeInfo, TermB, Loc, 0),
> +
> +		generic_unify(SubTermA, unsafe_cast(SubTermB)),
> +
> +		unify_tuple_pos(Loc + 1, TupleArity, TypeInfo, TermA, TermB)
> +	).

Reading this code made me think of a potential security issue here.
If this module is trusted with reflection primitives
(which it needs to be for get_subterm etc. to work),
but it is compiled with intermodule optimization enabled
(which is currently the default for .NET since it is required
to avoid the problem with abstract equivalence types),
then unify_tuple_pos might get exported.
Untrusted malicious application code might call unify_tuple_pos
with arguments which are not tuples, and which have different functors;
the call to unsafe_cast might end up using the wrong type.
Currently that's probably not a problem, since for .NET the
"unsafe_cast" here will end up invoking a dynamically checked cast
in the end.  But there might be similar issues lurking elsewhere
in the Mercury standard library implementation.

I think the only solution for now is to document that in the current
implementation, the Mercury standard library implementation is not
secure (or at least that it might not be secure), and that it should
not be used in any context where it could get invoked by untrusted code.

Apart from that (which is really a more general problem, not something
specific to this diff) the diff looks fine, although I agree with
Ralph's comment about the (func(...) = Y :- Y = ...) lambda expression --
it should just be written as (func(...) = ...).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------