Do we get a fix for glibc security issues?

Tracked by Jolla (In release)

asked 2016-02-17 14:14:15 +0300

lpr
4819 ●186 ●253 ●257

updated 2018-06-08 15:23:44 +0300

CVE-2014-9761 ( =MER#1633 )
CVE-2015-5180
CVE-2018-1000001 ( =MER#1869 ) [Priority: High]
CVE-2017-8804 CVE-2017-12132 CVE-2018-6485 CVE-2018-11236 [Priority: medium]
CVE-2017-12133

As hackers are working on real exploits this is very urgent. SFOS seems¹ to use ASLR (which prevents the most simple exploits), but what occurrence does it use: the weak form of kernel 2.6.12 or Position-independent executable (PIE) which is stronger but weak in low memory conditions :-( ? ASLR is not perfect: Here is an interesting article about ASLR on ARMv7 devices [Stagefright is not fixed btw and could harm a JollaPhone].
Possible workarounds without patching are not suitable!

• (CVE-2015-7547 fix released in Taalojärvi)
• (CVE-2015-8777 fix released in Haapajoki)
• (CVE-2015-8776: fix released in Haapajoki)
• (CVE-2015-8778: fix released in Haapajoki)
• CVE-2014-9761: A stack overflow (unbounded alloca) could have caused applications which process long strings with the nan function to crash or, potentially, execute arbitrary code. (Accessvector:NETWORK/REMOTE CVSS v3 Base Score:9.8/10 critical)
• (CVE-2015-8779: fix released in Haapajoki)
• (CVE-2015-1781: fix released in Haapajoki)
• (CVE-2014-8121: fix released in Haapajoki)

• (CVE-2016-1234 Fix released in Jämsänjoki)
• (CVE-2016-4429 Fix released in Jämsänjoki)

additionally:
• (CVE-2015-5277: fix released in Haapajoki)
• (CVE-2016-3075 fix released in Haapajoki)
• (CVE-2016-2856: fix released in Haapajoki)
• CVE-2018-1000001: libc does not account for all the possible return values from the kernel getcwd(2) syscall; arbitrary code execution may result from applications making further assumptions on the return value from the getcwd(3) libary function. Priority: High
• CVE-2017-15670: The GNU C Library (aka glibc or libc6) before 2.27 contains an off-by-one error leading to a heap-based buffer overflow in the glob function in glob.c, related to the processing of home directories using the ~ operator followed by a long string. (Accessvector:NETWORK/REMOTE CVSS v3 Base Score:9.8/10 critical)
• CVE-2017-15671: The glob function in glob.c in the GNU C Library (aka glibc or libc6) before 2.27, when invoked with GLOB_TILDE, could skip freeing allocated memory when processing the ~ operator with a long user name, potentially leading to a denial of service (memory leak).
• CVE-2017-8804: Fix memory leak after deserialization failure in xdrbytes, xdrstring (bsc#1037930)
• CVE-2017-12132: Reduce EDNS payload size to 1200 bytes (bsc#1051791)
• CVE-2018-6485: Fix integer overflows in internal memalign and malloc functions (bsc#1079036)
• CVE-2017-12133: Avoid use-after-free read access in clntudp_call (bsc#1081556) (Accessvector: network/remote)

¹cat /proc/sys/kernel/randomize_va_space returns 2 and repeated ldd <some-executable> is returning different addresses of linked libraries.

edit retag flag offensive close delete

Comments

10

Thank you, great post. Just wanted to open it ;) .... second :-D

megalith ( 2016-02-17 15:56:14 +0300 )edit

1

+1 and more characters

jollailija ( 2016-02-17 17:35:41 +0300 )edit

4

its glibc, they will have to rebuild/test the world. I would expect that they will push back the Taalojarvi release for it though.

r0kk3rz ( 2016-02-17 17:51:00 +0300 )edit

14

@r0kk3rz no, they haven't to rebuild a lot. It affects glibc alone with its system functions, notably getaddrinfo() and strftime() used by almost all other applications

lpr ( 2016-02-17 18:36:15 +0300 )edit

11

Why is Jolla not able to patch on day zero?

lpr ( 2016-02-18 19:03:01 +0300 )edit

12

answered 2019-03-14 20:19:23 +0300

Sage
2244 ●23 ●37 ●28

admin

updated 2019-03-15 14:16:27 +0300

Quick update on this.

We have glibc 2.25 in our devel now (https://git.merproject.org/mer-core/glibc/commits/master) and it will come out soon (not in the next release, but one after that). The reason for going to 2.25 was as there are new build requirements in newer releases that we need to solve first before going forward, but we are are already working on those so we could get even newer versions soon.

Quick list of next steps on this:

2.26 requires gcc 4.9 or later, which is also in the works already https://git.merproject.org/mer-core/gcc/commits/master
2.27 no new requirements that we do not yet meet, WIP PR at https://git.merproject.org/mer-core/glibc/merge_requests/20
2.28 requires make 4.0 or later
2.29 requires gcc 5 or later
2.30 (which is yet to be released) requires gcc 6.2 or later

Getting there one step at the time.

edit flag offensive delete publish link

Comments

you should at least use debians 2.25-6 instead of 2.25-vanilla like it is done in openrepos-version: https://launchpad.net/debian/+source/glibc/2.25-6
this would fix CVE-2017-16997 CVE-2017-1000408 CVE-2017-1000409 CVE-2017-15670 CVE-2017-15671 and CVE-2017-15804

lpr ( 2019-03-14 23:44:46 +0300 )edit

and in general it would be better to use an Ubuntu LTS version like bionic-beaver as source base: 2.27-3ubuntuX
this version will be patched for years...

lpr ( 2019-03-14 23:50:23 +0300 )edit

@lpr it sounds like the plan is to quickly get up to 2.27 or 2.28 once GCC is updated

r0kk3rz ( 2019-03-15 00:58:34 +0300 )edit

Here is WIP PR for getting up to 2.27 vanilla https://git.merproject.org/mer-core/glibc/merge_requests/20 Still needs quite a bit of testing before merging.

Sage ( 2019-03-15 14:13:31 +0300 )edit

So the 2.27 needs a bit more work, there is tens of packages that are failing after moving to that so need to fix all those before going to 2.27, in the mean time did PR for the 2.25.6 from ubuntu https://git.merproject.org/mer-core/glibc/merge_requests/21/diffs need to do rebuild test for that still though.

Sage ( 2019-03-15 22:25:21 +0300 )edit

11

answered 2016-03-30 17:53:54 +0300

schmittlauch
4334 ●60 ●75 ●71

updated 2016-03-31 23:35:45 +0300

I added this issue to the topics for community meetings, maybe it'll be discussed on Thurs Mar-31 2016 @ 14:30 UTC in #mer-meeting (IRC) so if you're interested please show up there.

Edit: The relevant part of the meeting:

So 2.0.1 releasing is pending on the incoming call silence issue. (veskuh, 15:23:12)
the plan has been to release the hotfixes along with 2.0.1, but if that is still too far we should reconsider doing it as a separate hotfix as is now the proposal (veskuh, 15:24:23)
Jolla don't have definition of what makes issue critical, but we do have process for hotfix releases (stephg, 15:31:38)

So let's expect that hotfix.

edit flag offensive delete publish link

Comments

2

This is probably the best answer the community can provide, but doesn't answer to the question even with an ETA. Anyway, thanks to @veskuh and btw, you're welcome to answer on TJC too ;)

reviewjolla ( 2016-03-31 23:52:15 +0300 )edit

6

answered 2016-04-24 16:02:49 +0300

lpr
4819 ●186 ●253 ●257

http://www.uni-tuebingen....

updated 2018-03-06 13:54:34 +0300

It seems we will not see a single package update for glibc in Taalojärvi and Saimaa.
Jolla claims to have solved the issues with version 2.0.1 so there will be a new early access release of Taalojärvi.
I suppose Saimaa users have to keep waiting until final release...
edit 20170515: cve-2016-1234 and cve-2016-4429 fixed in glibc-2.19ubuntu6.11 so please implement it as soon as possible...

edit 20170629: glibc-2.19-0ubuntu6.13 additionally handles CVE-2017-1000366 (Stack Clash) so this should be implemented asap... (MER#1789)
edit 20170731: glibc-2.19-0ubutu6.13 part of Jämsänjoki update, leaving only cve-2014-9761 and cve-2015-5180 ...
edit 20180222: glibc-2.19-0ubutu6.14 not part of 2.1.4.13, yet
edit 20180306: update to glibc-2.19-6.14 did not happen in final sfos2.1.4 ...

edit flag offensive delete publish link

Comments

9

Yes, 2.0.1.11 is rolling out today to early access and includes glibc update.

veskuh ( 2016-04-28 15:00:46 +0300 )edit

@veskuh @xfade quick update to glibc-2.19+6.8 is needed! [not glibc-2.19+6.9 because 6.9 unfixes cve-2014-9761]

lpr ( 2016-06-25 15:54:13 +0300 )edit

3

new release 2.0.2.48 without an update? come on guys, really? @veskuh @xfade @tigeli

lpr ( 2016-07-28 16:25:05 +0300 )edit

https://git.merproject.org/mer-core/glibc/merge_requests/10

tigeli ( 2016-08-28 19:14:01 +0300 )edit

@veskuh @xfade @tigeli please revert debian/patches/any/CVE-2014-9761-2.diff in SFOS-source (as mer-project refuses this request due to servers) and release it in final Fiskarsinjoki. Phones have different needs than servers...

lpr ( 2016-10-18 18:58:56 +0300 )edit

2

answered 2018-06-08 15:32:16 +0300

lpr
4819 ●186 ●253 ●257

http://www.uni-tuebingen....

updated 2019-02-02 11:29:11 +0300

there is glibc-2.19-6.14 (required: Snapdragon 400 or higher) available on openrepos: https://openrepos.net/user/7598/programs

there is glibc-2.25.6+git1 (required: Snapdragon 400 or higher) available on openrepos: https://openrepos.net/content/lprnext/glibc-225-jollaphone

edit (version 2.23 superseded by 2.25.6+git1):
there even is a preview of glibc-2.23-10 (required: Snapdragon 400 or higher) available, but after installation you cannot connect to jolla-repositories that need credentials anymore unless you revert back to 2.19: https://openrepos.net/content/lprnext/glibc-225-jollaphone

edit flag offensive delete publish link

Comments

1

“Known Issues: it seems Jolla store-client will not launch anymore (so you have to go back to 2.19 to use it)”

Pick your poison: Have exploits open or official, reliable store broken.

RoestVrijStaal ( 2018-06-09 11:04:27 +0300 )edit

1

if you don't use official store all day, reverting and upgrading again is inconvenient but does work...
Some math-operations should be a lot faster in glibc2.23 due to more ARM NEON usage...

lpr ( 2018-06-09 12:28:14 +0300 )edit

1

answered 2019-07-24 15:32:16 +0300

Sage
2244 ●23 ●37 ●28

admin

updated 2019-07-24 15:51:25 +0300

jovirkku

23703 ●213 ●311 ●247

moderator

These have been now fixes in latest release (3.0.3), if there are new issues that are found please file separate threads in together for those. One of which was already filed by @lpr https://together.jolla.com/question/210105/heap-based-buffer-over-read-in-glibc-cve-2019-9169-critical-remote/

Considering this now as closed.

edit flag offensive delete publish link

Do we get a fix for glibc security issues?

Comments

5 Answers

Comments

Comments

Comments

Comments

Question tools

Stats

Related questions

Do we get a fix for glibc security issues?

Comments

5 Answers

Comments

Comments

Comments

Comments

Question tools

Public thread

Stats

Related questions