Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 05 Dec 2014 19:59:35 -0500
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Offset2lib: bypassing full ASLR on 64bit Linux

On 05/12/14 05:15 PM, Reed Loden wrote:
> On Fri, Dec 5, 2014 at 7:09 AM, Daniel Micay <danielmicay@...il.com> wrote:
> 
>>
>> Mozilla has no excuse for not enabling PIE for Firefox, because 99% of
>> the code is in dynamic libraries already. It has no performance impact.
>>
> 
> For the record, Mozilla tried it several months ago and had to back it out.
> 
> "Nautilus (the file manager) can't open PIE executables, which makes
> distributing PIE executable essentially impossible."
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=857628#c6 (which caused
> https://bugzilla.mozilla.org/show_bug.cgi?id=1076892)
> 
> ~reed

I don't really see how this would prevent Mozilla from shipping a
browser with ASLR. The Tor browser has been shipping a fork of Firefox
built as a position independent executable for ages. It doesn't impact
users because they're either starting it via a .desktop file or the
command-line.

The support for desktop icons in Nautilus is deprecated / disabled by
default with only a hidden dconf preference to enable it. If you really
want to support the workflow of opening up the file manager, navigating
to the binary and double-clicking it then using a wrapper script is a
quite obvious solution.

The issue was already reported earlier by Mozilla, and the claim that
it's a blocking issue didn't make sense then either:

https://bugzilla.gnome.org/show_bug.cgi?id=737849

Chromium has used features like PIE, SSP and full RELRO for years while
Firefox doesn't enable any of it. I don't see it as much different from
how Chromium ships with an industry leading sandbox + features like JIT
hardening while Firefox doesn't have any of it. Even Internet Explorer
and Safari are shipping with decent sandboxing.

There are multiple cases of remote code execution discovered in every 6
week cycle and no industry standard exploit mitigations in place. It's
too bad that this doesn't least lead to any civil / criminal liability
due to negligence, especially when it's advertised as being more secure
/ private than competitors.

I find it hard to believe that there's any attention to security when
even the tiny amount of effort involved in enabling year / decade old
exploit mitigations is too much. Every project shipping a network-facing
or setuid binary without PIE has some explaining to do.


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.