security.bsd.map_at_zero=0 problem with samba33 (including solution)

[Bjoern A. Zeeb]

On Mon, 5 Oct 2009, Mike Tancsa wrote:

Hi Mike,

>> > Thanks for reporting the issue.  People are aware of the problem now
>> > and we'll try to present a solution within the next days for better
>> > position-independent executable (PIE) handling.
>> >
>> > Meanwhile there are multiple solutions for people affected:
>> >
>> > (1) recompile the port; but as more than just samba might be affected
>> >      and we generally do not want to flip the pie switch everywhere 
>> that's
>> > probably only a temporary, private solution.
>> 
>> I'll stick to this since I am happy about having the map_at_zero
>> option and want to continue to try it out on 7.2-STABLE. And I
>> see now reason why samba has to be linked with -pie (without -pie
>> it is also 4% smaller).
>
> Hi,
> What are the impacts (if any) of compiling all the ports with PIE disabled 
> that are effected by setting security.bsd.map_at_zero=0 ?

Basically in first place compared to yesterday, there is no impact if
you do it privately as it will not make much, if any, difference as
PIE support in FreeBSD so far has basically been non-existent and was
more working out of luck, according to my current understanding.

Actually there is a slight difference that I should mention.  With PIE
valid user code is currently mapped at virtual address 0. That's why
it started to fail for people setting map_at_zero to 0.  So NULL
pointer dereferences in applications like samba will not lead to the
obvious error but will point at something, which in that case usually
will be garbage and the application will either not work as intended
(well that's alsready the case with a NULL derefernce;) or crash in
random code (as a later consequence of the NULL deref).

In the future though, it seems we will support PIE and in that case
you'll get mappings at different place, in the end ideally slightly
random so that it'll be hard to exploit the code itself as people no
longer can easily pre-guess where things are in virtual memory.
Disbaling PIE now means, that this will not happen later but you'll
have the fixed (entry point) address, unless you recompile the ports
again.


I said, no impact if you do it privately above; the problems for the
ports crew here are:
1) the entire set of ports affected by PIE is unidentified.
2) they build packages for 6/7 and 8, if not yet 9 as well soon for
    multiple architectures and cannot just rebuild everything.
3) they can especially not just rebuild the package set for the
    upcoming 8.0-RELEASE (don't ask, I don't know when it'll happen;).
4) basically they shouldn't need to care about which way the port
    (read the package as released by its devlepors) choses to be
    compiled by default.

I do not have strong arguments if PIE makes a lot of sense but it
seems that for the long term we'll have to support it, as parts of the
other world support it as well,  and once we support it even old
packages will then continue to work even if people disable
mapping_at_zero or if the release by default does that.

/bz

-- 
Bjoern A. Zeeb         It will not break if you know what you are doing.