World: r3wp

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

But, the reasons for disallowing the functions as the BIND arguments 
have actually a similar flaw.

a: func [code /stuff] [stuff: "something secret, not a literal string" 
code]


With just a reference to :a, bind 'stuff to the function context. 
The function could be running or not when you get access to the bound 
word 'stuff. The exploit code can then be passed to the function 
in its code argument, which would then have access to the contents 
of 'stuff because the function is running.

your example is too trivial. I get the access to the "something secret..." 
too easily, jut by examining the function body. Don't you have anything 
more complicated?

This is the reason for that particular restriction. If there's a 
workaround that we don't yet know about, let us know so we can plug 
it.

That was just a placeholder. The stuff variable could be the results 
of a prompt to the user for their password, or of a native function 
that decrypts something. One problem at a time.

As said, problem solved. You need something nontrivial to throw at 
me.

No, seriously, I meant it. How do you do this without BIND 'stuff 
:a ?

As said, I do not have to. The string is already there for me to 
read.

Your trouble is, that you do not see, that the triviality of your 
problem matters.

Ignore the particular literal value there, and substitute it with 
something that outside code can't otherwise get access to, like the 
results of a call to a function that is referred to by a PROTECT/hide 
variable.

I cannot, it is up to you to find *any* meaningful example, which 
I am maintaining is impossible.

It is you failing to provide a reason, and, I am actually able to 
prove there is none.

If getting access to 'stuff is the only way to get access to what 
it refers to, how do you get access to 'stuff if all you have is 
:a ?

Any example?

As said, using the properties of REBOL functions, I can easily prove 
you wrong in any case you invent.

blah: module [] [hidden hidden-stuff: "something you want" a: func 
[code /stuff] [stuff: hidden-stuff code]]
blah/a func [] [do something to get access to hidden-stuff]

OK, fine, an example that looks meaningful to you.

So, do I assume correctly, that I cannot examine the BLAH module 
to get the HIDDEN-STUFF value?

It's just a placeholder. If you have a PROTECT/hide exploit, that's 
interesting too but off-topic.

Does not matter, it is just an assumption, I am just asking whether 
you don't mind me making it.

Right. Let me make that more explicit:

import module [] [hidden hidden-stuff: "something you want" export 
a: func [code /stuff] [stuff: hidden-stuff code]]

In those circumstances a reference to :a is copied to lib/a, but 
there is no reference to the module saved except the PROTECT/hide 
reference to hidden-stuff in the block of :a.

Or rather it's copied to system/contexts/user/a, but the point remains 
the same.

Yes, OK. So, now, let me cite:


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.
 - don't you see, that your purported reason fails?

Why it fails: because, even knowing the bound version of the 'stuff 
variable does not help me to get the HIDDEN-STUFF, so, the purported 
reason does not exist

a func [] [do something to get access to hidden-stuff]


The function a doesn't exclude functions from its arguments and it 
refers to its argument with a word rather than a get-word, so it 
can be tricked into running code while it is running. That means 
its context is valid while the exploit code is running.

So, once again, your example demonstrating the existence of the (purported 
and nonexistent) reason failed.

The 'stuff word isn't hidden, but it isn't leaked while the function 
is running. That means that the exploit code only has access to the 
:a function value.

So, come up with some exploit code (that doesn't use STACK because 
we're assuming SECURE 'debug works). This is a real problem.

Do I understand correctly, that this is what you propose as demonstrating 
the reason for the functions not being accepted by BIND?

a: func [] [do something to get access to hidden-stuff]

No, you added a : there. The function is being passed to a as an 
argument.

aha, sorry, now I see.