Skip to content

Allow to replace malloc

murmelurmel requested to merge murmelurmel/tor-browser-build:murmelurmel-main-patch-81664 into main

Merge Info

Related Issues

Backporting

Timeline

  • Immediate: patchset needed as soon as possible
  • Next Minor Stable Release: patchset that needs to be verified in nightly before backport
  • Eventually: patchset that needs to be verified in alpha before backport
  • No Backport (preferred): patchset for the next major stable

(Optional) Justification

  • Emergency security update: patchset fixes CVEs, 0-days, etc
  • Censorship event: patchset enables censorship circumvention
  • Critical bug-fix: patchset fixes a bug in core-functionality
  • Consistency: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc
  • Sponsor required: patchset required for sponsor
  • Other: allows to use Torbrowser with hardened_malloc

Issue Tracking

Review

Request Reviewer

  • Request review from an applications developer depending on modified system:
    • boklm /cc ma1

Change Description

This does not change how the browser works normally. If a user uses LD_PRELOAD to load a different memory allocator though, it enables Torbrowser to use this allocator instead. This allows Torbrowser to be ran on systems preloading hardened_malloc or even compiling it into their version of gcc.

Such a preload can be disabled, but if it eventually gets integrated into gcc it is not reversible.

When preloading hardened_malloc Firefox and variants crash immediately. This is prevented with this build argument, which is not set by default.

In theory it can be a security risk to allow the use of a different malloc, provided by the system. But it would be an easy fix, not affecting how it runs on most systems, but allowing this use case. This should be evaluated.

How Tested

I have used Firefox Nightly with completely disabled jemalloc (thus using hardened_malloc via LD_PRELOAD) for multiple days, ran benchmarks, watched videos, DRM content etc, and it worked perfectly. Maybe a bit slower, but not a single crash. This will be the same with this flag.

Results from previous conversation

  • fingerprinting due to performance is out of scope, as then it could also be done by fingerprinting the hardware
  • the hardened_malloc is very likely not less secure than mozjemalloc
  • protecting against local, malicious LD_PRELOAD's is out of scope of the TorBrowser
Edited by morgan

Merge request reports