On 10/30/20 5:55 PM, anonym wrote:
> procmem@???:
>> On 10/29/20 3:18 PM, anonym wrote:
>>> procmem@???:
>> 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.
>
> Woah, so it would probably work inside Tails?! I am very much interested
> in reproducing and investigating this in that case. Please help me out
> with any info/instructions you have about this!
>
OK so assuming you have restrict-stream-events toggled to false and
circuit-status whitelisted in the active profile, you would connect to
Tor with netcat like so (depending on the controlport no. you use). Have
Tor Browser open concurrently and browse to some page.
Then:
nc 127.0.0.1 9051
GETINFO circuit-status
It will initially give a 250 OK,but repeated, it'll show you everything
including the browser's circuit paths.
There's also a onion-grater debug mode that shows how it interacts with
incoming commands documented here you might find useful:
https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy#onion-grater_enable_debug_mode
>> 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+)
>>
>> ?
>
> I'd say, use the most accepting rule that doesn't break the
> functionality you want to keep since it is the more fail-safe approach,
> so if the first one works, it's better IMHO.
>
>>>> * 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?
>
> First, let's note that the rewrite rules operate on a per-line basis,
> which indeed puts some limitations of what is possible.
>
> My understanding is that you want to rewrite the multiline response of
> e.g. `GETINFO circuit-status` from something like:
>
> 250+circuit-status=
> 16 BUILT …
> 18 EXTENDED …
> …
> .
> 250 OK
>
> to an "empty" response:
>
> 250+circuit-status=
> .
> 250 OK
>
> Is this correct?
>
> If so, yes, I think there is a problem. I believe the best we can do at
> the moment is to have a rule like:
>
> GETINFO:
> - pattern: 'circuit-status'
> response:
> - pattern: '[0-9]+ (BUILT|EXTENDED|…) .*'
> replacement: ''
>
> i.e. that matches all the other lines of the response and replaces them
> with the empty sting... but that would result in a response with a bunch
> of empty lines in it:
>
> 250+circuit-status=
> <empty line>
> <empty line>
>
> … one <empty line> for each circ
> uit …
> .
> 250 OK
>
> which is think is invalid according to the control-spec. But it's worth
> testing, I guess! :)
>
Alright. I guess it can be left empty or at least stripped down enough
to appease the circuit dialog so it appears. Will need to experiment
around to know.
> But the better solution would be to extend onion-grater with something
> like the `suppress` option that exists for events, e.g.:
>
> GETINFO:
> - pattern: 'circuit-status'
> response:
> - pattern: '[0-9]+ (BUILT|EXTENDED|…) .*'
> suppress: true
>
> which would mean that any response line matching the pattern is
> completely dropped. I'm not completely sure, but it shouldn't be that
> hard to implement.
>
> Is this what you would like, or am I way off? If the latter, please try
> to explain in more detail what it is you want to achieve, preferably
> with concrete examples of the Tor output you get and exactly how you
> want it transformed.
>
Indeed it is. Thanks for your help.
> Cheers!
