[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #24177 [Applications/Tor Browser]: screenshot command in Web Developer toolbar is broken in Tor Browser



#24177: screenshot command in Web Developer toolbar is broken in Tor Browser
--------------------------------------+--------------------------
 Reporter:  cypherpunks               |          Owner:  tbb-team
     Type:  defect                    |         Status:  reopened
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-usability             |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by pospeselr):

 Replying to [comment:9 gk]:
 > That's due to #22692. I get the following in my terminal:
 > {{{
 > Message: Unix error 13 during operation stat on file image_name
 > }}}
 > Setting `security.sandbox.content.level` to anything less than `2` it
 "works". I wonder if #23970 would fix this issue as well.

 It does not (which isn't terribly surprising).  The patches in #23970 are
 specifically about serializing over the relevant font information from the
 sandboxed Web Content process to foreground firefox process so that the
 print.print_via_parent option works correctly.  Prior to the changes
 there, the print_via_parent option 'worked' but no fonts would be in the
 final rendered pdf/ps file.

 The issue here is almost certainly a file permissions issue since if you
 explicitly set a path the sandbox process has access to with the
 screenshot command (ie {{{ screenshot /tmp/screenshot.png }}} the
 operation succeeds.  The generated screenshot file and path will need to
 be broker'd over to the foreground which has access to the user's file
 system.

 The reason why some pages (empty tab, about:support, etc) can be
 screenshot (or successfully print-to-file'd prior to the #23970 fix) is
 (presumably) because they are hosted in the firefox process, rather than
 the sandboxed Web Content process, which seems kind of off.  For instance,
 if the strings in the about:support page are not properly sanitized, I
 could imagine sandbox-escape where a malevolent extension exercising some
 exploit through a malicious string in the Name, Version or ID strings.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24177#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs