World: r3wp

(only in trivial cases it may be a problem)

I am still sure, that disabling BIND in such cases is totally useless. 
(besides, when the function is not running, you cannot obtain the 
value of 'b even if you obtained 'b)

But, if you do want to "play dirty", then having 'a is completely 
sufficient

It surely is not a safety measure in any reasonable meaning, it is 
just an annoyance.

What it actually does, is that it disables to write some, otherwise 
clean, code.

I'm curious: How can you get a word 'b bound to a function context, 
when the function is not running, you don't have access to the original 
function body, and all you have is a word 'a bound to that same context? 
No command or extension tricks either - they're already assumed to 
be unsafe.

If there is a trick that doesn't require access to a block of code 
that already has a bound 'b in it, or that provides access to the 
bound body of a function without saving a reference to the body before 
the function is made, this is information we need to know to make 
R3 secure.

If it's the STACK function or something else that requires debug 
privileges to run, document it and move on. We already know STACK 
can be insecure, just not all of the tricks for doing so.

Actually, I'd be really interested if you figure out how to use STACK 
to hack a function that isn't running - that would be a heck of a 
trick.

I'm curious: How can you get a word 'b bound to a function context, 
when the function is not running, you don't have access to the original 
function body, and all you have is a word 'a bound to that same context? 
No command or extension tricks either - they're already assumed to 
be unsafe.

 - I offer you this statement, which I *can* prove in a reasonable 
 sense:


- I assume, that F is a function having a context with more than 
one variable (Otherwise, there is nothing to prove, is there?)

-, so, for the simplification, let's assume, that there are variables 
'var-a and 'var-b in F's context, such that:

- the Attacker has already access to the variable 'var-a bound to 
the F's context

- , but he does not have the access to the variable 'var-b bound 
to the F's context yet

- now, let's assume, that having access to the variable 'var-b in 
the F's context he would be able to "do some harm" (whatever that 
"harm" is)


Provided, that the above conditions are met, the Attacker is already 
able to do the harm even not having the variable 'var-b bound to 
the F's context available yet. Do I have even to prove the statement?

Oh, that's what you meant. I was asking specifically about the particular 
question I asked. It sounded like you were saying you had a way to 
do a BIND without BIND. If so, that would be an interesting trick, 
but also a security hole. I'm more interested in the trick though, 
if it exists.

Not much of a trick is needed. The above statement (when proven, 
which is easy), proves, that the disabling of BIND for non-running 
function words is not a security measure.

The above statement requires either access to a word of the same 
spelling bound to the context. I'm talking about accessing a different 
word.

Sorry?

Did I write that?

(I may have written it incorrectly, then, since that is not what 
I intended to write)

Let's ignore the function context aspect of it all, and simplify 
the problem. If you have a word bound to a context, and want to get 
access to another word bound to the same context, and don't have 
access to the BIND or IN functions at all, how would you do it?

Once again, the assumptions are:

- I have a word 'var-a bound to the F's context

- It is true, that *if* I had a word 'var-b bound to the F's context, 
then I would be able to do "some harm"


Provided that these conditions are met, then I am able to do the 
harm.

(Even though the BIND function is "crippled*, but, as proven by the 
above statement, unreasonably so.)

I am asking something really specific (see my last message).

Yes, but I never offered the answer to your question.

Ah, but that is the only question I was asking.

Yes, but my intent was to prove, that the BIND crippling is unreasonable, 
which is provable.

We can plug one hole at a time. What you are requesting is something 
that we are trying to prohibit, and we have good reasons for doing 
so. If there are also other means of doing it, we can address those 
issues later. One issue at a time.

What you are requesting is something that we are trying to prohibit, 
and we have good reasons for doing so. 
 - by the above, I just proved, that you do not

...have good reasons

