Ubuntu
nss package

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

Bug #409864 reported by Jozsef Kadlecsik
264
This bug affects 1 person
Affects Status Importance Assigned to Milestone
NSS
Fix Released
Medium
nss (Ubuntu)
Fix Released
Medium
Alexander Sack
Ubuntu karmic-alpha-6
Hardy
Fix Released
Medium
Alexander Sack
Intrepid
Fix Released
Medium
Alexander Sack
Jaunty
Fix Released
Medium
Alexander Sack
Karmic
Fix Released
Medium
Alexander Sack
Ubuntu karmic-alpha-6

Bug Description

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.

See original description
Revision history for this message
In , Kai Engert (kaie) wrote :

Created attachment 370674
Patch v1 (checked in)

Patch proposed by Ulrich

Revision history for this message
In , Rrelyea (rrelyea) wrote :

Comment on attachment 370674
Patch v1 (checked in)

r+ rrelyea

for 3.12.4

Revision history for this message
In , Nelson-bolyard (nelson-bolyard) wrote :

Comment on attachment 370674
Patch v1 (checked in)

Is this an issue only for x86_64 ?

Revision history for this message
In , Drepper-fsp (drepper-fsp) wrote :

(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.

Revision history for this message
In , Wan-Teh Chang (wtc-google) wrote :

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.

Revision history for this message
In , Nelson-bolyard (nelson-bolyard) wrote :

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.

Revision history for this message
In , Wan-Teh Chang (wtc-google) wrote :

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.

Revision history for this message
In , Wan-Teh Chang (wtc-google) wrote :

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.

Revision history for this message
In , Wan-Teh Chang (wtc-google) wrote :

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

Revision history for this message
In , Wan-Teh Chang (wtc-google) wrote :

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

Revision history for this message
In , Nelson-bolyard (nelson-bolyard) wrote :

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.

Revision history for this message
In , Nelson-bolyard (nelson-bolyard) wrote :

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

Revision history for this message
In , Nelson-bolyard (nelson-bolyard) wrote :

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.

Revision history for this message
In , Wan-Teh Chang (wtc-google) wrote :

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.

Revision history for this message
In , Rrelyea (rrelyea) wrote :

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

Revision history for this message
In , Wan-Teh Chang (wtc-google) wrote :

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.

Revision history for this message
Jozsef Kadlecsik (kadlec-launchpad) wrote : libfreebl3.so has got RWE flags in the PT_GNU_STACK ELF header

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.

Revision history for this message
Kees Cook (kees) wrote :

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

affects: ubuntu → nss (Ubuntu)
Changed in nss (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
visibility: private → public
Changed in nss (Ubuntu):
milestone: none → karmic-alpha-6
summary: - libfreebl3.so has got RWE flags in the PT_GNU_STACK ELF header
+ libfreebl3.so has got RWE flags in the PT_GNU_STACK ELF header (amd64)
Changed in nss (Ubuntu):
assignee: nobody → Alexander Sack (asac)
Revision history for this message
Kees Cook (kees) wrote :

$ 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

Revision history for this message
Kees Cook (kees) wrote :

Add stack markings to assembly file.

Changed in nss (Ubuntu Jaunty):
status: New → In Progress
Changed in nss (Ubuntu Karmic):
status: Confirmed → In Progress
Changed in nss (Ubuntu Intrepid):
status: New → In Progress
Changed in nss (Ubuntu Hardy):
status: New → In Progress
Changed in nss (Ubuntu Jaunty):
importance: Undecided → Medium
Changed in nss (Ubuntu Intrepid):
importance: Undecided → Medium
Changed in nss (Ubuntu Hardy):
importance: Undecided → Medium
Changed in nss (Ubuntu Jaunty):
assignee: nobody → Alexander Sack (asac)
Changed in nss (Ubuntu Intrepid):
assignee: nobody → Alexander Sack (asac)
Kees Cook (kees)
Changed in nss (Ubuntu Hardy):
assignee: nobody → Alexander Sack (asac)
Revision history for this message
Wan-Teh Chang (wtc-google) wrote :

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.

Revision history for this message
Kees Cook (kees) wrote :

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

Bug Watch Updater (bug-watch-updater)
Changed in nss:
status: Unknown → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in nss (Ubuntu Karmic):
status: In Progress → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in nss (Ubuntu Hardy):
status: In Progress → Fix Released
Changed in nss (Ubuntu Intrepid):
status: In Progress → Fix Released
Changed in nss (Ubuntu Jaunty):
status: In Progress → Fix Released
Revision history for this message
In , Reed Loden (reed) wrote :

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

Revision history for this message
In , Nelson-bolyard (nelson-bolyard) wrote :

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.

Revision history for this message
In , Dveditz (dveditz) wrote :

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

Revision history for this message
In , Wan-Teh Chang (wtc-google) wrote :

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

Bug Watch Updater (bug-watch-updater)
Changed in nss:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.