Opened 22 months ago

Last modified 21 months ago

#24177 reopened defect

screenshot command in Web Developer toolbar is broken in Tor Browser

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability
Cc: pospeselr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When I try use the command it returns "unknownError"

Linux Tor Browser 7.0.9 (based on Mozilla Firefox 52.4.1) (64-bit)

Child Tickets

Change History (11)

comment:1 Changed 22 months ago by gk

Component: - Select a componentApplications/Tor Browser
Keywords: tbb-usability added
Owner: set to tbb-team
Status: newneeds_information

Do you have steps to reproduce that?

comment:2 Changed 22 months ago by cypherpunks

Just open Tor Browser and go to any site ,say, Wikipedia.
In the Developer Toolbar (Shift+F2) at the bottom type in
screenshot image_name
hit enter

Normally a screen shot is taken but now its simply says
"unknownError"

comment:3 Changed 22 months ago by cypherpunks

As I was writing the previous comment I checked it and the issue occured.
After I was finished I decided to try on Wikipedia ... just to be sure.
This time I got a different error:
"TypeError: this.target.tab is null"

Haven't seen that before.

As I am writing this I switched back to the Wikipedia tab for one more test and I got the usual error this time:
""unknownError"

comment:4 Changed 22 months ago by cypherpunks

And there's more...
if I open an empty tab it takes a screen shot!
A plain white screen shot.
Going back to the other tabs with content and the error returns.

comment:5 Changed 22 months ago by cypherpunks

Status: needs_informationnew

comment:6 Changed 22 months ago by cypherpunks

Cc: cypherpunks added
Resolution: worksforme
Status: newclosed

comment:7 Changed 22 months ago by cypherpunks

Hi original poster here.
What does "closed defect (worksforme)" mean: this is a one off anomaly and only impacts my copy of TorBrowser?
Thanks.

comment:8 Changed 21 months ago by gk

Resolution: worksforme
Status: closedreopened

comment:9 Changed 21 months ago by gk

Cc: pospeselr added; cypherpunks removed

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.

comment:10 in reply to:  9 ; Changed 21 months ago by pospeselr

Replying to 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.

comment:11 in reply to:  10 Changed 21 months ago by gk

Replying to pospeselr:

Replying to 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.

Makes sense, thanks. So, the question boils down to why just specifying a filename without an absolute path is working in vanilla Firefox but not Tor Browser then I guess.

Note: See TracTickets for help on using tickets.