Fix issue #999

[plusvic]

No description provided.

[bnbdr]

I would make sure all other opcodes don't suffer from similar issues.

[plusvic]

OP_LENGTH (and OP_OFFSET with a bit more difficulty) could be used to read the canary provided that you can write a YR_MATCH structure somewhere and get its address in order to push it into the virtual stack. Writing the YR_MATCH structure in the virtual stack is possible, but I didn't find a way of knowing its address.

[bnbdr]

...I didn't find a way of knowing its address.

Faking YR_MATCH structure is possible because the bytecode can still infer the location of the vstack as I showed with the PoC and the function object.

Regardless, I did find the following:

• It's possible to read the canary value using OP_OFFSET without finding the vstack and faking a YR_MATCH struct on it. I can explain further if needed.

• OP_MATCH_RULE could theoretically be used to set the LSB of any address.

• The canary value is limited to a 15-bit unsigned value (at least on windows):

// stdlib.h
#define RAND_MAX 0x7fff

[plusvic]

It's possible to read the canary value using OP_OFFSET without finding the vstack and faking a YR_MATCH struct on it. I can explain further if needed.

I'm curious about this.

[bnbdr]

Basically pushing a shifted pointer to a real YR_OBJECT before issuing OP_OFFSET can cause the VM to read that object's parent's identifier and canary and put the addition of those on the virtual stack.

Then it's a matter of doing some calculations to reach the original canary value.

I've written a rule (yarasm, compiled) that compares the canary using both methods (OP_OFFSET and OP_COUNT).

It should exit cleanly if they match (i.e. no assertions).

[bnbdr]

@plusvic I can elaborate if necessary.

[plusvic]

Any additional info would be helpful. I haven't enough time to look into this in detail. However I'm wondering, given the design of the VM, if is going to be actually possible to close all the holes.

[bnbdr]

Easiest "patch" would be to break compatibility by requiring a command-line switch to allow running compiled rules together with classifying compiled rules as "potentially dangerous".

This prevents uninformed users from running possibly malicious rules without their intention and shifts the responsibility.

additional info would be helpful

I'll see what I can conjure up

[plusvic]

Yes, that's probably not vey hurtful to users and at least prevents using compiled rules inadvertently.

…

On Wed, Jan 23, 2019 at 2:37 PM bnbdr ***@***.***> wrote: Easiest "patch" would be to break compatibility by requiring a command-line switch to allow running compiled rules together with classifying compiled rules as "potentially dangerous". This prevents uninformed users from running possibly malicious rules without their intention and shifts the responsibility. additional info would be helpful I'll see what I can conjure up — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1001 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALKmUXIf8kF8JQSwBy2X7f3amSzB1OTks5vGGWAgaJpZM4ZRVnG> .