In basic terms, software deals with input, processing, and output. Many security vulnerabilities are created by developers making unfounded assumptions, often implicitly, about the nature of input data.
Buffer overflows have existed since the dawn of programming. Many programming languages rely on pointers for strings, buffers, and general memory allocation. As a result, it is easy to write data beyond the end of allocated memory. This issue was thoroughly understood in the 1970s, yet buffer overflows are still being exploited today for malicious remote code execution attacks. Making the same mistakes for more than 40 years constitutes sheer negligence.
Jeff Forristal, known by the alias Rain Forrest Puppy, wrote the first public discussion of SQL injection in 1998. The concept is simple. Many programs use input data to create SQL queries. Unless the program constrains input to acceptable characters, it is possible to include SQL delimiters and commands within user input. By carefully crafting input data, malicious users are able to modify the SQL query to bypass access controls and manipulate the database. More than 15 years later, SQL injection vulnerabilities continue to plague software and result in widespread security breaches.
Some applications also invoke other programs, including operating system commands. Allowing untrusted input to be included as part of the command string generated for executing a program allows attackers to modify arguments or even execute arbitrary commands. Despite decades of experience, this issue also persists.
It would be difficult to imagine physicians, civil engineers, or automobile designers making the same dangerous mistakes for 40 years, apparently unable or unwilling to learn from the past. Failing to demonstrate an appropriate standard of care makes for easy negligence and professional misconduct cases. So, why do professional software developers continue to churn out software with the same kind of defects?
One answer lies in how software is sold. Consider this extract from a common software licence agreement:
“TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND ITS SUPPLIERS PROVIDE THE SOFTWARE AND SUPPORT SERVICES (IF ANY) AS IS AND WITH ALL FAULTS, AND HEREBY DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY (IF ANY) IMPLIED WARRANTIES, DUTIES OR CONDITIONS OF MERCHANTABILITY, OF FITNESS FOR A PARTICULAR PURPOSE, OF RELIABILITY OR AVAILABILITY, OF ACCURACY OR COMPLETENESS OF RESPONSES, OF RESULTS, OF WORKMANLIKE EFFORT, OF LACK OF VIRUSES, AND OF LACK OF NEGLIGENCE…”
MIcrosoft’s agreement is by no means unique; it is representative of an industry that imposes one-sided agreements to limit their legal liability. On one level it makes sense. Software companies don’t want to be liable for damages if their software malfunctions, nor do they wish to be dragged into court every time someone suffers a data loss. This approach to avoiding liability is financially advantageous.
It is also likely that “as is and with all faults” licence terms encourage the development and sale of poorly designed, sloppily coded, and inadequately tested software. To be fair, software developers must take their reputation and potential support costs into account. However, it is much easier to deliver software releases at lower cost and on schedule with the knowledge that there are minimal, if any, liability issues involved.
Another answer lies in the fact that despite university programs in software engineering, very few engineering principles are applied to software development. Important topics such as stability and fault tolerance are frequently ignored. Many software companies focus solely functional requirements and fail to consider how their software will respond if something goes wrong. They design and build for the best case scenario: users performing expected functions in an expected order.
Software is critical to virtually every aspect of daily life. Individuals, businesses, governments, and ultimately the Canadian economy depends on software functioning properly. Financial losses due to preventable software security defects are staggering.
In most markets, companies that fail to properly design their products, repeatedly make the same mistakes, and don’t exercise due care, seldom survive for long. It is time that we stop accepting negligent software development practices.
Have questions you’d like answered in a future column? Email email@example.com.
SAMSUNG GALAXY S8 PLUS
The Samsung Galaxy S8 Plus is a beautifully crafted smartphone with nearly no bezel, curvaceous in design and reflects a…
How to: Connect to Exchange Online Using Multi-Factor Authentication
Using PowerShell to manage your Microsoft cloud services like Exchange Online and using multi-factor authentication (MFA) separately is awesome. Using…