Re: [Tails-dev] Resend: Locking down stream-events in onion-…

On 10/29/20 3:18 PM, anonym wrote:
> procmem@???:
>> Re-sending this in a human readable form:
>
> Thanks!
>
>> A couple of months ago I was looking at locking down the amount of
>> info leaked to Tor Browser in case it is compromised - if/when stream
>> events access is enabled. my thought was to have the cake and eat it too.
>
> I guess you are not considering the restrict-stream-events option since
> this is in a Whonix context?
>

Yeah, so the idea is to sanitize any such info while getting circuit
view to work for authenticated onion functionality.

In a Tails context adding a rule to filter circuit-status would also
provide more defense in depth, by limiting what a browser exploit can
find out (in event it doesn't escape the browser sandbox). While you
have GUI alternatives like Onion Circuits view for the curious user.

On a related note, with restrict-stream-events set to true, I was still
able to access all stream events when testing with netcat in the
workstation VM. Initially it worked as intended and didn't pass this
info, but during subsequent trials it would read everything Tor was doing.


>> stream-events are needed to supported auth onions IIRC.
>
> Also the circuit view.
>
>> I ran into issues with escaping characters from Tor's output namely $
>> and + which were included in an example output:
>>
>> 250+circuit-status=00 BUILT
>> $relayid~$relayid,$relayid~$relayid,$relayid~$relayid
>> BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
>> TIME_CREATED=2020-09-16T00:00:00.000000
>>
>> Questions:
>>
>> * Can onion-grater currently deal with such characters without having
>> to escape them?
>
> Du you mean if you can write a pattern (i.e. regexp) where you want to
> match + and $ (from Tor's output) without escaping them? If so the
> answer is no, escaping is the only mechanism, and my question for you is
> why? What's the problem with escaping? For instance, "pattern:
> '250\+circuit-status…" should work just fine.
>
> I feel like I don't understand your question at all. :/
>

You answered it perfectly. So what you are saying is it should work and
any errors would be sign of a bug.

Follow up: what is the best approach to capturing this section of the
pattern

$relayid~$relayid,$relayid~$relayid,$relayid~$relayid

?

Just using (\S+) once or

do I have to do \$(\S+)~\$(\S+),\$(\S+)~\$(\S+),\$(\S+)~\$(\S+)

?

>> * Is it even possible to sanitize responses as large and varied as
>> stream-events output without having something leak thru or is it best
>> to keep it blocked for peace of mind?
>
> Theoretically, I think yes, but any black-list approach is pretty much
> futile to get perfect unless you put unreasonable resources on
> maintaining it. So at best you it can be considered in a
> defense-in-depth approach, but not as a single defense, IMHO.
>

I think another problem is circuit info is multi-line and don't all
start with 250+circuit-status=

I'm guessing this prevents any use of a wildcard as an easy catch-all
for the whole replies?

>> The rule I used in the profile:
>>
>>
>> GETINFO:
>>        - pattern: 'circuit-status'
>>          response:
>>          - pattern: '250(.+)circuit-status=(\S+) (\S+) (.+) (\S+) (\S+)'
>>          - replacement: '250+circuit-status='
>
> This rule is buggy! The fix is to remove the "-" before "replacement". I
> spotted this issue thanks to the debug log where it is clearer:
>

Happy it helped.

>>  host onion-grater[8471]:   - pattern: circuit-status
>>  host onion-grater[8471]:     response:
>>  host onion-grater[8471]:     - {pattern: 250(.+)circuit-status=(\S+)
>> (\S+) (.+) (\S+) (\S+)}
>>  host onion-grater[8471]:     - {replacement: 250+circuit-status=}
>
> As you can see, the 'pattern' and 'replacement' keys are in separate
> dictionaries, but 'response' wants a list (in your case of length 1) of
> dictionaries with exactly those two keys present. It becomes a bit more
> apparent if you provide more than one rewrite rules:
>
>     GETINFO:
>     - pattern: 'circuit-status'
>       response:
>       - pattern: '250(.+)circuit-status=(\S+) (\S+) (.+) (\S+) (\S+)'
>         replacement: '250+circuit-status='
>       - pattern: ...
>         replacement: ...
>       - pattern: ...
>         replacement: ...
>       ...
>
> Yeah, onion-grater should do a better job validating that the filters it
> loads are correct...
>
> Cheers!

Thanks for the feedback :)