If you didn’t happen to see it in the news, the Computer History Museum released the source code for Microsoft Word version 1.1a with the announcement here. With it being a well-known fact that Microsoft products are frequently targeted (likely because of their market share) with new vulnerabilities being discovered quite often, we decided to run the source code through Checkmarx (a commercial static source code analysis tool) to see how it fared with respect to security. In the 1980’s, it is unlikely that security was in the spotlight like it is today. A number of coding errors could result in exploitable conditions such as buffer overflows, integer overflows, format string attacks, use after frees, etc. The following screenshots show the number of each type of finding that Checkmarx discovered. These numbers are without any manual verification and likely include false positives so the actual numbers could be less. As we can see, the large number of issues identified coupled with the many flaw categories suggests that there are likely a number of exploit opportunities. An example of one buffer overflow can be found in the “/OpusEtAl/tools/newtoexe.c” file where argv[1] is used with the strcpy function without any validation. The purpose of this file/tool is unknown and may not be exploitable remotely, however it is just a simple example that was quickly identified. Many of the attack techniques known about today probably did not exist back then either. The Morris worm in 1988 was one of the first, if not the first, malicious buffer overflow used. Microsoft has security integrated into its SDLC today, however back then it was likely not a priority. Any production application should have security embedded from start to finish including static source code analysis, dynamic testing, and environment hardening. Each acts as a preventative control when utilizing defense in depth. Static source code analysis offers maximum visibility into the functionality of the application whereas dynamic testing may not be able to access all features if they are not known about. Often there will be additional devices supporting an application such as databases, file servers, LDAP servers, routers, switches, load balancers, etc. Environment hardening should encompass further securing such devices as they are rarely fully secure out of the box in their default configurations. Many minimum security baseline documents are available including DISA STIGs (http://iase.disa.mil/stigs/) and CIS benchmarks (https://benchmarks.cisecurity.org/). By performing different types of testing throughout the creating of and application and its environment, the more secure it will be in the end. This article was written by Scott White | Principal Security Consultant.