Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiled rules can execute malicious code regardless of PARANOID_EXEC #999

Open
bnbdr opened this issue Dec 8, 2018 · 7 comments
Open

Compiled rules can execute malicious code regardless of PARANOID_EXEC #999

bnbdr opened this issue Dec 8, 2018 · 7 comments

Comments

@bnbdr
Copy link

@bnbdr bnbdr commented Dec 8, 2018

A malicious compiled rule file could escape YARA's virtual machine and execute arbitrary code despite the added checks introduced by PARANOID_EXEC.

This is possible due to the design of the virtual machine, which stores and operates on pointers to YR_OBJECTs from the virtual stack, as well as the following bugs:

  • OP_COUNT can be used to read a DWORD from any arbitrary address.
  • the VM scratch memory is uninitialized and could leak important addresses from the real stack.

These were assigned the following IDs, respectively:

  • CVE-2018-19976
  • CVE-2018-19975
  • CVE-2018-19974
@plusvic
Copy link
Member

@plusvic plusvic commented Dec 8, 2018

I more detailed explanation of your exploit would be helpful. I guess your idea is using OP_COUNT to read the objects canary and craft a fake object to execute arbitrary code, is that correct?

@bnbdr
Copy link
Author

@bnbdr bnbdr commented Dec 8, 2018

using OP_COUNT to read the objects canary

Yes. My PoC uses a fake function object and then executes code using OP_CALL.

more detailed explanation of your exploit would be helpful.

I have written a technical write-up that delves into the VM architecture and explains said PoC. I can publish it shortly.

@bnbdr
Copy link
Author

@bnbdr bnbdr commented Dec 8, 2018

@plusvic
Copy link
Member

@plusvic plusvic commented Dec 10, 2018

Very good job in finding and explaining this issue. You have done an impressive job in understanding YARA's internals. This commit should solve the problem with OP_COUNT: 6acc08d

Regarding the initialization of vmem, it's now fully explained in your write-up but I guess your point is that you can read values from the the uninitialized vmem that are return addresses left in the stack, and they can be used for determining the base address where the library was loaded. Is that what you meant?

@bnbdr
Copy link
Author

@bnbdr bnbdr commented Dec 11, 2018

Thanks.

...from the the uninitialized vmem that are return addresses left in the stack, and they can be used for determining the base address where the library was loaded

Yeah, among other things.

plusvic added a commit that referenced this issue Dec 13, 2018
* Add additional check in OP_COUNT for making sure that the string pointer is not a fake one.

* Initialize scratch memory in order to avoid maliciously crafted YARA rules from reading values left in the stack.
@plusvic
Copy link
Member

@plusvic plusvic commented Dec 13, 2018

#1001 should solve this issue. @bnbdr, your feedback is welcomed.

@plusvic
Copy link
Member

@plusvic plusvic commented Apr 30, 2019

@bnbdr would you mind reviewing #1061? The idea is storing the canary in a structure in the heap, instead of using a global variable, this way it should be harder to determine the canary's address, at least in theory. Your feedback will be appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants