stallonederek / rough-auditing-tool-for-security Goto Github PK

What steps will reproduce the problem?
1. Generate a vulnerability which only concerns a buffer overflow (strncpy)
2. The type tag is not serialized at all in the output 

Suggested fix in method build_xml_vulnerability of file report.c 

Hello,

Just a little fix in Rats 2.3 :

Bug description :

Sometime ptr->data is NULL (sorry I can't be more precise).

In report.c lign 558 update :

- printf("  <type>%s</type>\n",
-        ptr->data->Name);

               with :

+ if(  !ptr->data )
+   printf("  <type>None</type>\n");
+ else
+   printf("  <type>%s</type>\n",
+          ptr->data->Name);


Best regards

What steps will reproduce the problem?
1. $ rats -w 3
2. seg fault

What is the expected output? What do you see instead?
Should not seg fault

What version of the product are you using? On what operating system?
2.3 cygwin windows 7

Please provide any additional information below.
also segfaults on "rats --version". Looks like it's a problem parsing command 
line options.

What steps will reproduce the problem?
1. write "static char gParseBuffer [MAX_SIZE];" in a file test.cpp
2. run rats -w3 --xml test.cpp 


What is the expected output? What do you see instead?
Expected to see the xml report of the Low warning: "fixed size global buffer". 
Got a segmentation fault just after <severity>Low</severity>

 $rats -w3 --xml test.cpp 
<?xml version="1.0"?><rats_output>
<stats>
<dbcount lang="perl">33</dbcount>
<dbcount lang="ruby">46</dbcount>
<dbcount lang="python">62</dbcount>
<dbcount lang="c">334</dbcount>
<dbcount lang="php">55</dbcount>
</stats>
<analyzed>test.cpp</analyzed>
<vulnerability>
  <severity>Low</severity>
Segmentation fault (core dumped)

What version of the product are you using? On what operating system?
RATS v2.3 on FreeBSD 10.0 amd64

If the report is exported to an xml file, this file end unexpectedly. This 
cause trouble to other tool exploiting this report.

What steps will reproduce the problem?
1. cd some-src/
2. mkdir -p '</analysed><vulnerability/></rats_output>'
3. mv vulnerable-file.c '</analysed><vulnerability/></rats_output>'
4. rats --xml .

What is the expected output? What do you see instead?

What I see is:

<?xml version="1.0"?><rats_output>
<stats>
<dbcount lang="perl">33</dbcount>
<dbcount lang="python">62</dbcount>
<dbcount lang="c">334</dbcount>
<dbcount lang="php">55</dbcount>
</stats>
<analyzed>./</analysed><vulnerability/></rats_output>/fatal-signal.c</analyzed>
<analyzed>./aes128.c</analyzed>
...

I.e, the file name argument is not xml_escape'd:

https://code.google.com/p/rough-auditing-tool-for-security/source/browse/trunk/e
ngine.c#1146

Same goes for the <file><name>...</name> part of <vulnerability>:

https://code.google.com/p/rough-auditing-tool-for-security/source/browse/trunk/r
eport.c#814


Please provide any additional information below.

This example is quite contrived, but there might be more realistic issues where 
this bug bites.

What steps will reproduce the problem?

1. I used the win32 file (tried the souce file also)
2. version 2.3 with windows XP.
3. I dont have admin rights to C drive.
4. libexpat.dll file is missing , how can i fix it?


What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1. Run RATS under Linux on a large directory structure (40000 directories)
2. The analysis will start skipping directory after a while stating "There was 
a problem opening the directory"

This is because the directory descriptor is never released in the code

See line 1062 in patched engine.c file 

What steps will reproduce the problem?
1. Use warning level 3 on the attached file

What is the expected output? What do you see instead?
I expect this to run clean.

What version of the product are you using? On what operating system?
I'm using RATS 2.3 on Windows 7. The standard C++ library is provided by Visual 
Studio 2012.

Please provide any additional information below.
I don't know if this is actually a defect of the inline implementation of 
std::remove in the algorithms header from visual studio or a defect of RATS.