Unwind values are assignable with set-word expressions, SET or SET/any

[rebolbot]

Submitted by: BrianH

When there is an assignment statement in the evaluation flow of an unwind function (BREAK, CONTINUE, THROW, RETURN or EXIT), the assignment actually happens and the word is set to the unwind pseudo-error value. Strangely enough it doesn't interfere with the unwinding process. Presumably when the assign returns the value being assigned (for chaining) the unwind propagation can continue. Still, the assignment should not happen in this case, since it could be a major security hole (see the example and #1004). Perhaps related to bug #1509.

The preferred course of action would be for the assignment to not happen in this case, just propagate the unwind. That would allow regular errors to be assigned, but would not assign unwinds.

; Proof that the error is assigned
>> a: make error! "Hello" form a
== {** User error: "Hello"
}

; Note that the break happens - the error is printed, not formed
>> a: break form a
** Throw error: no loop to break

; Proof that the break unwind was assigned above
>> form a
== {** Throw error: no loop to break
** Where: form
** Near: form a
}
; Note that the unwind was evaluated before the FORM,
; not formed as is. You can tell by the Where and Near
; fields of the error. This is a bad sign.

; Why this is bad: You can use that value to replicate the BREAK function
>> do a
** Throw error: no loop to break
>> loop 1 [do a print "Good"]
>>
; If you are sandboxing the unwind functions, this will break the sandboxing.

^{CC - Data [ Version: alpha 97 Type: Bug Platform: All Category: Error Handling Reproduce: Always Fixed-in:r3 master ]}

[rebolbot]

Submitted by: Ladislav

it is not counterintuitive to R2 users; it always worked:

>> error? a: try [1 / 0]
== true

[rebolbot]

Submitted by: Ladislav

"...It only seems to work with untriggered regular errors and unwinds." - the #771 as well as #1509 both mention, that it is a bug to "leak" triggered errors/unwinds into the Rebol value space, as opposed to untriggered errors/unwinds, where it is OK.

Fortunately, taking into account, how error propagation is implemented, triggered regular errors cannot leak into the Rebol value space, only unwinds can.

[rebolbot]

Submitted by: BrianH

Weird, I've been using SET/any for years to work around this. When did it start working this way in R2? It's always strange when you find out that a standard workaround that you've been doing for an old bug isn't necessary because at some point the bug got fixed without anyone telling you :)

I can't dismiss this ticket until #1509 is fixed; until then it is a major security bug. Summary changed accordingly.

[rebolbot]

Submitted by: Ladislav

in the core-tests suite

[rebolbot]

Submitted by: BrianH

Based on further testing, SET and SET/any also assign the unwind values, so I changed the summary, description and core-tests suite accordingly. Having the unwind value be passed to the SET function at all is bug #1509, but once it gets the unwind value it certainly shouldn't assign it to anything.