odin1314 / yara-project

Automatically exported from code.google.com/p/yara-project
Apache License 2.0
0 stars 0 forks source link

Built-in functions (e.g., entrypoint) silently FAIL when applied against unsupported filetypes (should return false, instead) #47

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. Let's say I have two YARA rules declared as:

rule Is_EXE_Or_DLL { condition: entrypoint >= 0 } 
rule Is_Not_EXE_Or_DLL { condition: not Is_EXE_Or_DLL }

2. And then I supply an RTF file.

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

I would expect the YARA rule "Is_Not_EXE_Or_DLL" to fire, but it does not.  
This is because the "entrypoint" calculation only applies to PE files and will 
silently _FAIL_ on any other file types.  In general, for any built-in 
functions like "entrypoint", it should return _FALSE_ instead of failing, if 
the wrong filetype is supplied.

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

Yara v1.6, Linux 64-bit
Please provide any additional information below.

Original issue reported on code.google.com by dar...@kindlund.com on 10 May 2012 at 7:26

GoogleCodeExporter commented 9 years ago
When you use the "entrypoint" keyword YARA asumes that your rule is targeted to 
files that do have an entry point. If the file is of a type that doesn't have 
an entrypoint the rule is ignored and it's result is undefined. The condition 
"entrypoint >= 0" when applied to a non-executable file is neither true or 
false, and the same goes for "not entrypoint >= 0".

Besides, you shouldn't rely on the "entrypoint" keyword to determine if a files 
is an EXE or DLL, because the "entrypoint" keyword also aplies to ELF files and 
probably other file formats in the future that also have an entry point.

Original comment by plus...@gmail.com on 11 May 2012 at 12:53

GoogleCodeExporter commented 9 years ago
Page 13 of the YARA v1.6 User's Manual.pdf (1st paragraph):

"The presence of the entrypoint variable in a rule implies that only PE or ELF 
files can satisfy that rule. If the file is not a PE or ELF any rule using this 
variable evaluates to ***FALSE***."

Either the documentation needs to be fixed, or this bug is legitimate; it can't 
be both.  Do you see my point?

If you're going to silently fail built-in functions for unsupported file types, 
that's fine, but at least update the documentation to reflect that nuance.

Furthermore, it would be _exceptionally_ helpful, if YARA included some sort of 
"verbose" options, where it would spit out warnings, everytime a built-in 
function failed silently (because it encountered an unsupported file type).

As it stands, using these built-in functions is proving difficult to debug at 
times, _because_ YARA doesn't provide a lot of information about the steps it 
is performing, during individual rule evaluation.

Let me know if this makes sense.  Thanks for your time.

Original comment by dar...@kindlund.com on 11 May 2012 at 1:50

GoogleCodeExporter commented 9 years ago
You're right, the documentation should be fixed because it doesn't reflect the 
real behavior. Probably it should say "If the file is not a PE or ELF any rule 
using this variable is unsatisfiable". 

I think in this case it's better to think in terms of unsatisfiability, because 
we keep conceptual coherence. For a text file is not true that it's entrypoint 
is greater than zero, but the opposite is not true neither. The entry point 
concept simply doesn't make sense for a text file.

Regarding a "verbose" mode, it makes a lot of sense. It's a good idea to 
provide some feedback in those cases where keywords like "entrypoint" or 
"filesize" are used in the wrong context.

Original comment by plus...@gmail.com on 11 May 2012 at 10:47

GoogleCodeExporter commented 9 years ago
Okay, that's fine; I understand if you'd rather update the documentation and 
provide a higher verbosity level.  In that case, can you change the WontFix 
status of this issue, then?  Thanks! 

Original comment by dar...@kindlund.com on 12 May 2012 at 12:04