Mandatory ASLR on Windows for binary components

RESOLVED FIXED in Firefox 13

Status

()

Core
Security
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: khuey, Assigned: khuey)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug, {addon-compat, dev-doc-needed})

Trunk
mozilla13
x86
Windows 7
addon-compat, dev-doc-needed
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox13+ verified)

Details

(Whiteboard: [sg:want][qa+][advisory-tracking+])

Attachments

(1 attachment)

Created attachment 598386 [details] [diff] [review]
Patch

+++ This bug was initially created as a clone of Bug #677797 +++

Mandatory ASLR for all shared libraries has proven to be more difficult than we'd like.  Enforcing ASLR on all XPCOM components is pretty easy.  I cribbed liberally from Ehsan's patch for this.
Attachment #598386 - Flags: review?(benjamin)
No longer depends on: 694344, 694432, 696806
Comment on attachment 598386 [details] [diff] [review]
Patch

I'm still concerned about the possibility of this breaking third-party extensions with this, not via direct loading of XPCOM components but indirectly loading other DLLs, but I guess that we should try it and see what breaks. I think this is ok, but asking ehsan for a second look.
Attachment #598386 - Flags: review?(ehsan)
Attachment #598386 - Flags: review?(benjamin)
Attachment #598386 - Flags: review+
Comment on attachment 598386 [details] [diff] [review]
Patch

Review of attachment 598386 [details] [diff] [review]:
-----------------------------------------------------------------

Looks great!

::: xpcom/tests/component_no_aslr/TestComponent.cpp
@@ +19,5 @@
> + * Portions created by the Initial Developer are Copyright (C) 1998
> + * the Initial Developer. All Rights Reserved.
> + *
> + * Contributor(s):
> + *   Suresh Duddu <dp@netscape.com>

Nit: fix the obvious! ;-)
Attachment #598386 - Flags: review?(ehsan) → review+
Comment on attachment 598386 [details] [diff] [review]
Patch

Review of attachment 598386 [details] [diff] [review]:
-----------------------------------------------------------------

I would fix the obvious by using the MPL2 boilerplate, and

::: xpcom/tests/unit/xpcshell.ini
@@ +42,5 @@
>  # Bug 676998: test fails consistently on Android
>  fail-if = os == "android"
>  [test_versioncomparator.js]
> +fail-if = os != "win"
> +[test_comp_no_aslr.js]

Why does test_versioncomparator.js now fail on non-win OSes? If you meant that the new test fails, that would read

[test_comp_no_aslr.js]
fail-if = os != "win"

because the thing in []s is the INI section header, and fail-if is a property.

Also, the test_ prefix is probably no longer necessary, but I guess it makes sense to be consistent.

Comment 4

5 years ago
Comment on attachment 598386 [details] [diff] [review]
Patch

Review of attachment 598386 [details] [diff] [review]:
-----------------------------------------------------------------

::: xpcom/tests/Makefile.in
@@ +48,5 @@
> +DIRS		= \
> +  external \
> +  component \
> +  bug656331_component \
> +  component_aslr/component_no_aslr \

Needs corresponding toolkit-makefiles.sh entry.
I tried to land this yesterday but it broke Windows PGO builds :-/
Flags: in-testsuite+
Keywords: qawanted
Target Milestone: --- → mozilla13
Turned out to be a silly mistake.

https://hg.mozilla.org/mozilla-central/rev/b7582d84aa15
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
tracking-firefox13: --- → ?
http://blog.kylehuey.com/post/18120485831/address-space-layout-randomization-now-mandatory-for

Updated

5 years ago
Whiteboard: [sg:want]
Depends on: 730051

Updated

5 years ago
Depends on: 730274

Comment 8

5 years ago
Let's track any fallout from this bug, but no need to track a bug fixed on m-c.
tracking-firefox13: ? → -

Updated

5 years ago
Depends on: 731846

Updated

5 years ago
Depends on: 731919

Comment 9

5 years ago
Would it be possible to get a list of add-ons that may be affected together for QA to test?
Keywords: addon-compat
Any binary add-ons. But those add-ons will need recompile anyway.
(In reply to Alex Keybl [:akeybl] from comment #9)
> Would it be possible to get a list of add-ons that may be affected together
> for QA to test?

This can be useful for testing: https://addons.mozilla.org/en-US/firefox/compatibility/11.0?appver=1-11.0&type=binary
Adding qawanted to come up with a test plan of verifying add-on compatibility in FF13.
Keywords: qawanted
Given that further verification will be done in this bug, tracking for 13.
tracking-firefox13: - → +
(In reply to Alex Keybl [:akeybl] from comment #12)
> Adding qawanted to come up with a test plan of verifying add-on
> compatibility in FF13.

Does this fall under a feature being tracked for Firefox 13? or is this one of those "features" which is only tracked in bugs?
This will be assigned to someone in QA within the next 24 hours. Kyle, expect someone from Softvision (our Romanian partner) to be contacting you soon.

I am now tracking it for Firefox 13.
Whiteboard: [sg:want] → [sg:want][qa+]
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #14)
> Does this fall under a feature being tracked for Firefox 13? or is this one
> of those "features" which is only tracked in bugs?

I don't believe there's a feature page associated with this. This is more of a policy change with add-on compatibility fallout.
Removing qawanted from this bug as we have assigned someone to drive testing and sign-off of this as we normally would a full-fledged feature.
Keywords: qawanted
status-firefox13: --- → fixed
Depends on: 746616

Updated

5 years ago
Depends on: 749648
Depends on: 751585
Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0

Verified in 13 beta 4 on all Windows platforms (Windows Vista, XP, 7). Used process explorer and the following binary add-ons:
-FoxyTunes
-Last Pass
-Plain Old Favorites
-SBSH Safe Wallet Firefox Extension

Results here: http://bit.ly/KIL1EO

Apart from the Plain old favorites add-on (bug 746616), all other dlls had ASLR enabled or weren't loaded.
status-firefox13: fixed → verified
Whiteboard: [sg:want][qa+] → [sg:want][qa+][advisory-tracking+]

Comment 19

5 years ago
Would it be possible to indicate in the add-on list if an add-on is incompatible due to missing ASLR? At the moment everything looks normal to the user, but such add-ons just fail to execute. Some message during failed load attempt would be good too.

A pointer for troubleshooting binary add-ons, that might stop working with Firefox 13: http://stackoverflow.com/questions/8554014/how-to-know-whether-a-dll-uses-aslr-or-not
(In reply to Stefan Baebler from comment #19)
> Would it be possible to indicate in the add-on list if an add-on is
> incompatible due to missing ASLR? At the moment everything looks normal to
> the user, but such add-ons just fail to execute. Some message during failed
> load attempt would be good too.
> 
> A pointer for troubleshooting binary add-ons, that might stop working with
> Firefox 13:
> http://stackoverflow.com/questions/8554014/how-to-know-whether-a-dll-uses-
> aslr-or-not

This should probably be in the list of things which we check for in order to mark an add-on compatible with a new version automatically...
This is already the case, if an add-on contains binary components then default-to-compatible isn't enabled for it, it must list the current Firefox in its install.rdf (or update.rdf) for it to work.
You need to log in before you can comment on or make changes to this bug.