r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Ladislav
8-Oct-2011
[9588x4]
But, that does not solve the BIND annoyance.
In my opinion, BIND should simply obey and not annoy with error message 
in such a case
As said, if BIND does not do it for me, I can do it on my own using 
CHANGE, so no safety can be gained
...and, CHANGE actually isn't the only method usable, there are other, 
even uglier methods
BrianH
8-Oct-2011
[9592x2]
You can do it with CHANGE only if you get access to the bound body 
block, which is why letting a reference to that out is a security 
hole.
Or to a bound word.
Ladislav
8-Oct-2011
[9594]
Yes, understood, but that is fine. I know what I am doing and arrange 
the security as I see fit
BrianH
8-Oct-2011
[9595]
On second thought, allowing BIND to take a function! for its context 
argument would allow you to get around the security protections of 
BODY-OF.
Ladislav
8-Oct-2011
[9596x2]
I do not want to do that with a function. It really suffices to do 
it with a word
And, besides, it is circumventable anyway, the only reason why I 
do not show you that alternative is, that it looks even uglier than 
the usage of CHANGE
BrianH
8-Oct-2011
[9598]
But you can already BIND to a word bound to a function context. BODY-OF 
just keeps you from getting access to a word bound to a function 
context from outside the function. As long as you control access 
to the original code block you are secure.
Ladislav
8-Oct-2011
[9599x2]
But you can already BIND to a word bound to a function context.

 - actually, I cannot, if the function isn't already running (in that 
 case BIND refuses to do that)
That is what I call "annoying"
BrianH
8-Oct-2011
[9601]
>> bind 'a do func [/a] ['a]
** Script error: a is not in the specified context
** Where: bind
** Near: bind 'a do func [/a] ['a]


Well, then you don't have to be as careful with letting bound function 
words leak I guess.
Ladislav
8-Oct-2011
[9602x3]
(since it does not enhance security in any way)
But, that is wrong, since when you let the word out, you can bind, 
just not using the BIND function (you need to use CHANGE for that)
or, having the access to the body, you can do other tricks
BrianH
8-Oct-2011
[9605]
That isn't binding, that is changing to a word that is already bound.
Ladislav
8-Oct-2011
[9606x2]
And what else binding is in this case?
Binding just replaces all the words it "binds"
BrianH
8-Oct-2011
[9608]
>> head change [1] 'a
== [a]
>> head change [1] #"a"
== [#"a"]


With BIND, you can leak the 'a word and get access to the 'b word 
from that same context. You can't do that with CHANGE.
Ladislav
8-Oct-2011
[9609x3]
yes, but that is not a safety measure.
That is only "false safety", since it is circumventable
As long as you "Leak out" one word, you actually leak out the whole 
context, just not for the people who don't want to use "dirty tricks"
BrianH
8-Oct-2011
[9612x2]
(Sorry, internet outage)

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.
You still have to be careful while the function is running though.
Ladislav
9-Oct-2011
[9614x6]
What if 'a is harmless, but 'b refers to a password?

 - you are most probably out of luck, leaking 'a means 'b is obtainable 
 as well
(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.
BrianH
9-Oct-2011
[9620x4]
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.
Ladislav
9-Oct-2011
[9624]
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?
BrianH
9-Oct-2011
[9625]
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.
Ladislav
9-Oct-2011
[9626]
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.
BrianH
9-Oct-2011
[9627]
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.
Ladislav
9-Oct-2011
[9628x3]
Sorry?
Did I write that?
(I may have written it incorrectly, then, since that is not what 
I intended to write)
BrianH
9-Oct-2011
[9631]
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?
Ladislav
9-Oct-2011
[9632x2]
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.)
BrianH
9-Oct-2011
[9634]
I am asking something really specific (see my last message).
Ladislav
9-Oct-2011
[9635]
Yes, but I never offered the answer to your question.
BrianH
9-Oct-2011
[9636]
Ah, but that is the only question I was asking.
Ladislav
9-Oct-2011
[9637]
Yes, but my intent was to prove, that the BIND crippling is unreasonable, 
which is provable.