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 · 6 comments

Comments

Projects
None yet
2 participants
@bnbdr
Copy link

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

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

bnbdr commented Dec 8, 2018

@plusvic

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link

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

Fix issue #999 (#1001)
* 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

This comment has been minimized.

Copy link
Collaborator

plusvic commented Dec 13, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment