Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 25 Sep 2018, 05:22
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » REQUESTS
Patched glibc
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [13 Posts]  
Author Message
gonkbag

Joined: 07 Jan 2010
Posts: 29
Location: uk

PostPosted: Sat 27 Feb 2016, 05:50    Post subject:  Patched glibc
Subject description: serious security issue with glibc
 

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 ?
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 12697
Location: Gatineau (Qc), Canada

PostPosted: Sat 27 Feb 2016, 16:53    Post subject:  

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
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 12697
Location: Gatineau (Qc), Canada

PostPosted: Sat 27 Feb 2016, 17:13    Post subject:  

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
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
davids45


Joined: 26 Nov 2006
Posts: 1152
Location: Chatswood, NSW

PostPosted: Sat 27 Feb 2016, 18:00    Post subject: How to fix a glibc 'mismatch'? [SOLVED]
Subject description: A bit off topic - sorry
 

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 Very Happy , 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 Embarassed ) 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?
Screenshot.png
 Description   example - file-sharing program dukto not running in pupjibarowheezy
 Filesize   31.91 KB
 Viewed   302 Time(s)

Screenshot.png


Last edited by davids45 on Tue 01 Mar 2016, 01:16; edited 2 times in total
Back to top
View user's profile Send private message 
6502coder


Joined: 23 Mar 2009
Posts: 475
Location: Western United States

PostPosted: Sat 27 Feb 2016, 18:39    Post subject:  

Check your private mail!
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 12697
Location: Gatineau (Qc), Canada

PostPosted: Sat 27 Feb 2016, 23:10    Post subject:  

6502coder wrote:
Check your private mail!
Who? Me? I had no PM when I logged in just now.
_________________
musher0
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 12697
Location: Gatineau (Qc), Canada

PostPosted: Sat 27 Feb 2016, 23:46    Post subject: Re: How to fix a glibc 'mismatch'?
Subject description: A bit off topic - sorry
 

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
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
6502coder


Joined: 23 Mar 2009
Posts: 475
Location: Western United States

PostPosted: Sun 28 Feb 2016, 00:33    Post subject:  

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!
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 12697
Location: Gatineau (Qc), Canada

PostPosted: Sun 28 Feb 2016, 02:24    Post subject:  

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 !!!!! Very Happy But that's ok.
Someone who chooses a nick like "6502coder" has to be a great guy! Very Happy
Atari 8, eh? Very Happy

_________________
musher0
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)

Last edited by musher0 on Sun 28 Feb 2016, 09:13; edited 1 time in total
Back to top
View user's profile Send private message 
watchdog

Joined: 28 Sep 2012
Posts: 1663
Location: Italy

PostPosted: Sun 28 Feb 2016, 03:07    Post subject:  

If you are too anxious read this:

http://www.murga-linux.com/puppy/viewtopic.php?p=890437#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.
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 12697
Location: Gatineau (Qc), Canada

PostPosted: Sun 28 Feb 2016, 09:11    Post subject:  

watchdog wrote:
If you are too anxious read this:

http://www.murga-linux.com/puppy/viewtopic.php?p=890437#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!) Wink

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
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
gonkbag

Joined: 07 Jan 2010
Posts: 29
Location: uk

PostPosted: Mon 29 Feb 2016, 13:43    Post subject:  

Hello again
here's a good article about the issue http://www.theregister.co.uk/2016/02/16/glibc_linux_dns_vulernability/ 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.
Quote:
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 ?
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 12697
Location: Gatineau (Qc), Canada

PostPosted: Wed 02 Mar 2016, 00:36    Post subject:  

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:
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
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [13 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » REQUESTS
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0700s ][ Queries: 14 (0.0167s) ][ GZIP on ]