Patched glibc

Requests go here. If you fill a request, give it a new thread in the appropriate category and then link to it in the request thread.
Post Reply
Message
Author
gonkbag
Posts: 29
Joined: Thu 07 Jan 2010, 17:32
Location: uk

Patched glibc

#1 Post by gonkbag »

Hello
I've searched the forum with no luck for any signs of a patched glibc or a how to guide to patch the serious security issue with glibc.
All my net searches just say update it from your distro's repos.
If it's there somewhere could someone point me in the right direction.
glibc is such an important core part of all GNU/Linux systems that I'm reluctant to attempt compiling it myself in case it bricks the whole OS.
If a recompile is the only answer should we compile the newest version (2.23 I think) would that be compatible with older kernels ?

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#2 Post by musher0 »

Hello gonkbag.

Tone down the paranoia! You can relax!
No such vulnerability has been noted in the C libraries (aka glibc) that Puppy uses.

~~~~~~~~~~~~~~~~
FYI, I would like to add that:
* the library version number is important but not all that significant

* "glibc" is made up of a great number of components. Should there be a bug,
you wouldn't have to upgrade the whole kaboose, only a sub-set.

Those are wide subjects that are beyond the scope of your question. They should
not be discussed here.
~~~~~~~~~~~~~~~~

I read in this article: -- https://access.redhat.com/articles/2161461 --

Statement # 1:
> All versions of the glibc package included with Red Hat Enterprise Linux 6
and 7 were affected by this flaw.


Q. # 1: Is Puppy Linux derived from Red Hat 6 and 7?

A. # 1: NO. Puppy Linux is not based on Red Hat Enterprise Linux (RHEL) at all.

As far as I know, Puppy does not use any RHEL material. Depending on the
"Puppy breed", we use slackware, debian OR ubuntu repositories to build the
Puppies. I'm sure our devs would react promptly should a vulnerability be found
in the originating repo or libraries.


Statement # 2:
> A remote attacker could create specially crafted DNS responses which could
cause libresolv to crash or potentially execute code with the permissions of the user
running the library.


Three things here:
a) The use of the conditional form of the verb: "could". Please note : "conditional".

b) "DNS" : this vulnerability "could" affect name look-ups on the Internet. Only
"name look-ups". It is important but not the only thing.

It is certainly not the entire C library that needs to be corrected or changed. Only
a particular sub-sub-set.

c) "could create specially crafted": if I read this sentence correctly, no attack using
this vulnerability has been recorded yet
. The Red Hat people are being pro-active,
they're trying to show their commercial customers that they are ahead of the game.

(As you may know, Red Hat is one of the few distros that you have to pay for. Its
usual clientele is businesses rather than individuals.)

As I said:
Tone down the paranoia! You can relax!

I hope this helps.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#3 Post by musher0 »

You're right!

I won't go into the details of how to do it, but yes:

attempting to install any higher-numbered C library over the one used by a
running Puppy
will indeed break everything.


DON'T TRY IT!
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

How to fix a glibc 'mismatch'? [SOLVED]

#4 Post by davids45 »

G'day musher,

I have some older Pups on which I get problems trying to run new packages where I see a terminal message about the libc version not being correct/found when the new package won't run.

Is there a 'How to' or other simple explanation on how to use a newer libc version for this one application without wrecking the Pup's set-up that has the older C libs?

Is this a case where I should make a 'static' pet or sfs - where I have just one program that wants a later libc version? 'Static' = has all libraries included in the pet/sfs and these are in a path where other packages won't find them and try to 'share' them (i.e. as a 'dynamic' pet/sfs).

Thanks for any advice,

David S.

[SOLVED]
Thanks to help from 6502coder :D , I have made my program wanting a newer version of glibc (for some lib files) preferentially use the newer library files (2.15 version) without the need to attempt a glibc upgrade in the particular Pups having the 2.13 version.
The "Abracadbra" phrase is "LD_LIBRARY_PATH=", in a simple script, with the right following extras (and syntax and no typos :oops: ) and the right new glibc files on a path well away from the Pup-defined look-for-libs paths.
Maybe someone knowledgeable could do a 'How To' on using LD_LIBRARY_PATH= in a script to fix such version mismatch issues, for us users who keep old Pups but want the occasional new tricks too?
Attachments
Screenshot.png
example - file-sharing program dukto not running in pupjibarowheezy
(31.91 KiB) Downloaded 331 times
Last edited by davids45 on Tue 01 Mar 2016, 05:16, edited 2 times in total.

User avatar
6502coder
Posts: 677
Joined: Mon 23 Mar 2009, 18:07
Location: Western United States

#5 Post by 6502coder »

Check your private mail!

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#6 Post by musher0 »

6502coder wrote:Check your private mail!
Who? Me? I had no PM when I logged in just now.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

Re: How to fix a glibc 'mismatch'?

#7 Post by musher0 »

davids45 wrote:G'day musher,

I have some older Pups on which I get problems trying to run new packages where I see a terminal message about the libc version not being correct/found when the new package won't run.

Is there a 'How to' or other simple explanation on how to use a newer libc version for this one application without wrecking the Pup's set-up that has the older C libs?

Is this a case where I should make a 'static' pet or sfs - where I have just one program that wants a later libc version? 'Static' = has all libraries included in the pet/sfs and these are in a path where other packages won't find them and try to 'share' them (i.e. as a 'dynamic' pet/sfs).

Thanks for any advice,

David S.
Hi David.

The person to ask is dejan555 who put together the wonderful Dpup-4.87.That
Pup started 6 years ago based on Debian Lenny. It went through various trans-
formations and about a year and a half ago Dejan managed to bring it up to a glibc
of 2.20, which is above and beyond the recent librepup, even. Librepup was created
last Fall and it has a C library of only 2.19.

