GlibC brings GHOSTS takeover to Linux. Resolutions imminent!

[jamesbond]

By the way if these recent long term bugs are to be taken totally to heart the linux we know and love has always been a security minefield and should not be touched with a bargepole...guess we were just plain lucky

Back to windows then?

Pick your poison
In 2010, MS found a 17-year bug dated from Windows NT 3.1 (the very first Windows NT).
In 2014, MS found 20-year bug dated from Windows 95.
This is just casual googling, not more than 10 seconds spent in looking

[mikeb]

If you look hard enough then you will find flaws with anything .....
but is it relevant to desktop computer usage on the net?

This one is quite hard to use and indeed that's why it took years to find..... is anyone going to use something this obtuse when there are much much easier ways to do the nasty ....

The term is risk assessment......

If you examined your cars brake disks you would find flaws in them at a microscopic level...are you going to change all of them?

mike

[jamesbond]

If you look hard enough then you will find flaws with anything .....

Exactly my point.

The term is risk assessment......

Proper risk assessment requires good grasp of probabilities (and a little bit of voodoo).

[mikeb]

Well having read and understood the technical description of this flaw the assessed risk is very low.

Mike

[battleshooter]

Per Jamesbond, The vulnerability in glibc is between 2.2 and 2.17.
http://murga-linux.com/puppy/viewtopic. ... 370#824370.

Oh, I'm good then, it said that in the article too but I missunderstood.

Oh sweet, Vanguard's safe too.

Code: Select all

# /lib/libc-2.20.so 
GNU C Library (GNU libc) stable release version 2.20, by Roland McGrath et al.

[greengeek]

The safest versions of any software are the early pre-release versions that don't quite run yet. Having loads of syntax errors in the code is the best way to ensure it can't be used to hijack your computer.

[ninotix]

So Wary/Racy and Lupu are vulnerable.. Patch/security update for their glibc ver. would be very useful

[Burn_IT]

Community project, get patching!!

[ninotix]

I think that these 2 pakages fix vulnerability for Lucid

http://security.ubuntu.com/ubuntu/pool/ ... 1_i386.deb

http://security.ubuntu.com/ubuntu/pool/ ... 1_i386.deb

[LazY Puppy]

"It's a messy Universe."

No.

Just do not compare the earth with the universe.

It's just a human made messy planet earth.

[watchdog]

I have been using in wary the previous glibc upgrade from lucid:

libc6_2.11.1-0ubuntu7.20_i386.deb

Code: Select all

# /lib/libc.so.6
GNU C Library (Ubuntu EGLIBC 2.11.1-0ubuntu7.20) stable release version 2.11.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.3.
Compiled on a Linux >>3.2.0-68-generic<< system on 2015-01-22.
Available extensions:
	crypt add-on version 2.1 by Michael Glad and others
	GNU Libidn by Simon Josefsson
	Native POSIX Threads Library by Ulrich Drepper et al
	BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.

Tested working well without libc-bin update. I'm going to test the new update:

libc6_2.11.1-0ubuntu7.21_i386.deb

Is libc-bin update really necessary?

EDIT: I have tested the vulnerability in wary after the libc6_2.11.1-0ubuntu20_i386.deb upgrade using:

https://news.ycombinator.com/item?id=8953545

and without libc-bin upgrade. Result: not vulnerable.

[ninotix]

"Is libc-bin update really necessary?

EDIT: I have tested the vulnerability in wary after the libc6_2.11.1-0ubuntu20_i386.deb upgrade using:

https://news.ycombinator.com/item?id=8953545

and without libc-bin upgrade. Result: not vulnerable.[/quote]"


- l think that libc-bin should also be installed because it is correlated with libc6 and dependency of libc6 package and vice versa

I'm not sure that using lucid package(ubuntu based) on wary/racy (T2) is good idea because wary/racy has glibc-2.10-1 and lucid package might broke something,it would be great if someone with knowledge could compile 2.10 T2 based package that is patched with latest security updates for wary/racy pup but that is just my opinion

Edit: yep as i suspected lucid package (with or without libc-bin package) breaks locales on wary/racy,you can see bunch of error messages in tmp/xerrs.log so yea use lucid packages only for lucid pups and precise packages only for precise pups.. For wary/racy we need someone to create T2 compiled pet packages with new security paches for glibc-2.10-1 and glibc_locales-2,10-1 because those packages are included in wary and racy

http://www.security-database.com/cpe.ph ... ibc:2.10.1

[watchdog]

The locale breaking is an old issue discussed many times in this forum and in the glibc upgrade thread: we began to upgrade glibc in puppy 4.31 and wary with debian squeeze libc6. I add to /etc/profile the line "export LC_ALL=C" in this way:

Code: Select all

#this line gets edited by chooselocale script...
# w004 going back to non-utf8... 101120 back to utf8... 101121 off again...
#110409 change .utf8 to .UTF-8 ...
#LANG=en_US.UTF-8
LANG=it_IT.UTF-8
export LANG

#v426 recommended by MU, avoid crashing for non-English locales on some apps...
#120525 shinobar: don't think we need this...
export LC_ALL=C

(from wary 5.5 /etc/profile...)

I'll continue to use lucid libc6 in wary: it works for me. I think it will work in puppy 4.31, too (not yet tested). The glibc upgrade breaks puppy 4.31's pmount and locales; pmount can be recovered changing the exec line in the desktop file with:

Code: Select all

rxvt -e pmount

Locales can be recovered putting LC_ALL=C the in /etc/profile after lang setting (I don't remember the original line, could be sometghing regarding seamonkey in other languages). See above.

[ninotix]

Thnx Watchdog export LC_ALL=C does the job,no more errors (y)