Software Configuration Management (SCM) Security
By David A. Wheeler
Security and Aegis |
By Peter Miller
|Software development is often supported by specialized programs called "Software Configuration Management" (SCM) tools. SCM tools often control who can read and modify the source code of a program, keep history information (so that people can find out what changed between versions, and who changed them), and generally help developers work together to improve a program under development.||The left column is David Wheeler's essay about software configuration management and security. This column contains a running commentary on how Aegis achieves many of the desirable security goals David outlines.|
|Problem is, the people who develop SCM tools often don't think about what kind of security requirements they need to support. This mini-paper describes briefly the kinds of security requirements an SCM tool should support. Not every project may need everything, but it's easy to not notice some important requirements if you don't think about them. There are two basic types of SCM tools, "centralized" and "distributed"; the basic security needs are the same, but how these needs can be handled are different between the two different types. I'm primarily concentrating on basic SCM tools (like CVS, Subversion, GNU Arch, Bitkeeper, Perforce, and so on). Clearly related tools include build tools, automated (regression) test tools, bug tracking tools, static analysis tools, process automation tools, software development tools (such as editors, compilers, and IDEs), and so on.||
Aegis was designed from the very beginning with security
mind. Indeed, for some time it provided rather more
than open source developers needed or wanted.
Recent developments have provided additional configuration options to allow a more relaxed security profile than is provided by default.
|The Security Basics||The Security Basics|
|Fundamentally, there are some basic (potential) security requirements that any system needs to consider. These are:||Here are the security features that Aegis is able to provide:|
| || |
| || |
| || |
| || |
| || |
| || |
|An SCM has several assets to protect. It needs to protect "current" versions of software, but it must do much more. It needs to make sure that it can recall any previous version of software, correctly, as well as the audit trail of exactly who made which change and when. In particular, an SCM has to keep the history immutable - once a change is made, it needs to stay recorded. You can undo the change, but the undoing needs to be recorded separately. Very old history may need to be removed and archived, but that's different than simply allowing history to be deleted.||
Aegis has complete control of the history of a project
associated meta-data. All change sets are preserved
Most aspects of Aegis' meta-data are immutable. Only project administrators may change the description of a change once it has been committed to the repository (developers are notoriously bad at accurately describing their changes); project administrators cannot alter any information about the file histories or the various users and time stamps the change set has accrued.
|The Threats||The Threats|
|Okay, so what are the potential threats? These vary, and not all projects will worry about all threats. Nevertheless, it's easier to provide a list of threats and the counter-measures an SCM should support.||Aegis was designed from the ground up to cope with a number of threats.|
|Individual projects may choose to not employ a given counter-measure, since they may decide that's not a threat for them. For example, open source software (OSS) projects may decide that there's no "threat" of unauthorized reading of software, since the code is open to reading by all. However, that may not always be true - many OSS projects hide changes that reveal security vulnerabilities until the new version is ready for deployment. Thus, it's difficult to make simple statements like "projects of type X never need to worry about threat Y". Instead, it's simpler to list some potential threats, and then projects can decide which ones apply to them (and configure their SCM system to counter them).||
Aegis provides the ability to customize many aspects of
process which change sets travel through to be included
project repository. |
The default configuration is medium paranoid. It is possible to increase that to extremely paranoid (or extremely officious, depending on your perspective), or weaken it to merely be helpful.
|Outsiders without privileges||Outsiders without privileges|
|An outsider (not a developer or administrator) may try to read or modify assets (software source code or history information) when they're not authorized to do so. SCM systems should support authorization (like login systems), and support a definition of what unauthorized users can do. An SCM system should support configurations that allow anonymous reading of a project and/or its history, since there are many cases where that's useful. However, SCMs should also support forbidding anonymous read access. That's even true for OSS projects, since as I noted above, sometimes OSS projects want to hide security fixes until they're ready for deployment.||
By using the UNIX groups facility (see group(5)
more information) it is possible to limit the read access
project to members of a single group. |
However, this leaks the existence of the project. By using the AEGIS_PATH environment variable, telling Aegis where to look for projects, it is also possible to conceal the existence of a project.
Aegis has separate ACLs to developers, reviewers and integrators, limiting the number of users who can modify the project - but even then, they must follow the process.
|Normally unauthorized users shouldn't be allowed to modify a source repository, so an SCM should support that (and should make that the default). In rare cases, it's possible to imagine that even this constraint isn't true, especially if the SCM tool is designed to be used for resources other than source code. Most Wiki systems such as Wikipedia allow anonymous changes; they work instead by protecting the history of changes so that everyone will know exactly what's changed, instead of preventing writing of the primary data. Such approaches are rare for software code; for example, the Wikipedia software itself (as stored in its trusted repository) can only be changed by a few privileged developers. However, it is conceivable that software documentation and code would be maintained by the same SCM software, and perhaps a few projects would allow anyone to update the documentation as long as all changes were tracked and could be easily reversed.||
Aegis is very strict about which users are authorized to
and modify change sets. If you are not in the
you may not perform the action. |
It would be possible (although this isn't the case at present) to add code to Aegis to allow "anybody" to be a change set developer. It is probably most undesirable to allow "anybody" to be a code reviewer or integrator.
Aegis breaks the traditional "commit" step into several pieces. Large project are able to be configured to require a user other than the developer to perform the code review step (this is the default). Thus, it is safe for naive developers to modify any source file they like, but they have to get it past a code reviewer before it will appear in the repository. There are facilities in Aegis to require specific code reviewers for specific portions of the code.
|The underlying identification and authentication system (the login system) can use intrusion detection systems to detect likely attempts to forge privileges (e.g., by detecting password guessing attacks, or detecting improbable locations of a login). The underlying login system could also support enabling limits (e.g., delays after X login attempts, or only permitting logins from certain Internet Protocol address ranges for certain developers). However, these mechanisms need to not create a denial-of-service attack; otherwise, an attacker might try to forge logins not to actually log in, but to prevent legitimate users from doing so.||Aegis relies on the host operating system for authentication services. The extent to which the host operating system can detect attacks is the extent to which project managed by Aegis are safe or at risk.|
|Non-malicious developers with privileges||Non-malicious developers with privileges|
|An SCM system should support protected logins (e.g., if it uses passwords, it should protect passwords during transit and while they're stored). Once users are authenticated, an SCM system should be able to limit what users can do based on the authorization that's implied.||Aegis relies on the host operating system for authentication services. Once authenticated, individual users may be authorized to perform different actions, based on simple ACLs. Each project has separate ACLs for the various roles.|
|SCM systems could usefully limit reading to particular projects, say. Limiting reading of specific files inside a project can be useful, but it often isn't as useful inside a branch developers must access because developers often need the entire set of files to develop (e.g., to recompile something). But limiting who can read changes in certain branches could be vital for some projects. For example, it is common for security vulnerabilities to be reported to a smaller group of people than the entire development staff, and for the patch to be developed by specially trusted developers without full knowledge of all developers. This is particularly true for open source software projects, but it's also sometimes true for other projects. This kind of functionality can also be important for projects such as military projects with varying degrees of confidentiality; most of the program may be "unclassified", but with a poor or stubbed algorithm; there may be a better classified algorithm, but it will need to be maintained separately. Ideally, the SCM should be trustworthy enough to protect that data, though in practice such trust is rarely granted; an SCM should instead gracefully handle importing the "unclassified" version and automatically merging the "classified" data on equipment trusted to do so.||Aegis does not provide this facility on a per-file or per-directory bases. It is possible to vary staff roles per branch, but this does not include read access.|
|Limiting writing of specific files inside a project can be much more useful, since in some projects some users "own" certain files. In many situations it doesn't make sense either, but an SCM system should still support limiting which developers can make which changes.||Aegis breaks the traditional "commit" step into several pieces. Large project are able to be configured to require a user other than the developer to perform the code review step (this is the default). Thus, it is safe for naive developers to modify any source file they like, but they have to get it past a code reviewer before it will appear in the repository. There are facilities in Aegis to require specific code reviewers for specific portions of the code.|
|Malicious developers with privileges (and attackers with their credentials)||Malicious developers with privileges (and attackers with their credentials)|
|An area often forgotten by SCM systems is handling malicious developers. You know, the ones who intentionally insert Trojan horses into programs. Denying they exist doesn't help; they do exist. And even if they didn't, there's no easy way for an SCM to tell the difference between an authorized malicious developer and an attacker who's acquired an authorized developer's credentials.||Never ascribe to malice what you can ascribe to stupidity. Developers (particularly, tired and overworked developers) frequently do stupid things. If you can think of a malicious way to subvert a system, some user will do it by accident and not know he did it.|
|A malicious developer might even try to make it appear that some other developer has done a malicious deed (or at least make it untraceable). They can use their existing privileges to try to gain more privileges. A malicious developer might try to modify the data used by a CM system so that it looks like someone else made the change (e.g., provide someone else's name in a ChangeLog entry). A malicious developer might try to modify a CM "hook" to make it appear that some other developer has inserted malicious code (perhaps to avoid blame or frame the other developer). A malicious developer might modify the build process, e.g., so that when another developer builds the software, the build system attempts to steal credentials or harm the developer.||Aegis trusts the operating system to authenticate users. Once authenticated, users do not have write access to the meta-data or history files of any change set. The vast majority of "hooks" are in files controlled by Aegis' process; to maliciously change one requires a conspiracy of developer, reviewer and integrator.|
|Since developers have the privileges to read and change data, malicious developers (and attackers with their credentials) are harder to counter. But there are counter-measures that can be used against them. Here are some reasonable measures:||While developers have the privileges to read source files, and the ability to change them in their private work areas, they are unable (by themselves) to modify file histories or change set meta-data. Here are some of Aegis' counter-measures:|
| || |
| || |
On April 11, 2004, Dr. Carsten Bormann from the
Bremen sent me an email about a specialized attack that
terms the "encumbrance pollution attack". In an
pollution attack, the attacker inserts material that
legally included. To understand it, first imagine an SCM
perfectly indestructible history. The attacker steals
credentials, or is himself a malicious developer, and
a change that contains some encumbered material.
material is simply material which cannot be legally
Examples include child pornography, slanderous/libelous
statements, or code which has copyright or patent
This could be very advantageous, for example, a company
hire a malicious developer to insert that company's code
a competing product, and then sue the competitor for
infringement, knowing that their SCM system "can't" undo
problem. Or a lazy programmer might copy code that they
right to copy (this is rare in open source software
because every line of code and who provided it is a
public record, but it proprietary projects do have this
Any SCM can record a change that essentially undoes a
change, but if the history is indestructible and viewable
all, then you can't get rid of the history. This makes
SCM archive irrevocably encumbered. This can especially
problem if the SCM is indestructibly recording proposals
outsiders! An SCM system could be designed so that a
privilege allowed someone to completely deletion the
data of illegal changes, of course. However, if there
special privileges to delete history data, it might be
to misuse those privileges to cause other problems.
One mechanism for dealing with an encumbrance pollution attack is to allow specially-privileged accounts to "mask" history elements; i.e., preventing access to certain material by normal developers so that it's no longer available, so that the material isn't included in later versions (essentially it works like an "undo" against that change). However, a "mask" would still record the event in some way so that it would be possible to prove that the event occurred at a later time. Perhaps the system could record a hash of the encumbered change, allowing the encumbered material to be removed from the normal repository yet proving that, at one time, the material was included. A "masking" should include a cryptographic signature of whoever did the masking. This mechanism in particular requires careful design, because the mechanism should be design so that it doesn't permit other attacks.
|Most SCM systems have multiple components, say, a client and server. Even GNU arch, which can use a simple secure FTP server as a shared repository, has a possible server (the FTP server). Clients and servers should resist attack from other potentially subverted components, including loss of SCM data.||The Aegis support for geographically distributed development includes the whole process for each change set. This means that synchronizing with a remote repository is not a back door to your repository.|
|Repository attacks||Repository attacks|
|Many repositories have themselves undergone attack, including the Linux CVS mirror, Savannah, Debian, and Microsoft (attackers have acquired, at least twice, significant portions of Windows' code). Thus, a good SCM should be able to resist attack, even when the repository it's running on subverted (through malicious administrators of a repository, attacker root control over a repository, and so on). This isn't just limited to centralized SCM systems; distributed SCM systems still have the problem that an attacker may take over the system used to distribute someone's changes.||Aegis depends on the host operating system for limiting access to the repository history and meta-data. Aegis has no defense against a compromised root account making direct access to the history and meta-data, without executing Aegis.|
|An SCM should be able to prevent read access, even if the repository is attacked. The obvious way to do this is by using encrypted archives. But there are many variations on this theme, primarily in where the key(s) are stored for decryption. If the real problem is just to make sure that backup media or transfer disks aren't easily read, the key could simply be stored on a separate (more protected) media. The archive keys might only be stored in RAM, and required on boot up; this is more annoying for boot up, and an attacker is likely to be able to acquire the data anyway. The repository might not normally have the keys necessary to decrypt the archive contents at all; it could require the developer to provide those keys, which it uses and then destroys. This is harder to attack, but a determined adversary could subvert the repository program (or memory) and get the key. Another alternative is to arrange for the repository to not have the keys necessary to decrypt the archive contents at any time. In this case, developers must somehow be provided with the keys necessary to do the decryption, and essentially the repository doesn't really "know" the contents of the files it's managing!||
Aegis has no support for encrypted meta-data, and limited
support for encrypting history files. Add to this the
that a change set must be approved by a code reviewer,
not have the developer's keys. |
Aegis was designed long before this concept evolved. Its meta-data is not in a form which allows it to be placed in an immutable file, with each update to the meta-data being placed in another immutable file.
Portions of the meta-data are immutable, but because it is stored in the same file as some changeable data (for example, where the change set is in the process) digital signatures are problematic.
It is possible to encrypt change sets when they are in transit between repositories, using OpenPGP or GnuPG.
|Preventing write access when an attacker controls a repository is a difficult challenge, especially since you still want to permit legitimate changes by normal developers. Since the attacker can modify arbitrary files in this case, the goal is to be able to quickly detect any such changes:||Aegis was not designed to do this.|
| || |
|Related Work||Related Work|
|[This section omitted. See the original paper.]||Omitted.|
|All of this can't prevent all attacks. But such an SCM system can make the attacks much harder to perform, more likely to be detected, and make detection much more rapid. Here are some examples:||Aegis was designed to prevent several classes of attacks. The process used by Aegis is designed to make defective change sets (including malicious change sets) more likely to be detected. Here are some examples:|
| || |
|It's my hope that SCM systems will have more of these capabilities in the future.||Aegis has been capable of of preventing many of the described attacks for over a decade. It is a mature SCM with users including medical equipment vendors with strict FDA compliance requirements.|
|The beautiful graphics on this web site are by Grégory Delattre.||Return to the Aegis home page.|