CDima875370 (Community Member) asked a question.
I have one single error for an improper resource release (a StreamReader). I have this single identical line in 4 different files, but I only get one error. When I attempt to fix this error in a file (one occurrence per file), I get the error for the next file. The issue now is that I ended up with all files fixed, but I now get the same error for the initial file. Attempting another fix variant will then trigger the error in the next file and so on.
The project in question is a .NET Core 2.0 web app. I am building the project from the terminal on macOS. The .NET Core version seems to be supported (https://help.veracode.com/reader/4EKhlLSMHm5jC8P8j3XccQ/UWyzuOKNbFbwQACRLkZVjA)
Initial line:
var msg = new StreamReader(Request.Body).ReadToEnd();
// only use msg from here on
Fix #1:
var sr = new StreamReader(Request.Body);
var msg = sr.ReadToEnd();
sr.Close();
Fix #2:
string msg;
using (var sr = new StreamReader(Request.Body)) {
msg = sr.ReadToEnd();
}
Fix #3 is similar to #1 but I put everything in a try/catch/finally block (calling Close() in the finally block).
I'm not sure if I'm doing something wrong, or if it's a veracode issue (or some problem with the .NET core 2.0 support?). The weird thing is that the issue is only reported once and the file keeps changing between fix variants.
Any help is greatly appreciated.
.png){kind=logo}
Hi CDima875370,
Typically with CWE 404 and for any other flaw category, expanding on the flaw details in Triage Flaws will provide you a bit more information about the flaw. Specifically with CWE 404, the flaw description will provide you how many instances of the particular resource identified that has not been properly closed or instances where the scanner could not see it being closed. I would suggest starting there to see how many instances have been reported as this was a design choice our product team chose to make as to how we report flaws for this flaw category when there are multiple occurrences of the same resource being identified.
As for the code snippet you provided, they appear to be valid solution to address CWE 404. Without more details about your scan, I couldn't tell you specifically why the scanner is still reporting it. I would recommend you schedule a consultation call to discuss, https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/bLo7cMy~2mOWtJ~kbrVzDg , or you can send an email to Support@veracode.com with the application and scan name so we can look into the flaws identified to provide you more specific feedback.
Thanks,
Veasna Nhin
Application Security Consultant
This faulty flaw is still present. Using blocks are not being recognized in .NET Core.
I am experiencing the identical issue in .NET Core 2.2.5
I'm a bit confused by this as well... wrote a little sample console app to demonstrate:
using System;
using System.IO;
namespace CloseDispose
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Before Using...");
using (var ms = new MyMemoryStream())
{
Console.WriteLine("Within Using...");
}
Console.WriteLine("After Using...");
}
}
class MyMemoryStream : MemoryStream
{
public MyMemoryStream() : base()
{
Console.WriteLine("1. Constructor");
}
public override void Close()
{
Console.WriteLine("2a. Before Close");
base.Close();
Console.WriteLine("2b. After Close");
}
protected override void Dispose(bool disposing)
{
Console.WriteLine($"3a. Before Dispose({disposing})");
base.Dispose(disposing);
Console.WriteLine($"3b. After Dispose({disposing})");
}
}
}
Results In:
1. Constructor
Within Using...
2a. Before Close
3a. Before Dispose(True)
3b. After Dispose(True)
2b. After Close
After Using...
So you can see the using block disposes of the MemoryStream, which closes it internally.
@BParker (Community Member) ,
The using statement is a proper way to handle and dispose of resources. In C#, the using statement is essentially syntactic sugar. It makes it much easier to manage your resource without having to write a bunch of try/finally blocks to do so and that is what a using statement is actually translated to by the compiler. In your example the using statement would be translated to as such:
var ms = new MyMemoryStream();
try {
Console.WriteLine("Within
UsingTry...");}
finally {
if (ms != null)
{
ms.Dispose();
}
}
To make it more complicated, the finally block is really seen as try/catch by the Veracode Static Analysis Tool. I can't recall specifically if this is because the compiler translates it as such but this is how it is model by the tool which as you can see no longer resembles a simple using statement. As a reminder, with .NET we are scanning the compiled binaries that you provide to us as oppose to the source code which is why these might be seen in your results. This is something our Research and Static are aware of and are constantly revisiting to see if any improvements can be made to identify the usage of the using statement to not flag these when used correctly. For the time being, we recommend you document a mitigation and work with your security team to review/approve accordingly if their is usage of a using statement that is found in your results: https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/~p4MSKOS8F8X8h0KwFTKoQ .
Also just so that you are aware, as of our 2020.3 Static Engine release, https://help.veracode.com/reader/0152lUHzdfrlpRBBmxjSSQ/ZqmlYhVbi31yhEtT9Tkf6w?section=concept_tmx_l1y_fcb__apr2 , we now flag CWE 404 as an informational finding as most modern languages handles this more efficiently than in the past and this has become more of a code quality issue.
Thanks,
Veasna Nhin
Application Security Consultant