Developing secure software

Getting started
Open source
Sandbox
Shared memory
Secondary storage
Trojans
Passphrase storage and encryption
Use Java
How to be sure a client is on the same machine as the server

Getting started

• Developers must protect their own systems carefully

• Test, test, test. Because paranoia is a virtue, test everything, even things that you don't think will matter.

  • Use static checkers such as Findbugs and PMD. When you disagree with their reports say why in the code.

  • Test dynamically using tools such as JUnit.

  • Automatic testing is essential, but no substitute for traditional Alpha and Beta testing.

  • Get peers who understand software security to review your code.

• Use Java

• See

  • Tools & Tips for auditing code

  • Security Specific Programming Errors

  • Secure Programming for Linux and Unix HOWTO

  • Lessons Learned in Implementing and Deploying Crypto Software

  • Java

    • Sun's Security Code Guidelines

    • Twelve rules for developing more secure Java code

    • Writing Secure Java Programs

  • How to find security holes

Open source

• "Security" software without source code isn't secure

• You can't do source code audits without source code

• Open source is no guarantee that it's trojan-free, but it definitely helps

Code must run well in a sandbox

• As a user, not as root. Nothing in Tiger requires root access, with the possible exception of Business Envelopes

• chroot

• Minimum permissions from MAC such as LIDS

Shared memory

• Some types

  • Static data

  • Stack

  • Heap

  • Command line

  • Pipe

  • Swap

  • Device buffers

    • Keyboard

    • Screen

    • Net interface

• Some of these memory types are not shared on some systems

• Patches to Kaffe could help with static data, stack and heap

• Command lines can be hidden, although that opens other vulnerabilities

• Pipes can be encrypted or avoided

• If we can, lock memory pages

  • On Linux you can't lock memory unless you're root. Can you do it at all on Windows?

  • Standard Java does not allow page locking, but it should be doable via JNI

  • Locking memory is less important than many believe, since it usually doesn't secure memory used by pipes, stacks, heaps, etc.

    • Stacks and heaps are easily locked under some OSes, but are usually still executable. There are solutions to secure stacks and heaps, but few security pros use them, much less ordinary users.

    • There isn't an accepted secure protocol for pipes. Designing one would be easy, but getting it adopted would not.

    • No good solutions are available for peripherals such as keyboard and screen, or their drivers. Communications channels between device drivers and apps using them could be secured by, e.g., a pipe protocol transporting XML.

Secondary storage

• Some types

  • Internal hard disk

  • Floppy

  • CDROM

  • CDRW

  • Net

  • External hard disk, flash, microdrive, etc.

    • USB

    • Firewire/IEEE 1394

    • PCMCIA

    • SCSI

• Don't just erase files. Wipe them. Use "shred" on *nix.

• Wipe free disk space regularly

  • Create temp file to fill space

  • Wipe it

• Remove removable media when not needed

• Don't make or keep unneeded copies

Trojans

• Run in as limited a sandbox as possible

• Sun source code is available, but neither libre nor gratis, so few will perform security audits on it

  • Consider Kaffe for the JVM and class libraries

  • Consider classpathx for java extensions

  • Rewrite or replace any Sun packages used

    • Javamail

      • Tiger JMail is a project to do this

    • Java Activation Framework

      • Tiger JMail and classpathx have a JAF

  • Fairly good decompilers exist for java, and might be at least a short term measure

• Actually do security audits

• Sign code

Passphrase storage

• Tiger is intended to be used. Security that isn't used might as well not exist.

• Ideal authentication requires something you have, know, and are. This is almost always overkill.

• Almost all mail clients store user names and passwords now anyway

• After several years, we know that the only mail client encryption packages that most people will routinely use are the ones that store the passphrase

• More secure, and less usable, options

  • Passphrases and keys on removable tokens. Should be a user option.

  • Require user to reenter passphrase every session. Passphrase kept only in memory. Should be a user option.

  • Secure coprocessor. Many types available, from a computer connected via floppy net or the parallel port without a network stack, to smartcards. An option in later versions.

• Whether and how long a passphrase is stored is a user option

• Carefully watch developments in areas such as blinded biometrics

• Security experts who react in horror when ease of use wins over security should remember

  • Unused security is useless at best, and may provide a false sense of security

  • Sometimes the goal is "as private as a paper envelope"

  • We all need the cover traffic

If the decryption key is not on removable media, with an open source package an attacker knows exactly where on the system to get the key. Even with closed source it's usually not much challenge to find it, and closed source is less secure anyway. So encrypting passphrases with the key hidden somewhere on the disk would be just for show, to impress people who don't know how encryption works. We are very reluctant to do that.

An effective alternative is to put the master key on removable media, creating a hardware token. But requiring that the user keep track of a hardware token is definitely not "Making private email easy". It is an appropriate option for Business Envelopes.

Use Java

• Some Java security advantages

  • No buffer overflows

  • Detects stack attacks, bounds errors, and more

  • Easy to solve most race conditions with the "synchronized" keyword

  • Has no setuid, setgid, chown, etc.

  • Has built-in deleteOnExit for temp files

  • Has a pretty good MAC (Mandatory Access Control) system built-in, although it's often unused

  • Typesafe dynamic storage with automatic garbage collection

  • No signals; instead relatively safe and rigorous Exceptions

• Some Java security risks

  • The interpreter and runtime libraries are usually closed source

  • The language specification is controlled by a corporation

  • exec()

  • JNI (Java Native Interface)

  • createTempFile by default uses shared dir and is non-atomic

  • World permissions for files are the default

  • printf was added to java as java.text.MesageFormat.format; the class is "compiled", i.e. native code, and may have the format bug

  • Possible excuses for using JNI

    • no chroot() in Java

    • no ulimit() or setrlimit()

    • no sync()

    • no mlock()

      • But on Linux only root can lock memory, and we don't want to run as root

      • Maybe for Business Envelopes

    • no flock()

    • no easy way to zero objects

• Minimize or eliminate use of JNI (Java Native Interface)

• User input should be carefully filtered for characters, length, and as much as possible, for syntax and semantics.

• Character streams to System.out and System.err should be filtered

  • Allow only letters, digits, spaces, punctuation, and line endings

  • In particular no '>", '<', or '|'

• Audit the interpreter and libs

  • This requires open source, which means a non-Sun jvm such as Kaffe

• Why not C or C++?

  • Open source java code has "an order of magnitude fewer" bugs than closed source C/C++ code.

  • C handled most of the serious work for many years, but it was designed in the 1970s and shows it

  • Too many security related programming errors are easy in C

  • Although it's a little easier to write around some security bugs in C++, it's not much safer than C

  • You can write safe code in C or C++ or even assembly, but unless it's all you know, why take the risks?

• If you must use C or C++, use safer tools such as IBM's Stack Smashing Protector

How to be sure a client is on the same machine as the server

• Local IP address

  • Not only checked by software. If web page, page should say e.g., "Domain in url for this page must be 127.0.0.1."

• Local ping times

• Local dynamic SSL cert

  • Server only accepts SSL connections, e.g. HTTPS but no HTTP

  • Server dynamically regenerates client SSL cert

  • When client connects, server verifies client cert is the same one server generated

• Challenge-response through local channel

  • Dynamically generated secret key

  • Ideally shared through RAM

  • Response time below net times

  • Requires custom client

Privacy policy Copyright © 2005-2007 Tiger Privacy