libfreebl3.so has got RWE flags in the PT_GNU_STACK ELF header (amd64)

[Jozsef Kadlecsik]

Description: Ubuntu 8.04.3 LTS
Release: 8.04

libnss3-1d version is 3.12.3.1-0ubuntu0.8.04.1

The libfreebl3.so library from the package has got RWE flags in the PT_GNU_STACK ELF header:

$ readelf -l /usr/lib/nss/libfreebl3.so

Elf file type is DYN (Shared object file)
Entry point 0x2f40
There are 5 program headers, starting at offset 64

Program Headers:
  Type Offset VirtAddr PhysAddr
                 FileSiz MemSiz Flags Align
  LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000055b24 0x0000000000055b24 R E 200000
  LOAD 0x0000000000055b28 0x0000000000255b28 0x0000000000255b28
                 0x0000000000000d8c 0x0000000000005018 RW 200000
  DYNAMIC 0x00000000000563a0 0x00000000002563a0 0x00000000002563a0
                 0x0000000000000210 0x0000000000000210 RW 8
  GNU_EH_FRAME 0x00000000000509e0 0x00000000000509e0 0x00000000000509e0
                 0x0000000000000d44 0x0000000000000d44 R 4
  GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000 RWE 8

In consequence, glibc ld.so creates all stack allocated by the library with rwe flags unnecessarily.

The library can be fixed by issuing

# execstack -c /usr/lib/nss/libfreebl3.so

but the package should install a non-exploitable library.

[Kai Engert (kaie)]

Created attachment 370674
Patch v1 (checked in)

Patch proposed by Ulrich

[Rrelyea (rrelyea)]

Comment on attachment 370674
Patch v1 (checked in)

r+ rrelyea

for 3.12.4

[Nelson-bolyard (nelson-bolyard)]

Comment on attachment 370674
Patch v1 (checked in)

Is this an issue only for x86_64 ?

[Drepper-fsp (drepper-fsp)]

