D. J. Bernstein
Mailing lists
securesoftware

Information for contributors

It is your responsibility as a securesoftware contributor to make sure that your message is clear, correct, and complete. The mailing-list message quality has been entrusted to you.

Please provide a useful subject line for every message: 

     Subject: [local] [control] screen <=3.9.5 has a format string bug
     Subject: [remote] [kill] openbsd 2.7 can't handle bad IPSEC packets
Start with [local] or [remote]. Is this a problem for workstations where all users are trusted? Continue with the impact of the problem:
  1. [control]: The computer can no longer be trusted, even if the system is reinstalled. For example, the attacker can add a command to a user's .login file.
  2. [destroy]: The computer can be trusted if the system is reinstalled; however, information is lost. For example, the attacker can remove a user's .login file.
  3. [kill]: The computer can be trusted if the system is reinstalled, and no information is lost; however, a service has died. For example, the attacker can kill the inetd process. (If you're not sure whether a crash is [control] or [kill], figure it out before composing your message; the difference is crucial for system administrators.)
  4. [exhaust]: The computer can be trusted if the system is reinstalled, no information is lost, and services are still functioning; however, services are so overwhelmed by the attack that they are not consistently available to legitimate users. For example, the attacker can use up all available HTTP resources.
  5. [snoop]: Everything works, but the attacker gains information that he should not have. For example, the attacker can read a user's .login file.
Exactly which software versions have a problem?

Further messages discussing the same security hole---most importantly, suggesting fixes---should be part of the same thread: 

     Subject: Re: [remote] [kill] openbsd 2.7 can't handle bad IPSEC packets
Put Re: in front of the Subject line, and put a References line (or In-Reply-To line) into your message header showing the Message-ID of the original message. Your mail software should do this automatically if you follow up to a previous message in the thread.

Please do start a new thread if the security hole is more severe than the original message suggested: for example, if you discover that a [kill] problem is actually a [control] problem.

You are encouraged to publish portable, documented, readable software that exploits the security hole. This is by far the easiest way for other computer security researchers to verify your discovery and for administrators to confirm that they are vulnerable. If, for example, there is a screen security hole that allows a local user to take control of root, your program should run as a local user and create /securityhole-screen.

You are not encouraged to withhold information. Programmers who create security holes will suffer if those security holes are disclosed; good! They obviously need more incentive to check their work. The security holes are their fault, not yours. If you're worried about them shooting the messenger, post anonymously.