Issue metadata
Sign in to add a comment
|
ChromeOS toolchain should contain hardened libs. |
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36 Steps to reproduce the problem: We obtain our toolchain from here: https://pantheon.corp.google.com/storage/browser/chromiumos-sdk/2017/08/ Snapshot: 163007. And our sysroot from: https://pantheon.corp.google.com/storage/browser/chromeos-prebuilt/host/amd64/amd64-host/chroot-2017.08.01.163007/packages/cross-armv7a-cros-linux-gnueabi/ We notice that these libs don't have a stack canary: Full RELRO No canary found NX enabled libcrypt-2.23.so Full RELRO No canary found NX enabled libdl-2.23.so Full RELRO No canary found NX enabled libm-2.23.so Full RELRO No canary found NX enabled libnsl-2.23.so Full RELRO No canary found NX enabled libnss_compat- 2.23.so Full RELRO No canary found NX enabled libnss_dns- 2.23.so Full RELRO No canary found NX enabled libnss_files- 2.23.so Full RELRO No canary found NX enabled libpthread- 2.23.so Full RELRO No canary found NX enabled librt-2.23.so Full RELRO No canary found NX enabled libutil-2.23.so What is the expected behavior? What went wrong? Words. Did this work before? N/A Chrome version: 60.0.3112.78 Channel: n/a OS Version: Flash Version:
,
Feb 14 2018
Canary ALL the stacks.
,
Jan 7
llozano@ Can someone on the tool chain team please pick this up?
,
Jan 8
Caroline, can you please take a look?
,
Jan 8
How are you determining that they don't have a stack canary? I looked at a recent build, and all of the libraries you listed are built with the flag -fstack-protector-strong, which should provide a reasonable stack canary protection at not too expensive a performance penalty. But is is possible that your testing mechanism is not recognizing this form of protection?
,
Jan 9
I take that back. When I look at the files in pantheon that you refer to, it looks like they were built with "-fno-stack-protector". I'm not sure why, and I'm not sure if this has changed recently. Will keep digging.
,
Jan 9
Ok, here's what's going on: On Nov. 8, 2018, we upgraded those libraries from glibc 2.23 to glibc 2.27. At the same time, we change the flags with which they were being built. Previously they were built with -fno-stack-protector (i.e. no stack canaries). Since then they have been built with -fstack-protector-strong. If you get/download a recent sdk, those libraries should all be built with stack canaries. Please confirm if this is indeed the case, so we can close this issue.
,
Jan 9
,
Jan 9
going to drop the security markings as glibc has had a long history of not supporting SSP which makes this into a feature request if Caroline says glibc-2.27 is fixed, then let's assume so and let the reporter verify it (if they want) :)
,
Jan 9
,
Jan 21
(2 days ago)
Issue 763171 has been merged into this issue. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 Deleted