Discuss

discuss@lists.centos.org

34753 discussions

FLASH NewsBites - Heartbleed Open SSL Vulnerability (fwd)
by Connie Sieh 10 Apr '14

10 Apr '14

For even more information about "Heartbleed". -Connie Sieh ---------- Forwarded message ---------- Date: Wed, 9 Apr 2014 12:27:54 -0500 From: The SANS Institute <NewsBites(a)sans.org> Subject: FLASH NewsBites - Heartbleed Open SSL Vulnerability FLASH NewsBites - Heartbleed Open SSL Vulnerability FLASH NewsBites are issued only when a security event demands global and immediate action. The HeartBleed Open SSL vulnerability fits that description. Proof: More than 200 students at SANS 2014 in Orlando this week spent 2 hours in a briefing on Heartbleed last night after full days of classes. This one matters. Tonight at 8:15 SANS faculty member Jake Williams will present a briefing explaining the HeartBleed vulnerability and what it means to you. Jake says: "Another 24 hours have passed since the initial presentation and we know more about what is vulnerable and what isn't. Even if you attended the short presentation last night at #SANS2014, this is a don't miss event." Jake will cover the actual structure of the vulnerability, methods for detection, and what you need to do (both as a systems admin and an end user). Jake will also perform live demos against a vulnerable server so you see first hand what can be exposed. Finally, we'll be releasing packet captures containing the exploit (suitable for testing your IDS rules). Register at: https://www.sans.org/webcasts/openssl-heartbleed-vulnerability-98105 Jake Williams, a principal consultant at CSRgroup Computer Security Consultants, has over a decade of experience in secure network design, penetration testing, incident response, forensics, and malware reverse engineering. Prior to joining CSRgroup, he worked with various government agencies in information security roles. Jake has twice won the annual DC3 Digital Forensics Challenge and has spoken at several regional ISSA meetings, Shmoocon, and the DC3 Conference, as well as numerous US government conferences. Jake is currently pursuing a PhD in Computer Science where he is researching new techniques for botnet detection. His research interests include protocol analysis, binary analysis, malware RE methods, subverting the security of cloud technologies, and methods for identifying malware Command and Control (C2) techniques.

2 1

cachefs
by Rita 10 Apr '14

10 Apr '14

has anyone been using cachefs with 6.x series? i have tried using it but i keep getting hung processes after 2 weeks. ATM, running 6.3 but was curious if its more stable on Centos 6.5? -- --- Get your facts first, then you can distort them as you please.--

6 11

How to save a Gnome screen layout on CentOS 6.5 after logging off?
by Gilbert Sebenste 09 Apr '14

09 Apr '14

Hello everyone, A quick Gnome question that has vexed me. In CentOS 5.10, if I have, say, an X terminal window up on my screen, the next time I log in, it's there when I log in as an unprivileged user. That's because I can save the layout the way I want to; there's a checkbox for it to save the layout upon exiting. I see none for CentOS 6.5. So, my X-terminal isn't there when I log in each time. Clue me in, oh people wiser than I... Gilbert ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************

3 5

Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
by James B. Byrne 09 Apr '14

09 Apr '14

On Tue, April 8, 2014 18:55, Lars Hecking wrote: > Leon Fauster writes: >> Am 08.04.2014 um 23:08 schrieb Keith Keller >> <kkeller(a)wombat.san-francisco.ca.us>: >> > On 2014-04-08, Robert Arkiletian <robark(a)gmail.com> wrote: >> >> >> >> if you include libcrypto in the grep then sshd is affected. >> > >> > That's unfortunate. :( Is the bug in libssl, libcrypto, or both? >> >> >> looking inside - its seems that this issue (cve-2014-0160) is resolved >> in ssl/d1_both.c and ssl/t1_lib.c and not in files under crypto/ ... >> to say more i have to take a look into the build process. > > The OpenBSD note for the patch reads > (http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/007_openssl.patch) > > | Only SSL/TLS services are affected. Software that uses libcrypto alone > | is not affected. In particular, ssh/sshd are not affected and there > | is no need to regenerate SSH host keys that have not otherwise been > | exposed. > > The patched code is the same everywhere, ssl subdirectory only. Code in > the crytpo subdirectory is not affected or patched. However, if one was running an affected service, say httpd/ mod_ssl, on a host that had sftp sessions connected to it then would not the ssh private keys of the host and local users be in memory and therefore readable by the exploit? If so then are not all these keys potentially compromised as we have no idea how long this exploit has been known to others prior to the community's own discovery? I have only a vague idea how all this stuff works but it seems to me that it is necessary that the private keys of all PKI implementations at some point have to be somewhere in memory in their usable, and therefore observable, state. As I understand the exploit it allows systematic transfer of every byte in memory which would include the unprotected keys would it not? -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

