On 10/29/20 3:18 PM, anonym wrote:
proc...@riseup.net:
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 :)
_______________________________________________
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
