DTR 24772 Editor's report

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. • XYQ, XYE, XYF, EWF, XYY, FAB, YOW, XYK, BQF, and XZM
3. New vulnerabilities
4. • REU, NAI, SYM, LAV, CCB, TEX, MTW, SAM, GDL, NZN, CSJ, and IHN
5. 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. • value of parameter field or argument name
   • parameter, field, or argument name
9. In 6.5.4, last paragraph. Perhaps move or copy as a definition of lifetime of an object.
10. 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.
11. 6.6.6 first bullet item. Need reference to Garbage collector referenced and Valgrind
12. 6.7.6 second bullet item. Need reference to StackGuard, ProPolice and Microsoft Visual Studio /GS flag
13. 6.9.5, last bullet item. Languages may require it but leave the effect of not doing so as undefined
14. 6.9.6, last bullet item. "assist" is insufficient, it is necessary to detect violations
15. 6.12.5, also closely related is reassigning a value to a variable without evaluating it
16. 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.
17. 6.13.6, last bullet. Many programmers say it is to inefficient to check array subscript bounds
18. 6.14.6, second bullet. Doesn't this advice assume a particular hardware representation.
19. 6.15.1, isn't this a system development/programming error rather than a language vulnerability
20. 7.2.4, last paragraph. Prefer "he" to the clumsy "he/she"
21. 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"