We are trying to prevent functions from being modified from the outside 
without changing the function (SAME? test), and to allow functions 
to work on information that we want to keep hidden from other code, 
such as when a variable has an unencrypted password in it or other 
sensitive information. Or we could just give up on being able to 
run untrusted code because it's futile, as you are requesting.

Above you mentioned, that the reson is this:


- if I had access to a 'var-a variable bound to the F's context, 
and if I were able to do "some harm" having another variable 'var-b 
bound to the F's context, then that is a good reason why to cripple 
BIND, to not give me the access to the 'var-b bound to the F's context 
as well when the function is not running.

 As stated, I can disprove that as a reason.

Thus, the purported reason is not a reason at all, surely not "good".

My last message had the reasons. What you are talking about are the 
means.

OK, I will cite you exactly:


Sure it is, in some cases. What if 'a is harmless, but 'b refers 
to a password? If you can only CHANGE, not BIND, then leaking a word 
is only as dangerous as leaking what that word refers to. If you 
can BIND using that word as a context, you can get access to *every* 
value referred to by that context, not just the one. So it's still 
potentially a problem to leak a single word (depending on what gets 
assigned to that one word), but not as bad a problem as it could 
be.

That can be easily disproved.

Do you want me to?

OK, prove it without having access to the original body code (a separate 
issue), and while the function isn't running (another separate issue).

Yes, it is easy

Just with access to a reference to the function itself, and and a 
word bound to its context.

Sure, still trivial

Proof:


1) Due to the way how the function contexts are implemented in R3, 
the word 'b in F's context does not refer to a password when F is 
not running.

2) Because of that, I either cannot read the password at all, or 
have to be able to read it somehow, which is possible *only* when 
the function is running. (oherwise, there is no danger of me reading 
the password as is well known)
3) do I have to continue?

Sorry for using the power of logic, but I just am unable to see illogical 
statements as "good reasons".

OK, so you don't have a solution to that problem (darn, I was looking 
forward to that), but you have a proposed proof that it doesn't matter 
because you can't exploit it until the function is running. And since 
the BIND restriction when the function isn't running doesn't apply 
when the function *is* running later, even when applied to the same 
word, then the ban on BIND to a function-context-bound word when 
the function isn't running has no security benefit.


But the ban on BIND to the function! value *itself* still has value, 
because it would defeat the efforts to prevent any bound words from 
leaking out of the function from helping. Otherwise it would be unsafe 
to let untrusted code call safe functions because they would need 
to have a reference to the function in order to call it.

I do have a proof, which disproves your exact citation

But the ban on BIND to the function! value *itself* still has value, 
because it would defeat the efforts to prevent any bound words from 
leaking out of the function from helping. 
 - another disprovable statement

OK, get access to a function context with just a reference to the 
function itself. It doesn't matter if you run the function, because 
the function doesn't leak any bound words.

Why are you stating disprovable statements, and when I call them 
as such, you invent completely unrelated statements requiring me 
to prove them?

And no, using STACK still doesn't count because it's known, and blocked 
if SECURE works.

And, regarding to your "password problem", you are still trying to 
impose unrelated conditions. As is obvious, nobody can read a password 
from a function not referring to it when the function is not running. 
Thus, you cannot purport, that for the security of said password 
it is necessary to forbid something when the function is not running. 
It is not.

The "But the ban on BIND to the function! value *itself*..." statement 
refers to this:
>> not find second types-of :bind function!
== true


The BIND function doesn't accept function! values for its context 
argument. The reason for this is so that functions can prevent access 
to their context from leaking to code *that the function calls* that 
could be exploited while the function is running. All the function 
has to do is not leak bound words, and it's safe. If that doesn't 
work, please show how.

To remind you, I am and was always referring to this:

>> f: func [a b] ['a]
>> bind [b] f 1 2
** Script error: none word is not bound to a context
** Where: bind
** Near: bind [b] f 1 2

The above is unrelated

No, the above is the exact reason for:
>> not find second types-of :bind function!
== true

No...
 - still unrelated