3 2

Error occurs when build kernel 3.2.0
by 李欣 09 Apr '14

09 Apr '14

Hi all, Please let me know if this is not the right place to ask this question. I was trying to compile and build kernel 3.2.0, by following <Linux Administration - A Beginner's Guide> written by Wale Soyinka. Error occurs after running the following command: # new-kernel-pkg -v --mkinitrd --depmod --install 3.2.0-custom initrdfile is /boot/initrd-3.2.0-custom.img running depmod for 3.2.0-custom creating initrd: /sbin/mkinitrd --allow-missing -f /boot/initrd-3.2.0-custom.img 3.2.0-custom found /boot/initrd-3.2.0-custom.img and using it with grubby adding 3.2.0-custom to /boot/grub/grub.conf /etc/lilo.conf does not exist, not running grubby Does anyone ever run into this? How can I fix it? Here is the link that I downloaded kernel from: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.bz2 # uname -a Linux test_server 2.6.32-431.11.2.el6.x86_64 #1 SMP Tue Mar 25 19:59:55 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release CentOS release 6.5 (Final) Please let me know if any other information is needed. Thanks. Xin Li

3 3

Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
by Peter van Hooft 09 Apr '14

09 Apr '14

> Message: 23 > Date: Tue, 8 Apr 2014 07:08:30 -0400 > From: Steven Tardy <sjt5atra(a)gmail.com> > Subject: Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed > workaround > To: CentOS mailing list <centos(a)centos.org> > Message-ID: > <CAG2k2x9udVEty0BRS+pEj0Hy3Mrt5N7NeCfZZC1r9qyv0M=rvA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller < > kkeller(a)wombat.san-francisco.ca.us> wrote: > > > On 2014-04-08, Karanbir Singh <kbsingh(a)centos.org> wrote: > > > > > > Earlier in the day today, we were made aware of a serious > > > issue in openssl as shipped in CentOS-6.5 ( including updates issued > > > since CentOS-6.5 was released ); This issue is addressed in detail at > > > http://heartbleed.com/ > > > > is there an easy way to know which services need to be kicked? > > > > > rpm -q --whatrequires openssl > That should work, in theory. On one of my machines: # rpm -q --whatrequires openssl postfix-2.6.6-2.2.el6_1.x86_64 openssl-devel-1.0.1e-16.el6_5.7.x86_64 # Then try: # yum remove openssl 2>&1 | grep 'will be erased' | wc -l 421 # I use this (crude) script to find what processes have files open from an rpm: ---------------------------------------------------------------------- #! /bin/bash -p if [[ "$(whoami)" != "root" ]]; then echo "$0: must be root" >&2 exit 1 fi if [[ -z "$1" ]]; then echo "usage: $0 rpm..." >&2 exit 1 fi tmpfile=$(mktemp) || { echo "$0: couldn't create temporary file" >&2 exit 1 } trap "rm -f $tmpfile" EXIT for rpm in $*; do if ! rpm -q "$rpm" >/dev/null 2>&1; then echo "$0: no such rpm $1" >&2 exit 1 fi rpm -ql "$rpm" >> $tmpfile done fgrep -f $tmpfile /proc/*/maps | awk -F/ '{print $3}' | sort -u | while read pid; do echo "$(ls -l /proc/$pid/exe | awk '{print $NF}') ($pid) ($(tr '\0' ' ' < /proc/$pid/cmdline))" done | sort -u ---------------------------------------------------------------------- # ./processes-that-use-files-from-an-rpm openssl /usr/bin/python (13146) (/usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x ) /usr/libexec/mysqld (1626) (/usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock ) /usr/sbin/certmonger (1776) (/usr/sbin/certmonger -S -p /var/run/certmonger.pid ) /usr/sbin/httpd (1709) (/usr/sbin/httpd ) /usr/sbin/httpd (20152) (/usr/sbin/httpd ) /usr/sbin/httpd (20153) (/usr/sbin/httpd ) /usr/sbin/httpd (20154) (/usr/sbin/httpd ) /usr/sbin/httpd (20155) (/usr/sbin/httpd ) /usr/sbin/httpd (20156) (/usr/sbin/httpd ) /usr/sbin/httpd (20157) (/usr/sbin/httpd ) /usr/sbin/httpd (20158) (/usr/sbin/httpd ) /usr/sbin/httpd (20159) (/usr/sbin/httpd ) /usr/sbin/httpd (20160) (/usr/sbin/httpd ) /usr/sbin/ntpd (1484) (ntpd -u ntp:ntp -p /var/run/ntpd.pid -g ) /usr/sbin/sendmail.sendmail (1667) (sendmail: accepting connections) /usr/sbin/sendmail.sendmail (1678) (sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue) /usr/sbin/sshd (1456) (/usr/sbin/sshd ) /usr/sbin/sshd (28396) (sshd: root@pts/0 ) # And depending on this output I restart the services mentioned, or if there are to many, reboot the box :-) Regards, Peter van Hooft Philips Research