Dejan did explain to me briefly how he updated the C library for dpup-4.87, but it's
still above my head at this time. (I'm still studying the subject before I risk anything!)

The only sure-fire answer I can give you is this: you can compile any package on
your current Puppy after loading and activating its devx package. Such a compilation
will make the application run-able on your current Puppy.

But be fore-warned: some apps are easy and simple to compile, but
for others, there can be complications, among which:
  • * one or more missing library
    * the need to compile a secondary but essential app as well,
    * the app being compiled is not finding a library or header which you do have on
    __ your Pup (Puppy hierarchy is a tad different than on run-of-the-mill Linuxes).
Regarding "static" vs "shared" libraries: AFAIK, if you compile an app for your
current Puppy, in general, you don't need to specify "static" libraries when you type
the "configure" line before the compilation proper.

Finally, you will find on the Internet serious Linux forums with serious answers about
compiling a newer version of the C libraries in a separate folder and using that to
compile a certain app that needs it. Again, that's above my head at this time...

If you have the talent and the courage, go for it, but make double back-ups of
everything before you do.
So you can restore your Pup to what it was if the
experiment fails.

As I said, I'm still studying this, so I can help you only to a point. Hopefully, more
experienced members will join this thread and share their advice with us.

I hope this helps. BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
6502coder
Posts: 677
Joined: Mon 23 Mar 2009, 18:07
Location: Western United States

#8 Post by 6502coder »

musher0 wrote:
6502coder wrote:Check your private mail!
Who? Me? I had no PM when I logged in just now.
Sorry, I should have said @davids45. Not that I don't enjoy chatting with you, musher0!

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#9 Post by musher0 »

6502coder wrote:
musher0 wrote:
6502coder wrote:Check your private mail!
Who? Me? I had no PM when I logged in just now.
Sorry, I should have said @davids45. Not that I don't enjoy chatting with you, musher0!
You're not saying that to be polite, I'm sure !!!!! :D But that's ok.
Someone who chooses a nick like "6502coder" has to be a great guy! :D
Atari 8, eh? :D
Last edited by musher0 on Sun 28 Feb 2016, 13:13, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

watchdog
Posts: 2021
Joined: Fri 28 Sep 2012, 18:04
Location: Italy

#10 Post by watchdog »

If you are too anxious read this:

http://www.murga-linux.com/puppy/viewto ... 437#890437

In an old puppy I would use opendns without having to compile glibc. Glibc upgrade is very dangerous. I use glibc upgrade to run modern applications in old puppies but you have to experiment and know what are you doing.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#11 Post by musher0 »

watchdog wrote:If you are too anxious read this:

http://www.murga-linux.com/puppy/viewto ... 437#890437

In an old puppy I would use opendns without having to compile glibc. Glibc upgrade
is very dangerous. I use glibc upgrade to run modern applications in old puppies but
you have to experiment and know what are you doing.
Hello watchdog and all.

OpenDNS is a great tool, I used to use it. Except I can't with my current ISP,
videotron.ca. Also it's not as simple to configure on Puppy as it was on WhineDose.
(Me saying something positive about WhineDose, ha! Mark the calendar!) ;)

videotron.ca insists on you using their default (company?) DNS, otherwise no
Internet access, chum. So maybe other Internet service providers do it too.

What matters is that the vulnerability be plugged before you actually hit the road
(I mean: the Internet sites).

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

gonkbag
Posts: 29
Joined: Thu 07 Jan 2010, 17:32
Location: uk

#12 Post by gonkbag »

Hello again
here's a good article about the issue http://www.theregister.co.uk/2016/02/16 ... rnability/ I realise that an attacker would have to jump through a lot of hoops with little chance of success to exploit this, but I'll put it this way, looking both ways before crossing the road is a wise move not paranoia.
I use lupu 5 which is based on lucid ubuntu which is vulnerable.
I use puppy and other GNU/Linux distros partly because I like to look after my cyber security.
You can mitigate now against assaults exploiting the CVE-2015-7547 flaw by limiting all TCP DNS replies to 1024 bytes, and dropping UDP DNS packets larger than 512 bytes.
Anyone know how to do this ?

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#13 Post by musher0 »

As mentioned previously, gonkbag, the user doesn't need to do this if his/her ISP
is itself aware of the problem and mitigating it.

Ask your ISP to see if he's doing anything about it. If not, as member watchdog
above and another member who sent me a PM outlined, you can still use the
OpenDNS adresses.

Not that the problem you mention is not important. But the average user, including
me in this case, won't know how to manipulate those 1024-bit packets or what
have you on their own machine.

The C library is used across many OS's, so this coding oversight is likely to affect
all machines, including those of ISP's -- who have a vital interest in offering good
and secure service to their customers. It's an Internet-related bug, so they are
concerned too. And as Internet specialists they have much better expertise to kill
this bug.

Finally, you said that you are using a Lupu 5 Puppy. Have you checked that the
ldd version (aka glibc version, aka C library version) in Lupu 5 has this loophole ?
Do you even know how to check the ldd version on your Lupu?

I'd start there, if I were you. In the initial article you've offered, the RHEL people
explicitly stated that older versions of the C library were not involved. And Lupu 5
is definitely running with an older version of the C library. If I follow RHEL's logic,
that means it wouldn't have the bug. Please check your ldd version by opening a
terminal and typing:

Code: Select all

ldd --version
Please compare the results with those reported in the article and then tell us.

May I be as bold as saying that there's a possibility that you are making
everybody here needlessly paranoid? I'm prepared to eat crow over this.

Sorry, but that's how I feel about your topic at this point. BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

Post Reply