World: r3wp

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.

a func [] [print get bind 'stuff :a]

I had to go though the mezzanine code pretty carefully to consider 
what happens when functions are passed as arguments to the mezzanine 
functions. Some functions like REPLACE and ARRAY were modified to 
take advantage of that trick pretty nicely.

OK, but nothing of that kind applies to the case of BIND [...] 'some-variable

True, which is why I was convinced by that particular argument :)

then the ban on BIND to a function-context-bound word when the function 
isn't running has no security benefit
 :)

Yes, it only prevents some meaningful uses

Especially ones where the bound words are leaked intentionally to 
provide access to the context. It sounds worthy of a wish ticket 
in CureCode.

Unfortunately, the whole issue may be quite long to present completely

I'll write it up, if it's OK to copy some of your arguments from 
above into the ticket.

Anything

So, for the case of BIND [...] function the main difference is, that 
it cannot be done regardless of whether the function is running or 
not, which can be considered a security measure, then.

Yup. And BODY-OF returning an unbound copy prevents code like this:
	print get second body-of :a

PROTECT/hide doesn't affect existing bindings, so you need to be 
careful about leaking those too.

Initial version of the ticket made: http://issue.cc/r3/1893

Supporting comment added.

would it not be practical if REMOVE-EACH could /SKIP ?

nevermind. please ignore request.

remove-each [value skip] my-block [...]

ladislav, yes, saw it just now. :-)

The only function in R3 that operates that way is TRANSCODE, so as 
long as it doesn't choke on overlong combinations

#{c0ae} is an overlong encoding for #"." (#{2e}).

>> invalid-utf? #{c0ae}
== #{C0AE}

>> transcode #{c0ae}
== [® #{}]

>> transcode #{2e}
== [. #{}]

So for words, transcode is behaving strange. On the other hand, for 
strings ({"} is #{22}):

>> transcode #{22c0ae22}
== ["." #{}]

So, on R3 INVALID-UTF? flags overlong encodings? Sorry I missed that. 
Better fix the R2/Forward version accordingly.

No, it doesn't.

And we could use a ticket for the TRANSCODE bugs.

Or at least, it behaves the same as in R2.

INVALID-UTF? returns the series at the position of the first invalid 
sequence. If it doesn't flag it returns none.

If it is returning anything other than none for an overlong form, 
it is screening for overlong forms.

It is only in this particular case.

Other overlong forms are not being screened for, but one form is? 
That would also be worth a ticket.

No, that's nothing to do with overlong forms, but with PARSE in combination 
with bitsets being broken.

Which definitely is worth a ticket.

>> parse/all #{f0} reduce [charset [#{d0}]]
== true

I'm talking about the R3 version, which is a native that doesn't 
use PARSE. Do you think it's a related bug?

Mixed up R2 and R3 here.

The above is a bug in R3, in any case.

Well, if it doesn't have a ticket yet it could use one.

Ok. R2's invalid-utf? catches all 2-byte overlong forms, but not 
all 3 or 4-byte overlong forms.

#{e080af} is an overlong form for #"/", for example.

R2>> invalid-utf? #{e080af}
R2== none

R3>> invalid-utf? #{e080af}
R3== #{e080af}

Same for the 4-byte overlong sequence #{f08080af}. R3 correctly detects 
it as wrong, R2 does not.

So, R3's invalid-utf? seems to flag overlong encodings in general. 
R2(/Forward)'s invalid-utf? only catches overlong forms for 2-byte 
sequences, but not for 3- or 4-byte sequences.

Good - we can fix R2's version, but not easily fix R3's.

Change of subject: Has anyone sent mass emails in R3? I need to send 
some (legitimately, internally) from data that R3 processed.

What about 5 or 6 byte overlong forms?