2 1

Re: [CentOS] [CentALT] php-redis depedency error.
by sunshareall0709 09 Apr '14

09 Apr '14

THANK YOU! This DO help. ---------------------------------------------------------------------------------------------------------------- cd ~ wget -c http://dl.fedoraproject.org/pub/epel/6/x86_64/php-redis-2.2.2-5.git6f7087f.… sudo yum -y install ~/php-redis-2.2.2-5.git6f7087f.el6.x86_64.rpm [sunshare@sunshare tmp]$ php -i | grep redis /etc/php.d/redis.ini, redis Registered save handlers => files user redis This program is free software; you can redistribute it and/or modify [sunshare@sunshare tmp]$ cat test.php <?php $redis = new Redis(); $redis->connect('127.0.0.1', 6379); var_dump($redis->ping()); [sunshare@sunshare tmp]$ php test.php string(5) "+PONG" ---------------------------------------------------------------------------------------------------------------- 在2014年04月09 14时04分，"Maxim Shpakov"<maxim(a)osetia.org>写道： Hi! You can use php-redis from EPEL . It is compiled against stock CentOS php version 5.3.3 http://pkgs.org/search/?query=php-redis&type=smart 2014-04-09 8:58 GMT+03:00 sunshareall0709 <sunshareall0709(a)163.com>: > Hi! > Thanks for your response! > As you said, I've add exclude=php55* to /etc/yum.repos.d/centalt.repo, > and install again: > ---------------------------------------------------------------------------------------------------------------------- > [sunshare@sunshare ~]$ sudo yum install php-redis > Loaded plugins: refresh-packagekit, security > CentALT > | 951 B 00:00 > base > | 3.7 kB 00:00 > epel > | 4.4 kB 00:00 > extras > | 3.4 kB 00:00 > updates > | 3.4 kB 00:00 > Setting up Install Process > Resolving Dependencies > --> Running transaction check > ---> Package php-redis.x86_64 77:2.2.1-5.el6 will be installed > --> Processing Dependency: php(zend-abi) = 20090626-x86-64 for package: > 77:php-redis-2.2.1-5.el6.x86_64 > --> Finished Dependency Resolution > Error: Package: 77:php-redis-2.2.1-5.el6.x86_64 (CentALT) > Requires: php(zend-abi) = 20090626-x86-64 > Installed: php-common-5.3.28-4.el6.x86_64 (@CentALT) > php(zend-abi) = 20090626 > php(zend-abi) = 20090626-x86-64 > Available: php-common-5.3.3-26.el6.x86_64 (base) > php(zend-abi) = 20090626 > Available: php-common-5.3.3-27.el6_5.x86_64 (updates) > php(zend-abi) = 20090626 > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > ---------------------------------------------------------------------------------------------------------------------- > > > there are still available in [base] and [updates], so of course, > I add exclude=php-common-5.3.3-* to [base] and [updates]. > > then, try again: > ---------------------------------------------------------------------------------------------------------------------- > [sunshare@sunshare ~]$ sudo yum install php-redis > Loaded plugins: refresh-packagekit, security > Setting up Install Process > Resolving Dependencies > --> Running transaction check > ---> Package php-redis.x86_64 77:2.2.1-5.el6 will be installed > --> Processing Dependency: php(zend-abi) = 20090626-x86-64 for package: > 77:php-redis-2.2.1-5.el6.x86_64 > --> Finished Dependency Resolution > Error: Package: 77:php-redis-2.2.1-5.el6.x86_64 (CentALT) > Requires: php(zend-abi) = 20090626-x86-64 > Installed: php-common-5.3.28-4.el6.x86_64 (@CentALT) > php(zend-abi) = 20090626 > php(zend-abi) = 20090626-x86-64 > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > ---------------------------------------------------------------------------------------------------------------------- > > Yeath, this time just one hit the depedency. BUT ....as you can see, problem > as it's :-( > > Any more suggest, PLEASE? > Thank you! > > -- Sunshare > -- 2014-04-09 > > > 在2014年04月08 20时31分，"Maxim Shpakov"<maxim(a)osetia.org>写道： > > > Hi! > > Add exclude=php55* to /etc/yum.repos.d/centalt.repo > > There are problems regarding php55 dependencies in centalt repo. > > > 2014-04-08 15:26 GMT+03:00 sunshareall0709 <sunshareall0709(a)163.com>: >> Hi, All. >> When I try to install php-redis, there are obvious 4 package hit the >> depedency. >> One have already INSTALLED as follow. >> >> I've GOOGLED, NOTHING help. >> How can I get over this? Please Help, Thank you! >> -- Sunshare >> -- 2014-04-08 >> >> >> >> ------------------------------------------------------------------------------------------------ >> >> [sunshare@sunshare ~]$ sudo yum install php-redis >> [sudo] password for sunshare: >> Loaded plugins: refresh-packagekit, security >> Setting up Install Process >> Resolving Dependencies >> --> Running transaction check >> ---> Package php-redis.x86_64 77:2.2.1-5.el6 will be installed >> --> Processing Dependency: php(zend-abi) = 20090626-x86-64 for package: >> 77:php-redis-2.2.1-5.el6.x86_64 >> --> Finished Dependency Resolution >> Error: Package: 77:php-redis-2.2.1-5.el6.x86_64 (CentALT) >> Requires: php(zend-abi) = 20090626-x86-64 >> Installed: php-common-5.3.28-4.el6.x86_64 (@CentALT) >> php(zend-abi) = 20090626 >> php(zend-abi) = 20090626-x86-64 >> Available: php-common-5.3.3-26.el6.x86_64 (base) >> php(zend-abi) = 20090626 >> Available: php-common-5.3.3-27.el6_5.x86_64 (updates) >> php(zend-abi) = 20090626 >> Available: php55-common-5.5.11-1.el6.x86_64 (CentALT) >> php(zend-abi) = 20121212-64 >> You could try using --skip-broken to work around the problem >> You could try running: rpm -Va --nofiles --nodigest >> >> Following is my repo info: >> >> ------------------------------------------------------------------------------------------------ >> [sunshare@sunshare ~]$ sudo yum makecache >> Loaded plugins: refresh-packagekit, security >> CentALT >> | 951 B 00:00 >> CentALT/filelists >> | 136 kB 00:00 >> CentALT/primary >> | 102 kB 00:00 >> CentALT/other >> | 758 kB 00:03 >> CentALT >> 318/318 >> CentALT >> 318/318 >> CentALT >> 318/318 >> base >> | 3.7 kB 00:00 >> base/group_gz >> | 220 kB 00:01 >> base/filelists_db >> | 5.9 MB 00:33 >> base/primary_db >> | 4.4 MB 00:22 >> base/other_db >> | 2.8 MB 00:15 >> epel >> | 4.4 kB 00:00 >> epel/group_gz >> | 237 kB 00:01 >> epel/filelists_db >> | 8.4 MB 00:42 >> epel/primary_db >> | 6.0 MB 00:32 >> epel/other_db >> | 3.6 MB 00:19 >> epel/updateinfo >> | 769 kB 00:03 >> extras >> | 3.4 kB 00:00 >> extras/filelists_db >> | 11 kB 00:00 >> extras/prestodelta >> | 907 B 00:00 >> extras/primary_db >> | 19 kB 00:00 >> extras/other_db >> | 5.8 kB 00:00 >> updates >> | 3.4 kB 00:00 >> updates/filelists_db >> | 1.6 MB 00:07 >> updates/prestodelta >> | 216 kB 00:01 >> updates/primary_db >> | 2.6 MB 00:11 >> updates/other_db >> | 21 MB 01:41 >> epel/pkgtags >> | 1.0 MB 00:05 >> Metadata Cache Created >> _______________________________________________ >> CentOS mailing list >> CentOS(a)centos.org >> http://lists.centos.org/mailman/listinfo/centos > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos > > >

