AIS Local Security Holes
Summary: Various of the AIS APIs have several obvious local security holes in them.
Created by: AlanRobertson
This issue is to point out the nature of the problems associated with not identifying local senders. Without this, there is no security against attackers escalating their privileges to obtain unauthorized privileges. In some cases, this means being able to become root, and can result in another exploit being escalated into a root exploit.
The second area of concern for these APIs is that of information leaks. Since these APIs are general in nature, it is reasonable to assume that certain senders might be sending information which is sensistive in nature, and harm may come from leaking this information to unauthorized parties.
This issue does not discuss the communications issues which arise when more than one computer is considered.
The fundamental assumption of most of the AIS APIs is that information which is received by any of the various reception calls is intended to be acted on.
That is, the point of recieving some message is that it is expected in most cases that some kind of action should or must be taken as a result of receiving that message or information.
An attacker who knows what action will result from the receipt of a certain kind of information can then use that knowledge to cause that action to be taken by the recipient, by sending the right information to the recipient.
Fundamentally, this means restricting messages to be acted on to only come from authorized senders.
In addition, it can be assumed that some users of these APIs might be transmitting information which is sensitive in nature, and it is desired that it not easily available to unauthorized parties.
There are basically three techniques to deal with these issues:
When method (1) is applicable, this typically does not involve changes to the calling sequences in the API, only to the specification and the semantics correct implementations.
In general, methods (2) and (3) requires that the APIs be modified.
These methods are applicable separately or together in various combinations according to the needs of the API.
The membership API is simple, because only the system membership service should be a provider of information, and the only information provided is not sensitive in nature.
As a result, it is sufficient to have the specification require that correct implementations provide appropriate checks to ensure that the membership information is from the system membership information. No changes to APIs are needed.
It is highly probable that method (1) can be used to solve the problem quite easily - depending on how it is expected to be used.
A method (1) proposal follows:
This would require all process operating on a particular checkpoint be equivalent. Since it is expected that a slave can be promoted to master and take over the service which goes with this checkpoint, this is quite likely a sensible and reasonable restriction. Since each process is then equivalent, there is no leaking to unauthorized parties possible.
If it is not, then the creator of the checkpoint and those who join the checkpoint will have to be able to restrict what credentials they will join with. Note that both the creator and the subsequent slaves who join must each be able to restrict who they will communicate with, should this option be deemed necessary.
It is the purpose of the event API to be able to have diverse groups of processes provide messages which are consumed by a diverse (and possibly non-overlapping) group of processes. This API is subject both to privilege escalation and information leak issues.
As a result, only method (2) will generally provide sufficient protection to this API, since the recipients may need to restrict who they "believe" for a particular type of message, in order to avoid an escalation of privileges attack. This is general, but is not sufficient to prevent information leaks.
However, these can be combined with a method (3) API where the credentials of processes which can receive messages is restricted. Both of these two changes are necessary for this API.
If desired, a new API which would allow a given recipient can filter messages based on the credentials of the sender. This would eliminate the burden of checking the sender for some classes of applications.
The messaging API is the most general, and therefore the most difficult to protect. This API is subject to both escalation of privileges attacks, and information leaks.
When creating a messaging object, it is necessary to be able to restrict who can send messages using this object, and also who can receive them. Given the nature of this API, it is probable that each process that can receive will also need to transmit and vice versa.
This API will require both the use of technique (1) and technique (3).
To understand the full generality of why it needs to be able to authenticate each message sender individually and non-automatically, an example may be helpful.
Imagine a file server protocol - perhaps similar to NFS or SMB. In this case, each message coming from a client specifies a file handle or name, and an operation to be performed on the file. In this case, anyone can connect to the file server, but individual operations will be accepted or rejected based on the of the (sender-credentials, filename, operation) triple. It is easy to see that no general AIS authorization system can provide the granularity and flexibility which this kind of application needs.