DTR 24772 Editor's report

Date: 2007-11-26
Document: N0107
Author: Benito

Changes to the base document, all changes are marked with change bars.

  1. Changed some US only spellings to World spellings.
  2. Fixed some heading numbers
  3. Miscellaneous small editor edits
  4. Added some cross references
  5. Added vulnerability TRJ – Use of Libraries
  6. Added vulnerability AMV – Overlapping memory
  7. Added vulnerability HFC – Pointer casting and pointer type changes
  8. Added vulnerability EOJ – Demarcation of control flow
  9. Added vulnerability NYY – Dynamically linked code and self modifying code
  10. Added vulnerability BRS – Leveraging human experience
  11. Added vulnerability CLL – Switch statements and static analysis
  12. Added vulnerability NMP – Pre-processor directives
  13. Added vulnerability RVG – Pointer arithmetic
  14. Added vulnerability JCW – Operator precedence
  15. Added vulnerability KOA – Likely incorrect expressions
  16. Added vulnerability MEM – Deprecated features
  17. Added vulnerability PLF – Floating point arithmetic
  18. Added vulnerability STR – Bit representations

Decisions reached in Kona not in this document

  1. Changes to the vulnerabilities:
  2. New vulnerabilities
  3. New Vulnerability DCM has been moved to a modification to XYK

Comments not applied to base document

  1. The programming language that is used as an example should be identified
  2. The OS or System that is used as an example should be identified
  3. Make 1.1 a grammatical paragraph, not a list.
  4. 6.x.5 change to "Applicable language characteristics"
  5. Readers who are expert in only one language, e.g. "C", may not understand the special terminology of another, e.g. Ada. It is therefore highly desirable that the distinctive terminology of each language is covered in Section 3.
  6. An example would be helpful in 5.2.
  7. In 6.3.4, last sentence is ambiguous, does it mean
  8. In 6.5.4, last paragraph. Perhaps move or copy as a definition of lifetime of an object.
  9. 6.6 XYL. How does one detect that a memory leak is occurring? If you lose one byte per millisecond a gigabyte of memory will not be lost until the application has run for 11 days. Might need to add a simple program and system testing may not detect memory leak that is occurring.
  10. 6.6.6 first bullet item. Need reference to Garbage collector referenced and Valgrind
  11. 6.7.6 second bullet item. Need reference to StackGuard, ProPolice and Microsoft Visual Studio /GS flag
  12. 6.9.5, last bullet item. Languages may require it but leave the effect of not doing so as undefined
  13. 6.9.6, last bullet item. "assist" is insufficient, it is necessary to detect violations
  14. 6.12.5, also closely related is reassigning a value to a variable without evaluating it
  15. 6.13.1, there is an implicit assumption that a buffer starts with an index of zero — is this always the case or only in language X, Y and Z.
  16. 6.13.6, last bullet. Many programmers say it is to inefficient to check array subscript bounds
  17. 6.14.6, second bullet. Doesn't this advice assume a particular hardware representation.
  18. 6.15.1, isn't this a system development/programming error rather than a language vulnerability
  19. 7.2.4, last paragraph. Prefer "he" to the clumsy "he/she"
  20. 7.3, is this the same vulnerability as when a system stores "characters of password" rather than rf('characters of a password') = x where there is no simple inverse function rf-1(x) that gives "characters of password"