1 0

[CentALT] php-redis depedency error.
by sunshareall0709 09 Apr '14

09 Apr '14

Hi, All. When I try to install php-redis, there are obvious 4 package hit the depedency. One have already INSTALLED as follow. I've GOOGLED, NOTHING help. How can I get over this? Please Help, Thank you! -- Sunshare -- 2014-04-08 ------------------------------------------------------------------------------------------------ [sunshare@sunshare ~]$ sudo yum install php-redis [sudo] password for sunshare: Loaded plugins: refresh-packagekit, security Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package php-redis.x86_64 77:2.2.1-5.el6 will be installed --> Processing Dependency: php(zend-abi) = 20090626-x86-64 for package: 77:php-redis-2.2.1-5.el6.x86_64 --> Finished Dependency Resolution Error: Package: 77:php-redis-2.2.1-5.el6.x86_64 (CentALT) Requires: php(zend-abi) = 20090626-x86-64 Installed: php-common-5.3.28-4.el6.x86_64 (@CentALT) php(zend-abi) = 20090626 php(zend-abi) = 20090626-x86-64 Available: php-common-5.3.3-26.el6.x86_64 (base) php(zend-abi) = 20090626 Available: php-common-5.3.3-27.el6_5.x86_64 (updates) php(zend-abi) = 20090626 Available: php55-common-5.5.11-1.el6.x86_64 (CentALT) php(zend-abi) = 20121212-64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Following is my repo info: ------------------------------------------------------------------------------------------------ [sunshare@sunshare ~]$ sudo yum makecache Loaded plugins: refresh-packagekit, security CentALT | 951 B 00:00 CentALT/filelists | 136 kB 00:00 CentALT/primary | 102 kB 00:00 CentALT/other | 758 kB 00:03 CentALT 318/318 CentALT 318/318 CentALT 318/318 base | 3.7 kB 00:00 base/group_gz | 220 kB 00:01 base/filelists_db | 5.9 MB 00:33 base/primary_db | 4.4 MB 00:22 base/other_db | 2.8 MB 00:15 epel | 4.4 kB 00:00 epel/group_gz | 237 kB 00:01 epel/filelists_db | 8.4 MB 00:42 epel/primary_db | 6.0 MB 00:32 epel/other_db | 3.6 MB 00:19 epel/updateinfo | 769 kB 00:03 extras | 3.4 kB 00:00 extras/filelists_db | 11 kB 00:00 extras/prestodelta | 907 B 00:00 extras/primary_db | 19 kB 00:00 extras/other_db | 5.8 kB 00:00 updates | 3.4 kB 00:00 updates/filelists_db | 1.6 MB 00:07 updates/prestodelta | 216 kB 00:01 updates/primary_db | 2.6 MB 00:11 updates/other_db | 21 MB 01:41 epel/pkgtags | 1.0 MB 00:05 Metadata Cache Created

2 2

Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
by Keith Keller 08 Apr '14

08 Apr '14

On 2014-04-08, Karanbir Singh <kbsingh(a)centos.org> wrote: > > Earlier in the day today, we were made aware of a serious > issue in openssl as shipped in CentOS-6.5 ( including updates issued > since CentOS-6.5 was released ); This issue is addressed in detail at > http://heartbleed.com/ So it looks like new packages were issued by upstream pretty quickly. So one question is, is there an easy way to know which services need to be kicked? I was surprised (not unpleasantly) to note that sshd is not linked against libssl, but if you do a naive check against httpd, you won't find it linked either--because it's mod_ssl that's linked against it. --keith -- kkeller(a)wombat.san-francisco.ca.us

13 18

semi-OT: the trac problem solved
by m.roth＠5-cent.us 08 Apr '14

08 Apr '14

If it's of any interest, I finally solved the trac problem. Turns out you have to be granted TRAC_ADMIN to see/use the admin menus... but what is *not* suggested in anything I read is that, for those of us who might be ssh'ing into a server, and using organization-wide authentication, rather than /etc/passwd, you can't grant that to your username, but rather to username(a)organization.name ARGH!!!! And Paul, thanks for your help on the earlier parts. mark

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss