Hi, my name is Andy Webber, I am an ethical hacker in Oracle's Global Product Security group. In recent years, one area I've been focusing on has been the security of passwords.
Through Oracle Software Security Assurance, Oracle aims to continuously provide better security to its customers. This program involves various activities throughout development including, for example, educating developers, reviewing designs, running through security check-lists, having the code analysed by tools, running tests, ethical hacking and independent analysis. Despite these various security checks and the best intention of the developers, which result in many defects being found and fixed, some security defects unfortunately still evade detection before product release and may require the issuance of fixes.
In today's blog entry, I'm going to talk about one particular class of defect whose severity is relatively minor compared to buffer overflows, but still significant especially with regards to a customer's ability to achieve compliance with various regulations: The use of passwords on the command line. The use of passwords on the command line is a relatively hard to detect class of security defect. In addition, it can exist in product code, documentation, sample scripts and other locations.
It is tempting, and indeed a common practice, to accept a password as a parameter on the command line for programs and scripts. However, on UNIX systems for example, it is possible for any user on the same host to view the command line of any other user's running processes, and sometime the environment variables too. There is therefore the possibility that, where one user has entered a command with a password or other secret as a command parameter or environment variable, another user can obtain the password or secret by looking into the environment. Clearly, this can have dramatic consequences! As a result, a common security advice to developers has been to not accept passwords and other secrets as command-line parameters or via environment variables.
Although Global Product Security has for a very long time given unequivocal recommendations on the matter, it is still the case that developers routinely implement this feature. There are many reasons for this behaviour, including expected usage as part of a script rather than directly by a human. In addition, compared to the very simple approach of putting them on the command line, it is difficult to securely pass passwords around between programs in a truly platform independent way.
The use of passwords on the command line is an issue that is not likely to be caught by design reviews (since it is an implementation detail). In some cases, it can be caught by testing, for example by using specific passwords/secrets; using the Linux Auditing System to capture details about every command invoked; and looking through the logs to see if the known password appears. This approach, however, can only detect the problem for the commands actually used during the testing, and only the way they were actually invoked during that testing. If different installation options are chosen, then maybe different commands are run or they are run in different ways, however this can only be detected by trying every possible permutation and combination, which is not always practical if at all possible.
When working on the Oracle Database 11g Release 1, we discovered new allies while addressing the issue of the use of passwords on the command line: the technical writers that produce and update the documentation.
By working with the writers, we were able to produce some specific advice for documenting the handling of passwords. This involved, where practical, converting examples to use a more secure approach (in many cases, where a password is required but not supplied, it will be prompted for interactively). And where there was no secure alternative, the writers raised bugs against the developers requiring them to provide such secure alternative. As a result, for example, in the 11g Release 1 documentation, you are unlikely to see "sqlplus SCOTT/TIGER", and far more likely to see a "Password:" prompt.
As a result of the technical writers' commitment to Oracle Software Security Assurance, we are experiencing the following benefits:
- Enhanced documentation: in all examples where it is practical to do so the documentation indicates where there is more secure and a less secure method of passing a password or secret;
- Better recommendations to customers: by making the secure variant more prominent in the documentation, it encourages customers to adopt it where they can. In addition, the documentation now provides specific guidance about how to use the more secure methods in scripts;
- Increased number of programs and utilities that offer a more secure variant.
Of course, where a piece of code has been released as part of a product, customers may expect it to be able to take a password on the command line and may have custom scripts that require it. In order to maintain compatibility with these use cases, the old functionality will be retained until it eventually becomes deprecated, so there is no need to immediately modify scripts that use the 'old' method. For example, SQL*Plus is likely to accept a password for a long time to come. But, in addition to being a good security practice, the availability of a more secure variant makes it easier to be compliant where policy or regulatory requirements require that passwords are not given on the command line.
There is another major benefit resulting from the involvement of the technical writers in the security assurance effort: If the documentation, training and samples make less use of the use of passwords to SQL*Plus, then, in time, it will fade from memory as new users become accustomed to using only the more secure method.
While we understood that Oracle Software Security Assurance was never just about the code, few of us expected documentation writers to be raising security bugs. I think that the writers' involvement yields an interesting lesson: technical writers in any organizations, whether writing for blogs, documentation, examples and when teaching or training, can lead by example. They should flag insecure examples or behaviors in the documentation and if they can't find a secure alternative to these issues; then they should be empowered to raise a support request on the affected product.
