Opened 23 months ago

Last modified 20 months ago

#20772 assigned defect

src="data:<;base64 images rendered when "Show images"="Blocked"

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

Description

Any webpages (e.g. ht tp://defensivepatentlicense.org/) that use base64 encoding thwart people's disabling of images.
Due to there not being enough software writers to go around, TBB and its derivatives e.f. Orfox(ht tps://dev.guardianproject.info/issues/8039) often leave remote code execution vulnerabilities in the image parser.
Disabling images would protect against this vector of infection, but they can't be disabled. Due to the almost identical codebase for everything but the menus and window borders, I think that this is likely a bug in the TBb source code rather than in the tiny delta that is Orfox.

Child Tickets

Change History (6)

comment:1 Changed 23 months ago by gk

Priority: ImmediateMedium
Severity: BlockerNormal

comment:2 Changed 23 months ago by mcs

Here is the corresponding Firefox bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=331257

There has not been much recent activity though.

comment:3 Changed 23 months ago by cypherpunks

Priority: MediumHigh
Severity: NormalCritical
Status: newneeds_review

In light of all the past attacks on images, the length of time zero days can exist, the increased security focus of TBB compared to Firefox, the fact that Mozilla have all but markrd this WONTFIX (despite patches being provided, and the fact that soon it will be legal to hack everyone on Earth without restriction, might you possibly reconsider leaving this to Mozilla?

Even if all you say is "pull requests welcome", that's far better than "WONTFIX". The patches in the Mozilla bug you linked to probably work as-is in TBB, but compiling a custom TBB would stand out eay to much. I beg you, please consider including one of the patches from https://bugzilla.mozilla.org/show_bug.cgi?id=331257

Systems are routinely compromised by images; http://search.us-cert.gov/search?utf8=%E2%9C%93&input-form=advanced&affiliate=us-cert&query-or=JPEG+GIF+PNG+BMP&per-page=10&filter=off&x=31&y=9 therefor raising priority. Please forgive my stubborness on this, it just seems extremely dangerous.

I can't compile it to test but the patches in the Mozilla thread lokely just need a brief review and merge, I hope.

comment:4 Changed 23 months ago by gk

Priority: HighMedium
Severity: CriticalNormal
Status: needs_reviewassigned

I don't see a patch attached to this ticket or linked to in this ticket, especially none that cleanly applies to Tor Browser we are currently using, thus cancelling the review request.

comment:5 Changed 23 months ago by cypherpunks

Priority: MediumHigh
Severity: NormalMajor

Active SVG exploits targetting TBB in the wild; https://blog.torproject.org/blog/tor-browser-607-released#comment-223692
Having an option to disable the image parser would allow mitigating future image bugs during the time between discovery and the time it's patched and users download the new version.

This applies to TBB proper, not just the exceptionally understaffed derivatives (eg https://dev.guardianproject.info/issues/8039).

comment:6 in reply to:  5 Changed 20 months ago by cypherpunks

Replying to cypherpunks:

Active SVG exploits targetting TBB in the wild; https://blog.torproject.org/blog/tor-browser-607-released#comment-223692
Having an option to disable the image parser would allow mitigating future image bugs during the time between discovery and the time it's patched and users download the new version.

This applies to TBB proper, not just the exceptionally understaffed derivatives (eg https://dev.guardianproject.info/issues/8039).

It must be very annoying to people when a cypherpunks account undoes a priority/severity change that a Tor developer does just before because they disagree with it. Why does it have to happen all the time? On behalf of cypherpunks everywhere, I apologize.

Anyway, regarding SVG, Tor Browser's ability to disable SVG is unrelated to its disabling of other images. Disabling SVG in fact disables the entire parser, such that data:// URIs will not be able to bypass it and render it anyway. Only "regular" images which do not have their own dedicated options for disabling are affected by this 11 year old issue, like PNG, JPEG, etc. Of course, 0days do exist for them, even ones which do not require heap spraying and other scripting techniques for exploit reliability...

Note: See TracTickets for help on using tickets.