In spite of the fact that .NET has long been one of the more popular frameworks for those coding native Windows apps, it’s faced quite a bit of criticism due to several serious safety faults. Cybersecurity experts have pointed to the fact that .NET is easy enough to use without consideration for type safety. It’s generally possible for programmers to classify nearly any data type as a string instead of a secured string even if it’s designed to hold a password. As a result, it’s wholly possible for user credentials to get stored in a plain text environment when they’re passed over to an app developed with the .NET core of libraries.
The .NET Foundation put out the 6.0 stable release in November 2021, and some have suggested that this fixes many of the major flaws that cybersecurity analysts have pointed out about the various libraries that make up the framework. However, underlying problems related to data type specifications more than likely remain as these are the result of core design decisions that could take a Python 3-level refactoring to repair.
How Software Bloat Caused Security Issues
Heap overflow vulnerabilities and other kernel space problems seldom impact .NET applications directly because they’re somewhat self-contained. However, they have traditionally needed a large number of dependency packages that could potentially compromise a system when installed. For the longest time, it wasn’t even really possible to compile static linked executables that didn’t depend on a number of other redistributable libraries that had to be installed by an end-user.
Assuming that these weren’t already on their system, doing so dramatically increased the overall stack that they were running locally. If they were also running applications that required them to install Ruby or C++ libraries, then they could have far more code running at any given time than they imagined. Those who additionally ran some kind of WordPress hosting plugin software may face even further potential vulnerabilities. Naturally, those who consistently updated all of these dependencies would be in the best position, though this is more or less limited to those working with Unix systems where said libraries were regularly downloaded from online repositories.
Engineers now believe that they’ve found a solution to the dependency bloat that’s caused these issues.
Fixing the Flaws Inherent in .NET Libraries
Any .NET programs deployed as a single file binary won’t extract their core runtime packages to a temporary directory like they used to. While GNU/Linux users haven’t seen this kind of behavior in quite some time, it was still a major issue for those on the Windows and Apple Macintosh platforms. This change has also helped to improve file I/O numbers to at least some degree.
While .NET apps aren’t exactly portable at this point, it does mean that it’s easier for programmers to distribute a single binary that can be run on any machine that meets the minimum system requirements. Non-profit and open-source developers who share their applications via RPM or DEB packages might even be able to send far few files in their bundles, which could help to limit how much installation of them increases the total attack surface of a system.
Nevertheless, there are some serious questions that cybersecurity experts continue to raise about the long-term stability of applications developed with .NET code.
Problems that Still Plague .NET Apps
Unlike many other programming platforms, data types stored in memory with the .NET framework are going to usually get stashed away in RAM without any security services attached to them. That’s a serious problem when dealing with passwords and other forms of sensitive data, though it’s not much of an issue for developers of local productivity applications that don’t connect to any remote servers. While .NET might not be the first choice for those developing a text editor, it’s ironically a decent choice for someone writing the next vi clone.
Role-based security features help to protect files created and edited by apps built against .NET libraries, but these features are somewhat useless when dealing with a large number of files distributed over a network. At the same time, there’s always the possibility that someone could gain control of a regular user account and then start to mess with sensitive files even if they were stored locally.
By using a code injection attack, bad actors could theoretically take control of any account attached to a storage system that they wanted. Since these vulnerabilities are related more to the underlying cloud infrastructure, no patch to .NET Core would ever actually help to fix them. That being said, the fact that individual binaries compiled against the libraries don’t come with as many dependencies as they once did will help to reduce the attack surface that could make these potential attacks a possibility.
No framework will ever be truly safe, but it seems as though the latest .NET 6.0 release is at least a marked improvement over previous versions of the software. Whether it has introduced any new vulnerabilities will remain a question that only time can answer, however.
