This site best when viewed with a modern standards-compliant browser. We recommend Firefox Get Firefox!.

Linux-HA project logo
Providing Open Source High-Availability Software for Linux and other OSes since 1999.

USA Flag UK Flag

Japanese Flag

Homepage

About Us

Contact Us

Legal Info

How To Contribute

Security Issues

This web page is no longer maintained. Information presented here exists only to avoid breaking historical links.
The Project stays maintained, and lives on: see the Linux-HA Reference Documentation.
To get rid of this notice, you may want to browse the old wiki instead.

1 February 2010 Hearbeat 3.0.2 released see the Release Notes

18 January 2009 Pacemaker 1.0.7 released see the Release Notes

16 November 2009 LINBIT new Heartbeat Steward see the Announcement

Last site update:
2017-12-17 09:35:28

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.

Background

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:

  1. Senders can be restricted to only authorized senders by an externally administered (or automatically computed) list.
  2. Recipients are provided provided authentic identification (authentication) information, and then performs their own authorization checks - depending on the nature of the actions they perform.
  3. Information providing and consuming can be restricted generally for the communcations entity under consideration. For example, senders could be restricted, or recipients could be restricted. When restricting senders generally, this also can be used to prevent information leaks.

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.

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

Checkpoint API

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:

  • A correctly operating checkpoint service will require that all processing attaching to a checkpoint as either master or slave shall have the same credentials (effective user id and effective group id) as the original creator of the checkpoint. Processes which attempt to connect with different credentials will fail with an appropriate error code.

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.

Event API

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.

Messaging API

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.


CategoryIssue, CategoryOpenIssue