(In reply to comment #3)
> (From update of attachment 370674 [details])
> Is this an issue only for x86_64 ?

Yes. The offending asm file is only on x86 and only Linux performs the stack tests. So it's even Linux-x86-64 specific.

[Wan-Teh Chang (wtc-google)]

Comment on attachment 370674
Patch v1 (checked in)

r=wtc.

In the past, we have been solving this problem by
adding this magic section to the end of every .s file:

  # Magic indicating no need for an executable stack
  .section .note.GNU-stack,"",@progbits
  .previous

For example, see
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/arcfour-amd64-gas.s&rev=1.2&mark=118-120#118

So you can also fix this bug by adding this section
to the new .s files added in NSS 3.12.3 (I believe
intel-ase.s is the only one). I would do that.

If you decide to use the -Wa,--noexecstack solution,
you should do it for all CPU architectures.

[Nelson-bolyard (nelson-bolyard)]

In reply to comment 5,
I remember that we had to remove that magic pseudo-op from one of our .s
files because gas on some platform didn't recognize it. I prefer solving
it through a command line option instead of a pseudo-op, if possible,
because it's easier to have command lines that vary by platform than to
have assembler source that varies by platform.

[Wan-Teh Chang (wtc-google)]

Created attachment 370780
Use -Wa,--noexecstack for all processor architectures

To be future-proof, you may want to use -Wa,--noexecstack
for all processor architectures.

[Wan-Teh Chang (wtc-google)]

Created attachment 370782
Set it in coreconf/Linux.mk

We can also set it in coreconf/Linux.mk, which will take
care of all the NSS and JSS directories.

[Wan-Teh Chang (wtc-google)]

Comment on attachment 370674
Patch v1 (checked in)

Kai, I noticed that you haven't checked in this patch, so I checked it in
on the NSS trunk (NSS 3.12.4). I actually prefer passing the -Wa,--noexecstack
flag for all processor architectures (we also have assembly files for
x86), but I checked in this patch because it has received review+.

Checking in Makefile;
/cvsroot/mozilla/security/nss/lib/freebl/Makefile,v <-- Makefile
new revision: 1.106; previous revision: 1.105
done

[Wan-Teh Chang (wtc-google)]

*** Bug 488959 has been marked as a duplicate of this bug. ***

[Nelson-bolyard (nelson-bolyard)]

This bug was originally reported against x86_64 builds on Linux, and was only
fixed for that platform. :(

Now it has been reported again for x86_32 builds on Linux in bug 499584.
I propose that we back out the fix committed for this bug, and commit
wan-Teh's patch in attachment 370782 instead. Please follow this issue in
bug 499584.

[Nelson-bolyard (nelson-bolyard)]

*** Bug 499584 has been marked as a duplicate of this bug. ***

[Nelson-bolyard (nelson-bolyard)]

No. I was mistaken. Bug 499584 was also about x86_64, and is a duplicate
of this bug. However, I do think we should fix it as shown in Wan-Teh's
patch in attachment 370782, so that it is fixed for x86_32 also.

[Wan-Teh Chang (wtc-google)]

Comment on attachment 370782
Set it in coreconf/Linux.mk

If you check in this patch, please back out patch v1 (attachment 370674)
to avoid duplicate -Wa,--noexecstack flags.

[Rrelyea (rrelyea)]

Wan-Teh, does the duplicate cause a problem with the compilier?

If not, I would prefer to leave it until the next time we open the FIPS token tree.

bob

[Wan-Teh Chang (wtc-google)]

Comment on attachment 370782
Set it in coreconf/Linux.mk

Then we can wait until then to check in this patch.
I don't think we will add assembly code to any directory
other than lib/freebl.

[Jozsef Kadlecsik (kadlec-launchpad)]

Description: Ubuntu 8.04.3 LTS
Release: 8.04

libnss3-1d version is 3.12.3.1-0ubuntu0.8.04.1

The libfreebl3.so library from the package has got RWE flags in the PT_GNU_STACK ELF header:

$ readelf -l /usr/lib/nss/libfreebl3.so

Elf file type is DYN (Shared object file)
Entry point 0x2f40
There are 5 program headers, starting at offset 64

Program Headers:
  Type Offset VirtAddr PhysAddr
                 FileSiz MemSiz Flags Align
  LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000055b24 0x0000000000055b24 R E 200000
  LOAD 0x0000000000055b28 0x0000000000255b28 0x0000000000255b28
                 0x0000000000000d8c 0x0000000000005018 RW 200000
  DYNAMIC 0x00000000000563a0 0x00000000002563a0 0x00000000002563a0
                 0x0000000000000210 0x0000000000000210 RW 8
  GNU_EH_FRAME 0x00000000000509e0 0x00000000000509e0 0x00000000000509e0
                 0x0000000000000d44 0x0000000000000d44 R 4
  GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000 RWE 8

In consequence, glibc ld.so creates all stack allocated by the library with rwe flags unnecessarily.

The library can be fixed by issuing

# execstack -c /usr/lib/nss/libfreebl3.so

but the package should install a non-exploitable library.

[Kees Cook (kees)]

Strangely, it is only a problem on 64bit! This is really nasty since that means firefox runs with an executable stack. Ugh.

[Kees Cook (kees)]

$ find . -name '*.o' | xargs -n1 scanelf -e | grep X
ET_REL !WX --- --- ./mozilla/security/nss/lib/freebl/Linux2.6_x86_64_glibc_PTH_64_OPT.OBJ/Linux_SINGLE_SHLIB/intel-aes.o

[Kees Cook (kees)]

Add stack markings to assembly file.

[Wan-Teh Chang (wtc-google)]

This is NSS bug 486537:
https://bugzilla.mozilla.org/show_bug.cgi?id=486537

This bug was introduced in NSS 3.12.3, and fixed in NSS 3.12.4
in the upstream.

There are several ways to fix this bug. Please use the upstream patch:

https://bug486537.bugzilla.mozilla.org/attachment.cgi?id=370674
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/security/nss/lib/freebl&command=DIFF_FRAMESET&file=Makefile&rev2=1.106&rev1=1.105

so that you will detect the patch isn't necessary when you upgrade
to NSS 3.12.4.

Sorry about the inconvenience.

[Kees Cook (kees)]

Ah, yes, that will do nicely as well. Thanks for digging this up!

[Launchpad Janitor (janitor)]

This bug was fixed in the package nss - 3.12.3.1-0ubuntu2

---------------
nss (3.12.3.1-0ubuntu2) karmic; urgency=low

  * Add 91_nonexec_stack.patch: fix regression in stack memory
    protectons caused by unmarked assembly (LP: #409864).

 -- Kees Cook <email address hidden> Mon, 24 Aug 2009 15:03:19 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package nss - 3.12.3.1-0ubuntu0.9.04.2

---------------
nss (3.12.3.1-0ubuntu0.9.04.2) jaunty-security; urgency=low

  * Add 91_nonexec_stack.patch: fix regression in stack memory
    protectons caused by unmarked assembly (LP: #409864).

 -- Kees Cook <email address hidden> Mon, 24 Aug 2009 15:03:19 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package nss - 3.12.3.1-0ubuntu0.8.10.2

---------------
nss (3.12.3.1-0ubuntu0.8.10.2) intrepid-security; urgency=low

  * Add 91_nonexec_stack.patch: fix regression in stack memory
    protectons caused by unmarked assembly (LP: #409864).

 -- Kees Cook <email address hidden> Mon, 24 Aug 2009 15:03:19 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package nss - 3.12.3.1-0ubuntu0.8.04.2

---------------
nss (3.12.3.1-0ubuntu0.8.04.2) hardy-security; urgency=low

  * Add 91_nonexec_stack.patch: fix regression in stack memory
    protectons caused by unmarked assembly (LP: #409864).

 -- Kees Cook <email address hidden> Mon, 24 Aug 2009 15:03:19 -0700

[Reed Loden (reed)]

Is this something that should be backported to 3.12.3 for those users still using that branch?

[Nelson-bolyard (nelson-bolyard)]

Reed, to what branch(es) are you referring?
Naturally, we'd prefer that any products using 3.12.3 simply update to
3.12.4 now that it has been released.

[Dveditz (dveditz)]

Linux distros typically use "system NSS" and can easily upgrade to 3.12.4 or even apply this patch to their own 3.12.3 version if they prefer. Firefox will be upgrading to 3.12.4 and any effort should go into making that happen rather than putting this patch on 3.12.3

[Wan-Teh Chang (wtc-google)]

*** Bug 522462 has been marked as a duplicate of this bug. ***